On Wed, Jun 30, 2010 at 12:54:19PM -0400, Edward Ned Harvey wrote: > If you're talking about streaming to a bunch of separate tape drives (or > whatever) on a bunch of separate systems because the recipient storage is > the bottleneck instead of the network ... then "split" probably isn't the > most useful way to distribute those streams. Because "split" is serial. > You would really want to "stripe" your data to all those various > destinations, so they could all be writing simultaneously. But this seems > like a very specialized scenario, that I think is probably very unusual.
At this point, I will repeat my recommendation about using
zpool-in-files as a backup (staging) target. Depending where you
host, and how you combine the files, you can achieve these scenarios
without clunkery, and with all the benefits a zpool provides.
1 - Create a bunch of files, sized appropriately for your eventual backup
media unit (e.g. tape).
2 - make a zpool out of them, in whatever vdev arrangement suits your
space and error tolerance needs (plain stripe or raidz or both).
Set compression, dedup etc (encryption, one day) as suits you, too.
3 - zfs send | zfs recv into this pool-of-files. rsync from non-zfs
hosts, too, if you like.
4 - scrub, if you like
5 - write the files to tape, or into whatever file-oriented backup
solution you prefer (perhaps at a less frequent schedule than
sends).
6 - goto 3 (incremental sends for later updates)
I came up with this scheme when zpool was the only forwards-compatible
format, before the send stream format was a committed interface too.
However, there are still several other reasons why this is preferable
to backing up send streams directly.
--
Dan.
pgpEHsmYFFyjp.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
