Back(Up) to the Future

Ah, backups… What a nice boring topic! Everyone agrees on the fact that a strong backup procedure is mandatory for any computer (server, workstation, PDA or anything else which carry data). But lot of us also agree to say that backup are so boring to perform and, even more, maintain! To the question “Do you have a backup procedure?“, most of us will be proud to say “Yes!“. And about your restore procedure? 😉

For my private activities, I own a Macbook Air and I’m addicted to the Apple backup system called “Time Machine“. There is certainly no ideal backup solution but it does its job quite well and… without user interaction! Time Machine saves my data using a SMB share on a RAID-1 NAS using an automated procedure: mount the SMB share if I’m at home, perform the backup and umount it. Time Machine is based on the principle of incremental backups. Only the data changed since the last backup are saved.

I was looking for the same kind of solution for my Linux laptops. Google gave me three names: TimeVault, flyback and Back In Time. They are all based on the principle of “snapshots“. When a backup is performed, the unchanged files are just backuped as a symbolic link to the previous backup – without consuming disk space.

TimeVault has a deep integration with Nautilus. Unfortunately, the project looks abandoned and no 64-bits package is provided. This can look stupid but I don’t have time to compile big projects from the source code and I don’t want to install a full Gnome development environment on my laptops. That’s a reason why I use Ubuntu: to use packages!

flyback looks still maintained even if the last update has been released a few months ago. Unfortunately, flyback has been immediately set aside due to a major feature missing: backups must be started manually!

Back In Time has been inspired, as explained on the website, by the two first solutions. Basically, Back In Time is a front-end to manage backups performed using strong UNIX tools like rsync and diff (amongst others). The main window presents the available snapshots and allow to restore your data:

To configure a backup, several profiles can be created. A profile is just a set of  core parameters :

• The directory to backup
• The filesystem (destination) where the snapshot will be stored
• When perform the backup
• The files to include/exclude (based on regular expressions)
• Snapshot maintenance (how long to keep them)
• Performance related parameters (use of the “nice” command etc…)

Once a profile has been defined, a corresponding entry is added to the user’s crontab.  Cool stuff, there is an integration with Gnome: When a backup is running, an icon is display in your notification area. The availability of the destination path is performed at backup start. If the directory is not present, the backup is simply aborted.

But the feature which made me choose Back In Time as my backup solution is the “user-callback” script (located in your $HOME/.config/backintime). This script is called several times during the backup process with the following arguments:

  $HOME/.sysconfig/backintime/user-callback <profileID> \
                                            <profileName> \
                                            <Reason> [Error]

<Reason> is an integer:

1. Backup process begins.
2. Backup process ends.
3. A new snapshot was taken. The extra arguments are snapshot ID and snapshot path.
4. There was an error. The second argument is the error code:
   • The application is not configured
   • A “take snapshot” process is already running.
   • Can’t find snapshots directory (is it on a removable drive ?).
   • A snapshot for “now” already exist.

Based on those information, you are free to add your own features to Back In Time like:

• To kill a process before a backup and restar it once done, sending
• To send notifications to a monitoring tool,
• To mount a filesystem dedicated to the snapshots and much more!
• Use your imagination!

As Back In Time does not try to mount the destination filesystem by itself, here is an example of a user-callback script which (u)mount the required volume:

  #!/bin/bash
  # Get arguments from command line
  PROFILEID=$1
  PROFILENAME=$2
  REASON=$3
  ERRORCODE=$4

  LOG="/var/log/backintime-user-callback.log"
  NOW=`date +"%Y-%m-%d %H:%M:%S"`
  LOCALIP="192.168.254.200"
  INT=eth0
  MYIP=`ifconfig $INT | grep 'inet addr:' | cut -d: -f2 | awk '{ print $1}'`

  echo "$NOW Profile=$PROFILEID ($PROFILENAME), reason $REASON:$ERRORCODE" >>$LOG
  case $REASON in
    "1") # Backup process started
         if [ "$MYIP" == "$LOCALIP" ]; then
           # Try to mount the local NFS share
           /bin/mount /media/backup
         fi
         ;;
    "2") # Backup process ended
         if [ "$MYIP" == "$LOCALIP" ]; then
           # Try to umount the local NFS share
           /bin/umount /media/backup
         fi
         ;;
    "3") # New snapshot taken
         ;;
    "4") # Error detected
         ;;
      *) # Unknown reason
         ;;
esac
exit 0

Just by sending some backup information into a dedicated logfile or to your Syslog host via the “logger” command, you add more value to the backup by processing those events via your log management tool. Tools like “Time Machine” or “Back In Time” are easy to deploy and help you to restore lost file at a certain point. Very useful if you work on projects with a lot of files updated regularly.