What is the downtime for doing a send/receive? What is the downtime
for zpool export, reconfigure LUN, zpool import?
We have a similar situation. Our home directory storage is based on many
X4540s. Currently, we use rsync to migrate volumes between systems, but
our process could very easily be switched over to zfs send/receive (and
very well may be in the near future).
What this looks like, if using zfs send/receive, is we perform an
initial send (get the bulk of the data over), and then at a planned
downtime, do an incremental send to "catch up" the destination. This
"catch up" phase is usually a very small fraction of the overall size of
the volume. The only downtime required is from just before the final
snapshot you send (the last incremental), and when the send finishes,
and turning up whatever service(s) on the destination system. If the
filesystem a lot of write activity, you can run multiple incrementals to
decrease the size of that last snapshot. As far as backing out goes, you
can simply destroy the destination filesystem, and continue running on
the original system, if all hell breaks loose (of course that never
happens, right? :)
When everything checks out (which you can safely assume when the recv
finishes, thanks to how ZFS send/recv works), you then just have to
destroy the original fileystem. It is correct in that this doesn't
shrink the pool, but it's at least a workaround to be able to swing
filesystems around to different systems. If you had only one filesystem
in the pool, you could then safely destroy the original pool. This does
mean you'd need 2x the size of the LUN during the transfer though.
For replication of ZFS filesystems, we a similar process, with just a
lot of incremental sends.
Greg Mason
System Administrator
High Performance Computing Center
Michigan State University
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
