I'm sure that we've all been reminded, ad nauseum, about the importance of performing regular back-ups of our important data. And I'm also sure we all have good intentions in this regard. Perhaps most of us do, in fact, back up our data regularly and often.
However, all it takes is one lapse in our routine that can cause a disaster! The one time that we forget or are too busy... something really important came up … yadda ...yadda ...yadda … and, “Oh drat!” A hard drive crash! A fried mother board! Corrupted system software! Our system is un-bootable … DOA!!
Or let's assume that we've been good. We've been doing regular back-ups and doing them often. Our critical data is safe. But, we still have to first, repair or replace the failed hardware, and then restore our operating system, and then check to make sure all of our irreplaceable personal data is still there and accessible.
Let's devise a back-up plan which will perform a complete system and personal data back-up automatically, nightly, onto a bootable drive, either removable or another hard drive. What follows is my personal back-up plan. Discussion about the relative merits or drawbacks of our individual lay-outs and partitioning schemes can be done another time. I will show you mine, and you can adapt my plan to fit your own particular desired partitioning scheme. I'll give appropriate instructions for various plans when there are significant differences between my lay-out and more traditional lay-outs.

$ lspci
00:00.0 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2)
00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2)
00:01.3 Co-processor: nVidia Corporation MCP61 SMU (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)
00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)
00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1)
00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)
00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2)
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
00:09.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0c.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 6150SE nForce 430] (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control
02:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9500 GT] (rev a1)
03:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller (rev 03)
03:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller (rev 03)

An AMD dual-core 500, 2Gigahertz processor, 4G of ram, and 2 750G internal hard drives, plus a Western Digital 320G usb drive.

I'm running on Ubuntu 11.04 “Natty,” with Gnome 2.32, and I still use the old style Grub. I do not use a SWAP partition, as with 4G of ram, and my use of the computer, I find that there is no need for it. I do not use a separate '/boot' partition. Thus, my partition lay-out is; '/', and '/home.' I use ext4 for both 'root' and 'home.'

I have partitioned both hard drives identically, and have a similar partition scheme for the WD 320 drive, with the exception of having an additional 10G partition formatted to FAT32 for Windows compatibility. It also has a 20G '/' and a 269G '/home' partitions, both ext4.

$ ls /
bin cdrom initrd.img lost+found opt sbin tmp var wd1
bkhome dev lib mnt proc selinux usr wd2
bkup etc lib32 media root srv vmlinuz wd3
boot home lib64 net save sys vmlinuz.old

As you will notice, I made directories for the back-up drives, called bkhome and bkup for the internal hard drives. And wd1, wd2, and wd3 for the Western Digital usb drive. If your partitioning scheme includes separate partitions for '/boot', '/usr', '/opt', or '/var', you would need to create the appropriate directories for your separate partitions. For back-up purposes, it really isn't necessary to create the 'wd1' directory. I just prefer to control the mounting of things with 'fstab' rather than let things get mounted willy-nilly in '/media.'

The first thing we'll need to do after we've prepared our back-up disk with whatever partition scheme we've chosen, is to copy our main hard drive, in it's entirety, to the back-up drive. However, we cannot copy dynamically active directories, '/proc,' '/sys.' Nor should we copy directories which have a mounted drive attached to them, such as '/home.' Instead, we make those directories as root.

# mount /bkup
# mkdir /bkup/bkup
# mkdir /bkup/bkhome
# mkdir /bkup/home
# mkdir /bkup/media
# mkdir /bkup/proc
# mkdir /bkup/save
# mkdir /bkup/sys

# ls /bkup
bkup bkhome home media proc save sys

# cp -ravd /boot /bkup
# cp -ravd /bin /bkup
# cp -ravd /dev /bkup
# cp -ravd /etc /bkup
# cp -ravd /i* /bkup
# cp -ravd /lib* /bkup
# cp -ravd /mnt /bkup
# cp -ravd /opt /bkup
# cp -ravd /root /bkup
# cp -ravd /tmp /bkup
# cp -ravd /usr /bkup
# cp -ravd /var /bkup
# cp -ravd /vm* /bkup

Give ownership rights to 'user' for /bkhome;
# chown -R user /bkhome
# chmod 0700 /bkhome


You will need to make changes to '/etc/fstab' using your favorite text editor. This is my '/etc/fstab.' You will also need to edit the '/etc/fstab' files in each of the backup drives.
We'll need to know what drives are mounted and where.

# mount -l
/dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro,commit=0) [hd1,0]
proc on /proc type proc (rw)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
/dev/sda3 on /home type ext4 (rw,relatime,commit=0) [hd1,1]
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
/dev/sdd1 on /bkup type ext4 (rw,nosuid,nodev,user=al) [hd0,0]
/dev/sdd2 on /bkhome type ext4 (rw,nosuid,nodev,user=al) [hd0,1]

And we'll need to know the UUID of each partition. Using UUID instead of /dev/sdxx or LABEL is, in my opinion, much more reliable for keeping track of partitions, especially after a period of time when you might have re-partitioned your drives, or replaced a drive.

# blkid
/dev/sda2: LABEL="hd1,0" UUID="7b77942f-8731-45c2-a4f2-730defa607d4" TYPE="ext4"
/dev/sda3: LABEL="hd1,1" UUID="c3302a95-ad81-4897-98cf-e9934ac1d4d4" TYPE="ext4"
/dev/sdd1: LABEL="hd0,0" UUID="6d9777ab-1212-492f-a30e-78639df4f64a" TYPE="ext4"
/dev/sdd2: LABEL="hd0,1" UUID="7a4d6c9c-f9cf-4232-9395-20ed299c794b" TYPE="ext4"
/dev/sr2: LABEL="WD SmartWare" TYPE="udf"
/dev/sde1: UUID="08BD-7D3F" TYPE="vfat"
/dev/sde2: UUID="1ca78561-22b1-45f5-8549-95a6b2a8149e" TYPE="ext4"
/dev/sde3: UUID="26f04fe4-ccbb-43db-b667-f01382791a2b" TYPE="ext4"

Now, using the 'mount' and 'UUID' information, edit your /bkup/etc/fstab to reflect where it will be mounted, and so on, when you boot to it. If you have an additional back-up drive, such as a removable drive and a second internal hard drive, you will need to edit the /??/etc/fstab as well.


$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on UUID=7b77942f-8731-45c2-a4f2-730defa607d4 during installation
UUID=7b77942f-8731-45c2-a4f2-730defa607d4 / ext4 relatime,errors=remount-ro 0 1

# /home was on UUID=c3302a95-ad81-4897-98cf-e9934ac1d4d4 during installation
UUID=c3302a95-ad81-4897-98cf-e9934ac1d4d4 /home ext4 relatime 0 2

# /bkup was on UUID=6d9777ab-1212-492f-a30e-78639df4f64a during installation as a bootable copy of UUID=7b77942f-8731-45c2-a4f2-730defa607d4
UUID=6d9777ab-1212-492f-a30e-78639df4f64a /bkup ext4 noauto,user,exec 1 2

# /bkhome was on UUID=7a4d6c9c-f9cf-4232-9395-20ed299c794b during installation as a complete copy of UUID=c3302a95-ad81-4897-98cf-e9934ac1d4d4
UUID=7a4d6c9c-f9cf-4232-9395-20ed299c794b /bkhome ext4 noauto,user,exec 1 2

# /wd1 was on UUID=08BD-7D3F (western digital usb drive) during installation
UUID=08BD-7D3F /wd1 vfat noauto,user,exec 1 2


# /wd2 was on UUID=1ca78561-22b1-45f5-8549-95a6b2a8149e (western digital usb drive) during installation
UUID=1ca78561-22b1-45f5-8549-95a6b2a8149e /wd2 ext4 noauto,user,exec 1 2

