Creating a bootable copy of an active install

[bashPenguin]

Hi all,

Hoping one of you gurus can help me with this hypothetical handed down from up high (product management).

So imagine I have a generic Linux/*BSD install, and let's keep the partitioning simple. A /boot partition, and the / partition. The install boots and works correctly. Now, the person who wants to use this machine wants an emergency copy of the install that is basically a copy of the install at some point in time, so that in case they completely hose their main install, they can just boot into the copy.

What would be a good way to go about implementing such a system?

[Some considerations - the machine's installed software will not change much, basically once the machine is up the user only uses front ends to the system that abstracts functionality of the machine. They won't be installing software of their own onto it, though this wouldn't be too much a problem.]

I imagined a few scenarios, most involving just copying the directories, but the one that I think I'd like to implement would be this:
I'd copy the entire directory structure of the system in its pristine form (cp? tar and untar into the new partition? dd?), and for future syncing , use rsync from the primary partitions to the backup partitions when the user demands a copy be made. Also, modify the bootloader to recognize the other partition for booting.

However, I don't have much experience with something like this, so if anyone has implemented such a solution or knows another way that can be pretty fast or is better, let me know. If anyone uses an alternative solution (keeping a compressed copy around on some partition and then having something load it to recover a system) I'd like to hear it as well.

Thanks!

edit: I do have issues with such a feature, one being that I have to basically sacrifice half the hard drive for keeping a copy around.

 

[unhappy_mage]

This isn't as easy as it sounds. LVM lets you make snapshots... but I'd honestly just use dd to a removable disk.

If you do do something with copying files, the way I generally do it is "cd /source/dir; find . | cpio -pdmav /destination". That preserves permissions and so forth, and prints what files it's finished copying so you can see what's going on. Be sure not to copy /proc and /sys and so forth - perhaps boot from livecd and do it that way?

 

[bashPenguin]

I'm not sure if the machine would be shipped out to users with this back-up install already done for them initially, or if it will be created after the user initially configures it. If it's the former, then I have a lot more freedom in creating it, so I can use a liveCD or other to mirror the unmounted, inactive install.

The desired functionality is that the machine itself (without external storage, or a second machine, etc.) will have a backup bootable install in case the user does something to hose their install. I can only assume the machine will have one hard drive, nothing else, no removable disks or anything. Not to mention, I can't assume my end user knows what Linux or FreeBSD is, and they're not supposed to know what OS the machine runs.

I'll keep thinking about this more, you've raised some issues for me to look into, like LVM.

Thanks.

 

[Bones]

Your choice of tool depends on what you need to back up. dd will preserve the partition layout, which is nice for backing up the volume boot record(s), but that is easy to recreate with a bootloader reinstall. The MBR requires separate handling from the other partitions unless you image an entire drive. Basically, I look at dd as being overkill (and slow) for just doing a data backup.

My preferred method for system backup is plain old tar. tar works correctly for system backups as long as you tell it to preserve permissions. I boot a LiveCD and perform the copy from that environment, which avoids having to manually screen out files and directories like /dev and pidfiles from the backup.

cpio is a good alternative, but for this application I don't see an advantage in using it.

Another alternative is to use squashfs for the backup, which produces a compressed and directly mountable image of the system. It's reasonably fast at making the image (it uses multiple cores if the machine has them).

 

[Bones]

The desired functionality is that the machine itself (without external storage, or a second machine, etc.) will have a backup bootable install in case the user does something to hose their install. I can only assume the machine will have one hard drive, nothing else, no removable disks or anything. Not to mention, I can't assume my end user knows what Linux or FreeBSD is, and they're not supposed to know what OS the machine runs.

Those are interesting requirements. dd might be the way to go, then, if a competent system admin won't be available to handle the restoration process.

How about installing some minimal Linux, in addition to the regular system, that would handle system restoration? It could be set up to kick the user directly into a root prompt, with some short verbage on running one custom script that would dd the backup image over the partition with the (presumably damaged) operating system. Grub is easily configured for this sort of thing.

 

[eloj]

I'd look into a RAID-1 setup where the mirror is taken offline and synced periodically as needed (semi-daily? Weekly?). You could then have a boot menu which would select which disk to boot, so if the "master" is hosted, a reboot will have things up again.

It'd require some thinking and some custom work to make it safe though. Say they hose drive-0, reboot on drive-1, then what do you do with drive-0? Make it the mirror automatically? (what if there's something they want to try and recover from it first?) Require the user/admin to make it so manually? Then you risk that they forget and you've degraded back to where you're now...

Technically though, running a degraded RAID-1 setup is nice, and if the "master" dies, you can be back up very quickly.

 

[bashPenguin]

I am unsure if this system will even run more than one disk to allow for RAID. If it does, I still have to work with the assumption that people using this machine will have the technical expertise of someone who calls their monitor the CPU, So I have to devise a way to make this as painless, automatic, and transparent to the end user as possible.

Some more interesting suggestions though, guys, so thanks!