On Tue, May 3 at 17:39, Rich Teer wrote:
Hi all,
I'm playing around with nearline backups using zfs send | zfs recv.
A full backup made this way takes quite a lot of time, so I was
wondering: after the initial copy, would using an incremental send
(zfs send -i) make the process much quick because only the stuff that
had changed between the previous snapshot and the current one be
copied? Is my understanding of incremental zfs send correct?
Your understanding is correct. We use -I, not -i, since it can send
multiple snapshots with a single command. Only the amount of changed
data is sent with an incremental 'zfs send'.
Also related to this is a performance question. My initial test involved
copying a 50 MB zfs file system to a new disk, which took 2.5 minutes
to complete. The strikes me as being a bit high for a mere 50 MB;
are my expectation realistic or is it just because of my very budget
concious set up? If so, where's the bottleneck?
Our setup does a send/recv at roughly 40MB/s over ssh connected to a
1gbit/s ethernet connection. There are ways to make this faster by
not using an encrypted transport, but setup is a bit more advanced
than just an ssh 'zfs recv' command line.
The source pool is on a pair of 146 GB 10K RPM disks on separate
busses in a D1000 (split bus arrangement) and the destination pool
is on a IOMega 1 GB USB attached disk. The machine to which both
pools are connected is a Sun Blade 1000 with a pair of 900 MHz US-III
CPUs and 2 GB of RAM. The HBA is Sun's dual differential UltraSCSI
PCI card. The machine was relatively quiescent apart from doing the
local zfs send | zfs recv.
I'm guessing that the USB bus and/or the USB disk is part of your
bottleneck. UltraSCSI should be plenty fast and your CPU should be
fine too.
--eric
--
Eric D. Mudama
edmud...@bounceswoosh.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
