On Tue, March 29, 2011 07:39, Richard Elling wrote: > On Mar 29, 2011, at 3:10 AM, Roy Sigurd Karlsbakk <r...@karlsbakk.net> > wrote: > >> ----- Original Message ----- >>> 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. >> >> 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, d...@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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
