We talked about this a bit via email, and I’m thinking I don’t really want to incorporate the patch into this code. My thinking was two-fold – first, I’m not sure I’d really want clients futzing with the backup server: let the backup server admin decide what they want to do with the backups as they roll in.
Next, if you have a few hundred clients all running the ZFS Automatic Snapshots service, and you add diskspace to your backup server, you then perhaps need to change each client, in order to tell it not to destroy server-side backups any more.. Centralised administration, yeah?
Now, on the other hand, if we had a means of accessing a remote SMF repository, the client’s zfs/backup-destroy-cmd could be retrieved from the backup server, properly allowing centralised administration of this feature.
Anyway, I think it’s waay cool that Mika’s thought about this and published his patch – he’s got a two-server setup, where he wants backups from one machine to be copied over to the other machine, but also destroyed periodically. Not a backup server, so much as a “poor-man’s cluster” (as Mika so eloquently put it) – so if you don’t want to setup an actual cluster (for free!), then Mika’s patch might be what you’re after!
Update: Of course, I should also mention this thread, which talks about actual clustering using ZFS..
(as shipped, ZFS is not a clustered filesystem, don’t plug a zfs pool into two hosts simultaneously, and expect it to work. more here and here)