# /wd3 was on UUID=26f04fe4-ccbb-43db-b667-f01382791a2b (western digital usb drive) during installation
UUID=26f04fe4-ccbb-43db-b667-f01382791a2b /wd3 ext4 noauto,user,exec 1 2

/dev/sr0 /media/dvd auto ro,user,noauto,unhide 0 0

$ cat /bkup/etc/fstab
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on UUID=6d9777ab-1212-492f-a30e-78639df4f64a during installation
UUID=6d9777ab-1212-492f-a30e-78639df4f64a / ext4 relatime,errors=remount-ro 0 1

# /home was on UUID=7a4d6c9c-f9cf-4232-9395-20ed299c794b during installation
UUID=7a4d6c9c-f9cf-4232-9395-20ed299c794b /home ext4 relatime 0 2

# /bkup was on UUID=7b77942f-8731-45c2-a4f2-730defa607d4 during installation as a bootable copy of UUID=6d9777ab-1212-492f-a30e-78639df4f64a
UUID=7b77942f-8731-45c2-a4f2-730defa607d4 /bkup ext4 noauto,user,exec 1 2

# /bkhome was on UUID=c3302a95-ad81-4897-98cf-e9934ac1d4d4 during installation as a complete copy of UUID=7a4d6c9c-f9cf-4232-9395-20ed299c794b
UUID=c3302a95-ad81-4897-98cf-e9934ac1d4d4 /bkhome ext4 noauto,user,exec 1 2

# /wd1 was on UUID=08BD-7D3F (western digital usb drive) during installation
UUID=08BD-7D3F /wd1 vfat noauto,user,exec 1 2

# /wd2 was on UUID=1ca78561-22b1-45f5-8549-95a6b2a8149e (western digital usb drive) during installation
UUID=1ca78561-22b1-45f5-8549-95a6b2a8149e /wd2 ext4 noauto,user,exec 1 2

# /wd3 was on UUID=706b7027-c3fe-4265-b5fc-8164923944e0 (western digital usb drive) during installation
UUID=706b7027-c3fe-4265-b5fc-8164923944e0 /wd3 ext3 noauto,user,exec 1 2

/dev/sr0 /media/dvd auto ro,user,noauto,unhide 0 0


$ cat /wd2/etc/fstab
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on UUID=1ca78561-22b1-45f5-8549-95a6b2a8149e during installation as a bootable backup # of UUID=7b77942f-8731-45c2-a4f2-730defa607d4
UUID=1ca78561-22b1-45f5-8549-95a6b2a8149e / ext4 relatime,errors=remount-ro 0 1

# /home was on UUID=706b7027-c3fe-4265-b5fc-8164923944e0 during installation as a bootable # backup of UUID=c3302a95-ad81-4897-98cf-e9934ac1d4d4
UUID=706b7027-c3fe-4265-b5fc-8164923944e0 /home ext3 relatime 0 2

# /bkup was on UUID=7b77942f-8731-45c2-a4f2-730defa607d4 during installation as a bootable copy of UUID=1ca78561-22b1-45f5-8549-95a6b2a8149e
UUID=7b77942f-8731-45c2-a4f2-730defa607d4 /bkup ext4 noauto,user,exec 1 2

# /bkhome was on UUID=c3302a95-ad81-4897-98cf-e9934ac1d4d4 during installation as a complete copy of UUID=706b7027-c3fe-4265-b5fc-8164923944e0
UUID=c3302a95-ad81-4897-98cf-e9934ac1d4d4 /bkhome ext4 noauto,user,exec 1 2

# /wd1 was on UUID=08BD-7D3F (western digital usb drive) during installation
UUID=08BD-7D3F /wd1 vfat noauto,user,exec 1 2

/dev/sr0 /media/dvd auto ro,user,noauto,unhide 0 0



Next, we will need to add the appropriate boot entries into our /boot/grub/menu.lst. I still prefer the old Grub to the newer version. It works just fine for me, and I do not see any difference in boot performance between the two. Your preferences might be different. Having very little experience with the new style Grub, I can't give any details about how to edit that. This is my /boot/grub/menu.lst;

$ sudo cat /boot/grub/menu.lst
[sudo] password for al:
color white/blue black/black

default 0

timeout 10

#hiddenmenu

splashimage=(hd0,1)/boot/grub/penguin-inside.xpm.gz

title Ubuntu 11.04 64bit sda2 (kernel 3.4.0-rc2-vanilla-natty+)
root (hd0,1)
kernel /boot/vmlinuz-3.4.0-rc2-vanilla-natty+ root=UUID=7b77942f-8731-45c2-a4f2-730defa607d4 ro quiet splash
initrd /boot/initrd.img-3.4.0-rc2-vanilla-natty+
quiet

title Ubuntu 11.04 64bit sda2 (kernel 3.3.0-vanilla-natty+)
root (hd0,1)
kernel /boot/vmlinuz-3.3.0-vanilla-natty+ root=UUID=7b77942f-8731-45c2-a4f2-730defa607d4 ro quiet splash
initrd /boot/initrd.img-3.3.0-vanilla-natty+
quiet

title Ubuntu 11.04 64bit sda2 (kernel 3.0.0-12-generic)
root (hd0,1)
kernel /boot/vmlinuz-3.0.0-12-generic root=UUID=7b77942f-8731-45c2-a4f2-730defa607d4 ro quiet splash
initrd /boot/initrd.img-3.0.0-12-generic
quiet

title Ubuntu 11.04 64bit sdb1 (kernel 3.4.0-rc2-vanilla-natty+)
root (hd0,1)
kernel /boot/vmlinuz-3.4.0-rc2-vanilla-natty+ root=UUID=6d9777ab-1212-492f-a30e-78639df4f64a ro quiet splash
initrd /boot/initrd.img-3.4.0-rc2-vanilla-natty+
quiet

title Ubuntu 11.04 64bit sdb1 (kernel 3.3.0-vanilla-natty+)
root (hd1,0)
kernel /boot/vmlinuz-3.3.0-vanilla-natty+ root=UUID=6d9777ab-1212-492f-a30e-78639df4f64a ro quiet splash
initrd /boot/initrd.img-3.3.0-vanilla-natty+
quiet

title Ubuntu 11.04 64bit sdb1 (kernel 3.0.0-12-generic)
root (hd1,0)
kernel /boot/vmlinuz-3.0.0-12-generic root=UUID=6d9777ab-1212-492f-a30e-78639df4f64a ro quiet splash
initrd /boot/initrd.img-3.0.0-12-generic
quiet

title Ubuntu 11.04 64bit wd2 (kernel 3.4.0-rc2-vanilla-natty+)
root (hd0,1)
kernel /boot/vmlinuz-3.4.0-rc2-vanilla-natty+ root=UUID=1ca78561-22b1-45f5-8549-95a6b2a8149e ro quiet splash
initrd /boot/initrd.img-3.4.0-rc2-vanilla-natty+
quiet

title Ubuntu 11.04 64bit wd2 (kernel 3.3.0-vanilla-natty+)
root (hd4,1)
kernel /boot/vmlinuz-3.3.0-vanilla-natty+ root=UUID=1ca78561-22b1-45f5-8549-95a6b2a8149e ro quiet splash
initrd /boot/initrd.img-3.3.0-vanilla-natty+
quiet

title Ubuntu 11.04 64bit wd2 (kernel 3.0.0-12-generic)
root (hd4,1)
kernel /boot/vmlinuz-3.0.0-12-generic root=UUID=1ca78561-22b1-45f5-8549-95a6b2a8149e ro quiet splash
initrd /boot/initrd.img-3.0.0-12-generic
quiet

