Joining the parts
That ZFS is a great filesystem, with many, many features, i think everyone agree. But it is not perfect, and that is the nice thing about open source software and communities: we can help with a little part, make a tiny contribution, and that makes the whole difference in the end. And i think backup procedure for ZFS needs some love…
Thinking about a backup solution for ZFS, i’m using the excellent SMF service by Tim Foster (autosnapshot). It’s pretty stable (0.10), and do handle the snapshots creation/deletion very well. But the backup function is not so good… so, i did take a look at the ZFS replicator script by Constantin, and the new one with contributions by Mike Hallock. I did some minor, really two or three lines patch to the ZFS replicator script (basically to add my log style, and the “-R” ZFS send option), and here you can get it.
The “-R” option is not present on Solaris 10, and i think was nice the decision Constantin did for not put features not present in Solaris 10, so you can just search for it in the script, and remove it. But you should know that without it the pool and filesystems properties are not preserved. I think this option must be backported to Solaris 10.
The last part i did was create a “manager” script that act like a wrapper for the ZFS replicator. More one time i did write it just to enhance the logging, and to make the cron line more simple. With it you need just the following line in crontab (for each pool you want to backup):
0 * * * * /usr/local/bin/replica -M srcpool -R targetpool -H destinationhost
I still handle the exclusion of the pool itself in the replication procedure, because if you don’t, you will get errors after the first replication. So, i just replicate the filesystems. Another change was made to handle a server with more than one pool (just the pool requested will be replicated). Two log files will be created in “/var/log/backup/“: replica-poolname.`date`.log, and zfs-replicate.`date`.log. Would be nice if the ZFS send command could give some statistics at the end, but it does not. Then, with the timestamps i did add to each send task, we can implement a “posreplication” report to monitor our backup performance (todo). To use this solution, just put the both scripts in “/usr/local/bin“, and create the directories “/var/log/backup“, and “/var/backup/run“.
That is my two cents, i hope it can help somebody else, and we can improve the ZFS backup procedure a lot more…
peace
Now think about what you wrote: ZFS, for better or for worse, is only available on FreeBSD and on Solaris. No other UNIX has it. Let’s say that you invest the time to perfect the backup, and that you get it working correctly, the way you want it to.
But what to do with the other 17000 UNIX systems, like AIX and HP-UX, that DON’T have ZFS? So every one of those would have their own backup solution?
Wouldn’t the correct way to solve this be to first get ZFS working across as many platforms as possible, then concentrate on a unified backup methods?
Oh yeah, and what of other solutions, like Oracle ASM? I can’t use ZFS snapshots for those!
As innovative and as good as ZFS snapshot and backup facilities are, in a heterogenous environment, it’s next to useless.
At least until it’s available on enough platforms, to provide some semblance of consistency.
A simple package to make the things a little easier…
https://www.eall.com.br/hp/Solaris/MRSLzfsreplicate.tar.gz
Leal.