I don't disagree that zfs is the better choice, but...
> Seriously though. UFS is dead. It has no advantage
> over ZFS that I'm aware
> of.
>
When it comes to dumping and restoring filesystems, there is still no official
replacement for the ufsdump and ufsrestore. The discussion has been had
> At this point, I will repeat my recommendation about
> using
> zpool-in-files as a backup (staging) target.
> Depending where you
> ost, and how you combine the files, you can achieve
> these scenarios
> without clunkery, and with all the benefits a zpool
> provides.
>
This is another good sch
evik wrote:
Reading this list for a while made it clear that zfs send is not a
backup solution, it can be used for cloning the filesystem to a backup
array if you are consuming the stream with zfs receive so you get
notified immediately about errors. Even one bitflip will render the
stream unusa
>
> if, for example, the network pipe is bigger then one
> unsplitted stream
> of zfs send | zfs recv then splitting it to multiple
> streams should
> optimize the network bandwidth, shouldn't it ?
>
Well, I guess so. But I wonder, what is the bottle neck here. If it is the
rate at which zfs
>
> would be nice if i could pipe the zfs send stream to
> a split and then
> send of those splitted stream over the
> network to a remote system. it would help sending it
> over to remote
> system quicker. can your tool do that?
>
> something like this
>
>s | ->
o. The only way I know of achieving that is by using zfs send etc.
>
> On 6/28/2010 11:26 AM, Tristram Scott wrote:
[snip]
> >
> > Tristram
>
> ___
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
>
For quite some time I have been using zfs send -R fsn...@snapname | dd
of=/dev/rmt/1ln to make a tape backup of my zfs file system. A few weeks back
the size of the file system grew to larger than would fit on a single DAT72
tape, and I once again searched for a simple solution to allow dumping
