Moment-in-time snapshot backups of Linux systems with Data Protector

You can get moment-in-time snapshot backups of Linux systems with Data Protector.

Everybody knows the "Use Shadow Copy" flag for Windows backups gets something very close to a moment-in-time snapshot, but there's a persistent rumour that you can only get a good moment-in-time snapshot of Linux systems if you take a VMware snapshot backup.

If you are backing up a btrfs filesystem (which is supported on the Linux agent: you can see it listed in /opt/omni/.util), then you can use its built-in snapshot capabilities.

But even ext3 and xfs filesystems can do snapshots with the help of the LVM layer. This technique dates back to the early days of HP-UX, but it works on modern Linux boxes (and probably on modern HP-UX boxes as well). You will need to do four steps:

1. Make sure that you have some spare space in the volume group which contains the volumes you are wanting to back up. Use vgdisplay and look for the lines about Free PE (free physical extents).
2. Make a backup specification (through the Data Protector GUI if you want to) including all the filesystems you want. Don't tick the host, tick each of the filesystems, even if you want all of them. In the pre-exec and post-exec fields of the filesystem defaults (not the pre-exec and post-exec for the whole backup job) put snapshot-preexec.sh and snapshot-postexec.sh.
3. Put snapshot-preexec.sh and snapshot-postexec.sh into /opt/omni/lbin. 
4. Edit the backup specification. Look for the lines that say FILESYSTEM "/xxx" ... and replace them with FILESYSTEM "/mnt/backup/xxx" ... The end result should look like Linux-Snapshot-Example

Then you can run the backup as per normal.

The snapshot-preexec.sh script looks at the parent process which spawned it (which will be the vbda process) and finds the -volume parameter. Then it strips off the /mnt/backup part of it, and figures out the logical volume that the original filesystem is mounted on. It calls lvcreate --snapshot, runs fsck and then mounts that snapshot volume. So by the time the vbda process starts trying to read the /mnt/backup/xxx filesystem, the filesystem is mounted.

The snapshot-postexec.sh script cleans up these volumes.

There are two environment variables you can set in the backup specification which snapshot-preexec.sh will make use of.

• SNAPSHOT_PREFIX (which defaults to /mnt/backup)
• SNAPSHOT_SIZE (which defaults to 10m, which means that 10MB worth of block writes can be happen while the backup runs. For a busy filesystem this might be too little.)

Of course, the backups will be recorded as being of /mnt/backup/... which means that disaster recovery won't work properly (because it will never see your root filesystem as being backed up). It's a pity that there isn't an easy way of updating the internal database to make it think that it was a different filesystem backed up.

All in all, it's not that difficult to do. It only took me about an hour to set up. The mysterious thing is that 17 years after I first implemented this on an HP-UX system -- and I wasn't the first to do this -- it's still not out-of-the-box functionality.


Greg Baker is an independent consultant who happens to do a lot of work on HP DataProtector. He is the author of the only published book on HP Data Protector (http://x.ifost.org.au/dp-book). He works with HP and HP partner companies to solve the hardest big-data problems (especially around backup). See more at IFOST's DataProtector pages at http://www.ifost.org.au/dataprotector