Up to the moderator whether this will add anything:
I dedicated the 2nd NICs on 2 V440s to transport the 9.5TB ZFS between
SANs. configured a private subnet & allowed rsh on the receiving V440.
command: zfs send | (rsh <receiving-host> zfs receive ...)
Took a whole week (7 days) and brought the receiving host's networking
down to unusable. Could not ssh in to the first NIC, as the host would
not respond before timing out. Some Oracle db connections stayed up,
but were horribly slow. Gigabit Ethernet on a nice fast Cisco 4006
switch. Solaris 10, update 5 sending to Solaris 10 update 3, both V440s.
I'm not going to do this ever again, I hope, so I'm not concerned with
the why or how, but it was pretty bad. Seems like a zfsdump would be a
good thing.
--
David Strom
On 1/13/2011 11:46 AM, David Magda wrote:
On Thu, January 13, 2011 09:00, David Strom wrote:
Moving to a new SAN, both LUNs will not be accessible at the same time.
Thanks for the several replies I've received, sounds like the dd to tape
mechanism is broken for zfs send, unless someone knows otherwise or has
some trick?
I'm just going to try a tar to tape then (maybe using dd), then, as I
don't have any extended attributes/ACLs. Would appreciate any
suggestions for block sizes for LTO5 tape drive, writing to LTO4 tapes
(what I have).
Might send it across the (Gigabit Ethernet) network to a server that's
already on the new SAN, but I was trying to avoid hogging down the
network or the other server's NIC.
I've seen examples online for sending via network, involves piping zfs
send over ssh to zfs receive, right? Could I maybe use rsh, if I enable
it temporarily between the two hosts?
If you don't already have a backup infrastructure (remember: RAID !=
backup), this may be a good opportunity. Something like Amanda or Bacula
is gratis, and it could be useful for other circumstances.
If this is a one-off it may not be worth it, but having important data
without having (offline) backups is usually tempting fate.
If you're just going to go to tape, then suntar/gnutar/star can write
directly to it (or via rmt over the network), and there's no sense
necessarily going through dd; 'tar' is short for TApe aRchiver after all.
(However this is getting a bit OT for ZFS, and heading towards general
sysadmin related.)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss