jwz mentions PSA: Backups a backup system that's fairly clever. Your backup method is to essentially restore to the replacement drive. This seems to work simply on OSX. What all do I need to do to adopt this guide to Ubuntu?


Partition the two external drives the same way as your system drive, and rsync all your partitions as well as dding the boot sector (the first sector of the drive) from the system drive to the external drives. Ugly, but serviceable, if you get your partitioning right (big if).

Also take a look at more advanced "system snapshot" systems like mondo rescue, which kinda take care of that sort of trickery for you.

  • Just copying the bootsector is insufficient. Even in grub, the actual boot sector or MBR contains hard references to the sectors of the stage1/stage1.5 files in /boot/grub. You'll need to re-run the grub installer; there's no shortcut there.
    – bdonlan
    May 5 '09 at 6:31

For Ubuntu I recommend using sbackup, the whole "rsyncing a live bootable disk" just doesn't function very well in Linux. If the UUID's are different on the two drives (9/10 they will be) then you can't simply boot off the backup disk to get back up and running, you'll need to boot off your Ubuntu CD and edit /etc/fstab on the replacement drive first. If the UUIDs are the same, then you're going to run into problems while trying to have the two mounted simultaneously.

There are differences in the Mac filesystem that make this kind of trickery possible, I've never heard of doing this method via rsync but it's very common in the OSX world to backup by simply creating a disk image of your live boot volume, which you can later restore. Functionality to restore such images is provided on the OSX install CD.

The quickest solution for Ubuntu is sbackup and then just reinstalling Ubuntu (from the Ubuntu 'live CD' it's effectively the same as restoring a disk image, after which you restore your previous package selection, config and data from the sbackup archive. Fairly simple and I suspect you could write a howto that takes a new user through the complete steps of backup/install/restore without much problem.

  • Have you ever used sbackup?
    – jldugger
    May 3 '09 at 2:07
  • And I means <em>used</em>. To restore.
    – jldugger
    May 3 '09 at 2:08
  • used? Hell I donno how or if italics work here...
    – jldugger
    May 3 '09 at 2:09
  • Yup, I used it at my previous job and on my personal laptop where we were ll using ubuntu dekstop machines. Previously I was using homegrown scripts on 10+ servers and 50+ desktops. It's great, and I've restored from a backup as well with great success. I was a debian (and later Ubuntu) sysadmin and C developer for around 7 years. These days I'm mostly using a Microsoft stack but I still occasionally use Ubuntu and haven't found a better backup solution other than coding your own. May 3 '09 at 10:21

If you are clever, and you plan in advance, you can use LVM to accomplish this for you.

Say you have your system on a drive that uses LVM; in fact, the entire system is on an LVM volume somewhere.

With your second hard drive in an external case, attach the drive to your system, get LVM to recognize the drive, and then use LVM's mirror facility to copy the drive in place. Once a complete copy is finished, break the mirror. You will now have an exact snapshot in time (because the mirror also records any changes that take place during the copy process). The only thing you need now is to make it bootable. If you're using GRUB, you can do this from your existing system.

If you want to be really clever, write up this process as a script, and run the script on a regular basis. All you have to do is make sure the external drive is attached when it runs.


Not sure if I am understanding your question correctly:

If you are wanting to backup your linux machine to create bootable restore cd's, then have a look at mondo

It's a clever backup program that backs up your kernel and all required hardware drivers in such a way to be able to snapshot the entire server to .iso images, which can then be burned to CD/DVD. Then if a restore is needed, just pop in the first CD, power-on, and select a restore option.


I don't have an exact step-by-step recipe for you, but I suspect I would start building a system like this. I am assuming you are an Ubuntu user based on your icon, the tags.

  • I would start with the mini.iso that matches your running system and do a CLI-only install onto the portable drive. I would make it one big partition.
  • I would test booting from the portable drive to make sure everything is working so far.
  • On the install on your portable drive I would update the /etc/fstab, and /boot/grub/menu.list to use the uuid if they aren't already.
  • I would create a backup script (/root/rsync-to-portadrive) and exclude file (/root/rsync-exclude) like bellow (you probably need to add/tweak your exclude file).

I haven't tested this and worked out the fine details, but I am pretty sure if you rsync and don't overwrite the /etc/fstab or /boot, then the system should still boot and be able to mount the root filesystem. The /root/rsync-exclude file will keep you from including tmp files and junk you don't need to backup, and it will keep you from overwriting your /boot directory and fstab.

Like I said, I haven't tested I believe my basic plan is sound. I agree with other posters in believing that this isn't a great method for backing up your system. If you have any database applications like mysql, you will want to make sure you back them up separately.


# mount the portable device
mkdir -p /srv/portabackup/
mount /dev/disk/by-uuid/19976dc9-2d2b-43e3-87ff-d3fb071ddcb3 /srv/portabackup/

# make a backup of your /boot and fstab
mkdir -p /srv/portabackup/boot_backup/
cp /etc/fstab /srv/portabackup/boot_backup/fstab
rsync -va /boot/ /srv/portabackup/boot_backup/
# sync the main system
rsync -vaEH --delete --stats -D --numeric-ids \
      --exclude-from=/root/rsync-exclude \
      / /srv/portabackup/
# unmount
umount /srv/portabackup/


- lost+found/
- core
- *~
- .nfs*
- /tmp/***
- /var/tmp/***
- /boot/***
- /boot_backup/***
- /etc/fstab
- /etc/mtab
- /srv/portabackup/***
- /proc/***
- /sys/***
+ *

You didn't mention the frequency and the constraints. For desktops, I used a simple nightly cron script that did a dumb but complete duplication of the drive based on something like :

dd if=/dev/hda of=/dev/hdb


  • Cannot be simpler. If there is a problem, just throw away the faulty drive and you're good to go with a new one.
  • Since you will be reading the whole drive again, and writing the whole also it is nice to detect some bad sectors in a proactive way.
  • Filesystem & partitionning agnostic.


  • Horridly slow (Read hours). I did improve it by using a custom tool that did basically the same, but reading the destination in parallel and only issuing a write if the data was changed.
  • Since you are replicating many live filesystems, not much should change in them, especially since it's not really like a crash, the beginning of the drive will not be in sync with the end. So it's better to do it on a maintenance basis (with temporarily remounting the filesystems R/O)

A more chirugical solution does exist if your system allows "snapshotting" such as LVM snapshots as other pointed out. I proposed mine since the backup/recovery part is not as simple as your question seemed to imply.


You can't make a safe copy of a live system. The best bet is to make a boot disk, say a live CD, modified to run a script that does the back in one of the ways described above.

You could use these instructions to do the clone with ddrescue.

  • Why not? For the simplifying things, lets assume the only databases online are sqlite.
    – jldugger
    May 7 '09 at 23:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.