As long as there has NOT been a catastrophic failure to the mother board, this will allow booting to either of the backup drives, /bkup, or /wd2. I do boot to each of them from time to time, just to be certain that they both work, and that the back-ups have gone as planned.
There is one more thing that we need to do, however, before we can actually get either of them to boot fully. We need to edit the /etc/fstab files on each of them to reflect the actual '/' and '/home' partitions. Examples of my /bkup/etc/fstab and /wd2/etc/fstab were shown earlier. Use your favorite text editor to edit yours appropriately.

Now, we need to build a cron job to do the backup at a time which is convenient for you. Lazy as I am, it's just easier to use Gnome-schedule to build the cron jobs. I invoke “gnome-schedule” as root to build the 'system' backup. And I use Gnome-schedule as 'user' to build the backup of my home directory.
As root, build this schedule;

Task Description Date and Time Command preview
Recurrent Backup System On every day @ 01:00 mount /bkup
Recurrent Backup System On every day @ 01:01 cp /bkup/etc/fstab /bkup/save/fstab.bkup.save
Recurrent Backup System On every day @ 01:01 cp -rauvd /boot /bkup
Recurrent Backup System On every day @ 01:01 cp -rauvd /etc /bkup
Recurrent Backup System On every day @ 01:01 cp -rauvd /lib* /bkup
Recurrent Backup System On every day @ 01:01 cp -rauve /opt /bkup
Recurrent Backup System On every day @ 01:01 cp -rauvd /root /bkup
Recurrent Backup System On every day @ 01:01 cp -rauvd /usr /bkup
Recurrent Backup System On every day @ 01:01 cp -rauvd /var /bkup
Recurrent Backup System On every day @ 07:45 cp /bkup/save/fstab.bkup.save /bkup/etc/fstab
Recurrent Backup System On every day @ 08:00 umount /bkup

As user, build this schedule;

Recurrent Backup Home On every day @ 01:00 mount /bkhome
Recurrent Backup Home On every day @ 01:01 cp -rauvd /home/al /bkhome
Recurrent Backup Home On every day @ 08:00 umount /bkhome







Notice the command, “cp -rauvd” will copy everything the first time it is used, and only the files which have changed since the last time, on each succeeding use. Also notice on the “root” task that you MUST save the /bkup/etc/fstab BEFORE you update /bkup/etc/fstab, and then restore it AFTER you have updated it. Thus, the addition of '/save' in the '/' directory. Also notice that you will need to give the backup enough time to finish copying large files/directories before you close. The amount of time required will vary depending on the speed of your processor, and the size of the files/directories being copied.
Similar scheduled tasks should be created for the '/wd2' and '/wd3' back-ups if you intend to have them backed up automatically. I did not include them, as they are virtually identical to the ones posted.

In the event of a failed mother board, when you'll be recovering a totally dead system from either your back-up hard drive or the removable drive, you will probably have to boot your new machine from a recovery disk, such as a Debian installation CD or even a Ubuntu Live DVD. Make your backup drive the working partition with the recovery CD, and then mount the new drive in the /mnt directory. Or, make your backup drive the working partition, and invoke;

# grub-install --recheck /dev/sda

Addition of the '--recheck' will provide you with a handy 'map' of your new system, and it will show you which drive your MBR has been installed on, should you have more than one drive.

Something we should keep in mind is that if we delete a file on our primary drive which has been previously copied to our back-up drive, that file STILL exists on the back-up drive. If we uninstall a program which has been previously copied to our back-up drive, that program STILL exists on the back-up drive. In the case of uninstalled programs, it is possible that an old program could cause conflicts with a newer one on your back-up drive after future back-ups. Therefor we should occasionally completely replace EVERYTHING on the back-up drive, and start anew with our back-up schedule.

I hope that this little guide will be helpful. Feedback is welcome and appreciated.

Thanks,
owa