Over the years, my backup strategy with Clonezilla and Lucky Backup have helped me quite a number of times, especially back in January when a notebook under my care was stolen while traveling. With my backup strategy it takes around 30 minutes to restore an image of the system partition on an emergency spare hard drive and a couple of hours to restore the data partition with half a terabyte of data. While I would say that such times are more than acceptable I was not quite happy about the time it takes to restore the data and have now found a simple solution to restore the data partition in just a few minutes as well.
My Current Backup Procedure
To restore my notebook as quickly as possible I have divided my hard drive in two partitions, one for the system and an encrypted partition for the data. Occasionally I make a backup of the system partition using Clonezilla. This only takes a few minutes as only around 10 GB are used. Restoring the system on another hard drive can thus also be done in a few minutes.
As noted above the story is somewhat different for the data partition which in my case currently holds more than 500 GB of data. Making a full backup and restore of such an amount of data takes several hours. This is why I use Lucky Backup and several backup hard drives to perform incremental backups which just takes a few minutes. Lucky Backup is mainly a graphical front end for the fabulous rsync command line program shipped in Linux distributions. Despite only backing up files that have changed, Lucky Backup’s end result is a 1:1 copy of my data on my backup drives that is instantly accessible at all times even without Lucky Backup. In addition, the program provides snapshots of data that has changed or has been deleted in addition to the 1:1 copy.
Speeding Up Data Restoration
As restoring all data takes a long time I’ve now come up with the following addition to this procedure: At all times I keep an emergency spare hard drive ready with a recent copy of the system partition and a fairly recent copy of the data. When I want to use this fully functioning copy of my system I just insert it into another notebook and I have an up and running system apart from the data which is outdated. To bring the data up to the state of the last backup, a single rsync shell command suffices:
rsync --dry-run -h --progress --stats -r -tgo -p -l -D --delete-after --exclude .luckybackup-snaphots/ FROM TO
FROM and TO have to be replaced with the paths of the backup drive (FROM) and the destination directory on the emergency spare hard drive (TO). The dry-run parameter allows to test the restore process and see which files would be updated, created and deleted if the command was run without it. As I have a lot of data which only changes little over time the command only takes a few minutes to execute even if the data partition of the backup disk was not updated for months. Much better than waiting several hours for a full restoration to complete.
With the command line options given above, rsync ensures that the target directory on the emergency spare hard disk is an exact 1:1 copy of what is present on the backup disk. That means that newer files or newly created files on the system will be replaced by older files from the backup or deleted if they were not present on the backup. This is great as it allows me to use the emergency spare drive not only for emergencies but also for experiments that modify the data. In case of an emergency, all changes are reverted to the state of the backup. If this is not desired the –update option keeps modified and new files on the emergency spare hard disk data partition in place and does not replace them with older versions from the data backup.
One thing that needs an additional explanation is the exception given in the command line above. The .luckybackup-snapshots directory contains old versions and copies of deleted files which do not have to be replicated to the emergency backup system.
Note that I didn’t come up with the rsync command options above on my own. Lucky Backup has a nice feature to show which command line it will use for replication which I used as a blueprint to adapt it for this scenario.