Hi all I have a few boxes with rather large amounts of data on ZFS, and so far, it''s been working quite well. Now, one little problem is mentioned every now and then. 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. What could make a partial transfer work? Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 roy at karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et element?rt imperativ for alle pedagoger ? unng? eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer p? norsk.
On 2011-Mar-29 02:19:30 +0800, Roy Sigurd Karlsbakk <roy at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110329/822f1788/attachment.bin>
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-bounces at opensolaris.org [mailto:zfs-discuss-bounces at 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 <roy at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5011 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110329/4415c9c1/attachment.bin>
----- Original Message -----> On 2011-Mar-29 02:19:30 +0800, Roy Sigurd Karlsbakk > <roy at 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.I know that''s how it works, I''m merely pointing out that changing this to something resumable would be rather nice, since an initial transfer or 30 or 300 terabytes may easily be interrupted. Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 roy at karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et element?rt imperativ for alle pedagoger ? unng? eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer p? norsk.
Richard Elling
2011-Mar-29 12:39 UTC
[zfs-discuss] [illumos-Developer] zfs incremental send?
On Mar 29, 2011, at 3:10 AM, Roy Sigurd Karlsbakk <roy at karlsbakk.net> wrote:> ----- Original Message ----- >> On 2011-Mar-29 02:19:30 +0800, Roy Sigurd Karlsbakk >> <roy at 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. > > I know that''s how it works, I''m merely pointing out that changing this to something resumable would be rather nice, since an initial transfer or 30 or 300 terabytes may easily be interrupted.In the UNIX tradition, the output and input are pipes. This allows you to add whatever transport you''d like for moving the bits. There are many that offer protection against network interruptions. Look for more, interesting developments in this area soon... -- richard>
David Dyer-Bennet
2011-Mar-30 16:15 UTC
[zfs-discuss] [illumos-Developer] zfs incremental send?
On Tue, March 29, 2011 07:39, Richard Elling wrote:> On Mar 29, 2011, at 3:10 AM, Roy Sigurd Karlsbakk <roy at karlsbakk.net> > wrote: > >> ----- Original Message ----- >>> On 2011-Mar-29 02:19:30 +0800, Roy Sigurd Karlsbakk >>> <roy at 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. >> >> I know that''s how it works, I''m merely pointing out that changing this >> to something resumable would be rather nice, since an initial transfer >> or 30 or 300 terabytes may easily be interrupted. > > In the UNIX tradition, the output and input are pipes. This allows you to > add whatever transport you''d like for moving the bits. There are many that > offer protection against network interruptions. Look for more, interesting > developments in this area soon...Name three :-). I don''t happen to have run into any that I can remember. And in any case, that doesn''t actually help my situation, where I''m running both processes on the same box (the receive is talking to an external USB disk that I disconnect and take off-site after the receive is complete). A system crash (or power shutdown, or whatever) during this process seems to make the receiving pool unimportable. Possibly I could use recovery tricks to step back a TXG or two until I get something valid, and then manually remove the snapshots added to get back to the initial state, and then I could start the incremental again; in practice, I haven''t made that work, and just do another full send to start over (7 hours, not too bad really). Anyway, the incremental send/receive seems to be the fragile point in my backup scheme as well. -- David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info