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 scheme.
I
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 | - | j
-
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 send
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
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
.
On 6/28/2010 11:26 AM, Tristram Scott wrote:
[snip]
Tristram
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discu
ss
--
This message posted from opensolaris.org
