Hi, I really don't like cross-posts, so this answer only goes to zfs-discuss. A possible workaround: redirect the 'zfs send' to a local file and transfer this file by a mechanism that is able to do a resume (e.g. rsync).
Gruß Jan Dreyer -----Original Message----- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Peter Jeremy Sent: Monday, March 28, 2011 11:47 PM To: Roy Sigurd Karlsbakk Cc: ZFS Discussions; Discussion list for OpenIndiana; Illumos Developers Subject: Re: [zfs-discuss] zfs incremental send? On 2011-Mar-29 02:19:30 +0800, Roy Sigurd Karlsbakk <r...@karlsbakk.net> wrote: >Is it (or will it) be possible to do a partial/resumable zfs >send/receive? If having 30TB of data and only a gigabit link, such >transfers takes a while, and if interrupted, will require a re-transmit >of all the data. zfs send/receive works on snapshots: The smallest chunk of data that can be sent/received is the delta between two snapshots. There's no way to do a partial delta - defining the endpoint of a partial transfer or the starting point for resumption is effectively a snapshot. For an initial replication of a large amount of data, the most feasible approach is probably to temporarily co-locate the destination disk array with the server to copy the data across. You can reduce the size of each incremental chunk by taking frequent snapshots (these can be deleted once they have been replicated to the backup host). -- Peter Jeremy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
