Backing up Solaris[TM] ZFS file systems

Applies to:
Solaris SPARC Operating System - Version: 8.0 and later [Release: 8.0 and later ] Solaris SPARC Operating System - Version: 8.0 and later [Release: 8.0 and later] All Platforms

Goal
What is the best practice for backing up Solaris ZFS file systems?

Solution
Steps to Follow Solaris ZFS changes the way that file systems can be managed. For many situations the ideal solution for back up is to use regular snapshots and to then keep these snapshots so that users have online access to any files that are accidentally deleted or damaged. This then removes the need to recover individual files from backup as they are now stored online. Combined with using RAID in the form of RAIDZ, RAID2Z or mirrors to protect from hardware failure reduces the need for backup even further. However even with all this protection you still want to have a backup in case of a disaster.

Backing up a Solaris ZFS file system

Whilst not a hard rule the principle reason for backing up file systems is not usually disaster recovery. Rather it is for user error or application failure that results in the loss of or corruption of files. Since ZFS has very cheap snapshots that reason is often not required anymore. Traditionally this is handled by using ufsdump(1M). If you can keep the snapshots online then you do not require a back up that provides more than the option to recover the whole file system. If you are unable or unwilling to keep snapshots on line then you should let an enterprise back up solution take care of your backups.

Backing up using built in Solaris commands

Using cpio(1), tar(1) or pax(1)
Now that we have snapshots it is best that the back up software back up the snapshot rather than the actual file system. This removes the dangers of file changing while the backup is running. An example of a script that could be used to take snapshots and back them up using cpio would be:
#!/bin/ksh -p function do_path { typeset mount_point while read mount_point do echo ${mount_point#/}/$1 done } unset cdpath PATH=/usr/bin:/usr/sbin export PATH cd / typeset -Z8 random random=$RANDOM now=$(date +%Y%m%d%H%M%S) snap_name=backup_$now$random pools=${1:-$(zpool list -H -o name)} for pool in $pools do zfs snapshot -r ${pool}@$snap_name || exit 1 done find $( zfs list -H -o mountpoint -r -t filesystem ${1:-$(zpool list -H -o name)} | \ do_path .zfs/snapshot/$snap_name) -size \ -$(((8 * 1024 *1024 *1024) - 1))c -depth -print |\ cpio -o -v -P -@ -H ustar${TAPE:+ -C $((1024 *128)) -O ${TAPE}} exit $?

Similar scripts can be written for using tar(1) or pax(1) depending on the functionality you require. cpio(1) has the advantage that is can support multiple tapes however if you need multiple tape support you should look to use an Enterprise back up solution. Then you can restore the files using pax(1) which can strip out the extra path components that get added due to being part of a snapshot. EG:
pax -r -s '/.zfs\/snapshot\/backup_2007051010180900023201//' \ -b $((1024 *128)) -v -x ustar < $TAPE

Using zfs send and zfs receive

You can back up zfs snapshots using zfs send and restore them using zfs receive. As zfs send can be used to create incremental backups these commands look like a good way to back up a pool and then restore the whole pool back to the state that it was in. If you use these commands to back up to another storage pool then you can have rolling incremental backups. Indeed there are scripts that will do exactly that and example of which can be found on Chris Gerhard's blog.

Backing up using enterprise back up solutions

Sun Storege Enterprise Backup 7.3.2 supports backing up of ZFS file systems including the ACLS. See Document 1012843.1 for details of how to use that software to back up ZFS filesystems using snapshots.

Backing up a whole pool

If you have a mirrored pool with only one zdev then you could use a hardware RAID device that supports snapshotting to take a snapshot of the entire pool (one side of the mirror would be a copy of the entire pool).