On Sun, Jan 17, 2010 at 05:31:39AM -0500, Edward Ned Harvey wrote: > Instead, it is far preferable to "zfs send | zfs receive" ... That is, > receive the data stream on external media as soon as you send it.
Agree 100% - but.. .. it's hard to beat the convenience of a "backup file" format, for all sorts of reasons, including media handling, integration with other services, and network convenience. Consider then, using a zpool-in-a-file as the file format, rather than zfs send streams. Make a backup pool out of N conveniently-sized files, sparse to start with if it suits you. Go ahead and make it a raidz[23] pool, in case some of your backup media goes bad. zfs recv your backups into this pool. zfs export the pool, to quiesce the file contents. If the files are themselves in zfs, snapshot that filesystem now for good measure; then you can immediately bring your backup pool online again, as well as have local reference copies of old backups, as storage space allows. Send these files to whatever backup system/service you want to use. Handle them like any other large archive file format. If you choose file sizes well, you can burn them to dvd's or write them to tapes. Multiple smaller files (rather than one file per medium) can be easier to handle, but its best to make multiple raidz vdevs and arrange a file from each vdev per medium (so you can still recover from a lost dvd/tape). If you have a non-zfs remote storage server, rsync works well to update the remote copies incrementally after each backup cycle (and to bring back older versions later if needed). Lots of cloud backup providers exist now that can do similar incremental replication. gpg sign and encrypt the files before sending, if you need to. Some day soon, zfs crypto will allow backups encrypted within the pool, without defeating incremental replication of the files (as gpg will). Another option is to mount these files directly on whatever generic NAS devices you want to hold the backups, and import the pool from there. I'd be wary, but if you were to consider that, fortunately there's a good testing tool (zfs scrub) to help you be sure the NAS service is reliable. You do need all (or at least most) of your files available in order to do a restore. Given that you should be preferring to use local snapshots for small recovery jobs anyway, that's not really a burden for a full recovery. At this point, you get back all the snapshots that were in the backup pool at the time it was saved. The zfs send stream format used to not be committed, though it appears this has recently changed. It still has all the other drawbacks previously noted. The zpool format is committed and does have a tested and supported backwards compatibility/upgrade path. -- Dan.
pgpmu7bvoOxnf.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
