ZFS backups: retrieving a few files?

David Magda dmagda at ee.ryerson.ca
Tue Nov 23 02:06:59 UTC 2010

On Nov 22, 2010, at 17:13, Andrew Reilly wrote:

>> The currently accepted practice is to create a ZFS file system on the
>> backup drive and just keep sending incremental snapshots to it.  As  
>> long
>> as the backup drive and host system have a snapshot in common you  
>> can do
>> incremental transfers.  This way you only have to keep the most  
>> recent
>> snapshot on the main system and can keep as many as you have space  
>> for
>> on the backup drive.  You also have direct access to any backed up
>> version of every file.
> That sounds like a very cool notion.  Not unlike the
> time-machine scheme.  Interesting how different capabilities
> require going back and re-thinking the problem, rather than just
> trying to implement the old solution with the new tools.

As noted, saving the output of "zfs send" isn't very useful and  
generally not recommended as  a backup mechanism. It's come up quite  
often on Sun/Oracle's zfs-discuss list:


In addition to regular snapshots, also make sure to have an offline  
backup of some kind (tar, Networker, NetBackup, Amanada, etc.). Errors  
can propagate to online copies / backups, and if an intruder can  
penetrate your primary system, there's a good chance they can get to  
the secondary copy of your data; penetrating a tape on a shelf over  
the network would be much more challenging. :)

Newer versions of ZFS also support a "zfs diff" command, but I'm not  
sure if that functionality has made it into FreeBSD yet:


Combine "diff" with some snapshots and scripting, and you can speed up  
things like tar and rsync a lot since you don't have to traverse the  
entire file system to find changes.

And at the end of the day remember it's not about about backups, but  
about restores. If you can't restore coherent data in a timely manner  
it's pointless.

More information about the freebsd-stable mailing list