cvs commit: hints lfsbackup.txt
timothy at linuxfromscratch.org
timothy at linuxfromscratch.org
Tue Dec 24 07:53:08 PST 2002
timothy 02/12/24 10:53:08
Added: . lfsbackup.txt
Revision Changes Path
TITLE: Making a Working Backup of an LFS system
LFS VERSION: 4.0, should work on all
AUTHOR: Eric Miller <emiller at techskills.com>
This will quickly create an functioning duplicate of a finished LFS system.
This is useful for:
- Creating a backup of an LFS system on the same physical machine. That way
if something goes wrong in BLFS, users can boot into the Backup system and
repair thier original LFS. (or reverse the process to "restore" thier system
to its original state.)
- Doing a quick install on another system, e.g. "ghost". If you have two
identical systems with the same hardware, remove a hard drive from one, mount
in the LFS box, and follow the instructions here.
Once you have finished building an LFS system, it might be a good idea to create a
backup of the new system, before continuing with BLFS and other projects. In doing
so, you can confidently experiment with your new system and not "buy the farm" if
things go terribly wrong. A good time to do this is right at the end of the LFS book,
and before moving on to BLFS. This hint will explain how to create a dual-boot LFS system,
using a finished LFS system as a model, without doing another install.
You will need really only three things to complete this _very_ simple project:
- a finished LFS system
- access to your original host system
- some hard drive space, unpartitioned, at least as large as your LFS system
Let me take a second to further define these, for those who intend to use this for other
means. A "finished LFS system" is up to your definition. Nothing says that you have to
wait until the last page of the LFS book to do this. Really, any point that you want to
create a "restore point" will work fine. Understand that the dual-boot functionality
described here will _only_ work if your original LFS system was at least bootable.
Likewise, you may elect to make a backup after sucessfully finishing a big BLFS project,
like installing X and getting a desktop to work. The "finished system" is up to you.
If you followed the LFS book, your host system (the one you built LFS from), will still
be available in lilo. You may, however, have gotten rid of that puppy just as soon as
you logged into LFS without errors. There are creative ways to get around the fact that
you may not have access to your original host system (the one you built LFS from). You
can use the LFS boot CD, or a boot floppy with the necessary tools (post to lfs-support for
the url to the CD, see other hints for making boot floppies).
Finally, unpartitioned drive space canbe on _any_ installed fixed drive. You can even
install a drive from another (identical) system, make this backup, re-install the drive in
the original system, and you have two LFS systems for the price of one! (to do this, you
would ignore the editing of fstab, and you would need to use a boot disk to get into
the system the first time and run lilo.)
So, if you have those three things, let's do it! For this hint, we will use a sample
system that looks like:
/dev/hda1 Host system
/dev/hda3 LFS (the one you are making a copy of) # we will call this the source
/dev/hda4 the destination of our "backup" # we will call this the target
Note: If you are doing this at the end of the LFS book, or after any other big jobs,
you may want to get rid of /static, /usr/src, and any other big files like lfs-sources.tar
You may also want to run the --strip script at the end of the book (4.0). This is not
necessary, and if you are uncomfortable deleting files or running the script, then don't!
It will only make your backup (considerably) smaller and the process much faster.
- Boot your system into the original host linux (or Boot CD or floppy).
- fdisk /dev/hda (or whatever drive you using as the target)
- Create a primary partition that is at least slightly bigger than the data of
the source LFS. When in doubt, 1GB should be PLENTY for post LFS system.
- mke2fs /dev/hda4 (change to your situation, use /dev/hd## of target)
- mkdir /mnt/backup (also mkdir /mnt/lfs, if its not there already!)
- mount /dev/hda3 /mnt/lfs (change to your situation, use /dev/hd## of source)
- mount /dev/hda4 /mnt/backup (change to your situation, use /dev/hd## of target)
- cd /mnt/lfs (do not forget this, seriously!!!!)
- cp -Rav * /mnt/backup
- Take a break.....
- When cp is complete, do:
and edit the fstab to include an entry for the new partition. Refer to the
LFS book, ch6, editing FSTAB, for detailed info if you need it.
- Save the new fstab, reboot the system (shutdown -r now).
- At the lilo prompt, choose your original (source) LFS system.
- Login as usual, and do:
cp /etc/lilo.conf /anydir/anywhere
Edit lilo to INCLUDE the new (target) system. The LFS book gives a good example
of what lilo.conf should look like, do <man lilo.conf> to see a VERY good
example of a dual boot lilo.conf entry.
- Save the new lilo.conf
- run lilo (its in your path, just type lilo and <enter>). Watch for errors! If
lilo produces errors, do not proceed!!! Check your syntax based on the errors,
and edit lilo.conf as needed. When in doubt, replace the copy of lilo.conf to its
original location (/etc) and start over.
- When lilo exits without error (e.g. wrote *LFS, wrote backup), reboot and choose
the new backup system in lilo!
- login, make sure everything is cool.
- reboot, choose your original LFS system, proceed to make a mess of it without fear!
That's it. It's my first hint, so it's uber simple. To "restore" your system back to
the point of the backup, just reverse the process! By reverse, I don't mean the steps.
Simply make a backup of the backup, on the partition where the messed up LFS is. Don't
forget to either rm -r * in / _OR_ mke2fs to wipe out all the stuff on the bad partition,
otherwise you will just "restore" the good stuff next to bad stuff.
Thanks to Chris Lingard and others for thier guidance.
Use the hint at your own risk. Neither the author, nor the Linux From Scratch
project accepts any reponsibility for anything that happens when using these
documents or associated files.
An appropriate place to discuss this hint is blfs-support MailingList/NewsGroup
If I can improve this hint, or clarify in any way, let me know!
emiller at techskills.com
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe hints' in the subject header of the message
More information about the hints