First of all, I must apologize. I''m an OpenSolaris newbie so please don''t be too hard on me. Sorry if this has been beaten to death before, but I could not find it, so here goes. I''m wanting to be able to have two disk servers that I replicate data between using send / receive with snapshots. Yes, I know that is simple enough, but what happens when the primary server goes down and I actually need to make changes to the secondary? Can I then replicate the data back to the primary server without starting over? TIA. -- This message posted from opensolaris.org
On Feb 10, 2010, at 10:31 AM, Terry Hull wrote:> First of all, I must apologize. I''m an OpenSolaris newbie so please don''t be too hard on me.[phasers on stun]> Sorry if this has been beaten to death before, but I could not find it, so here goes. I''m wanting to be able to have two disk servers that I replicate data between using send / receive with snapshots. Yes, I know that is simple enough, but what happens when the primary server goes down and I actually need to make changes to the secondary? Can I then replicate the data back to the primary server without starting over? TIA.Yes. However, when you replicate back to the primary, you will need the last common snapshot to exist on the primary and any data written on the primary since the last common snapshot will be eliminated. If this is not what you want, then you should look at software designed to do remote replication -- something like AVS. -- richard
Thanks for the info. If that last common snapshot gets destroyed on the primary server, it is then a full replication back to the primary server. Is that correct? -- Terry -- This message posted from opensolaris.org
On Feb 10, 2010, at 1:38 PM, Terry Hull wrote:> Thanks for the info. > > If that last common snapshot gets destroyed on the primary server, it is then a full replication back to the primary server. Is that correct?If there are no common snapshots, then the first question is "how did we get here?" :-) In other words, at some point you could say that the primary is effectively gone and begin anew with data from the secondary. When I setup such systems, I try to make sure there is at least several common snapshots at the primary, secondary, and tertiary sites. -- richard
On Wed, Feb 10, 2010 at 3:38 PM, Terry Hull <tah at nrg-inc.com> wrote:> Thanks for the info. > > If that last common snapshot gets destroyed on the primary server, it is > then a full replication back to the primary server. Is that correct? > > -- > Terry > >I think a better way of stating it is that it picks the newest common snapshot. EG: primary has: 1pm 2pm 3pm 4pm 5pm 6pm 7pm 8pm 9pm secondary has: 1pm 2pm 3pm 4pm 5pm 6pm 7pm 8pm 9pm 10pm 11pm So when you go to replicate back, it will see that 9pm is the newest shared snapshot both have, and start replicating all changed blocks after that point. If 9pm goes away, it would use 8pm instead, if 8pm is gone... etc. If you had moved to the secondary, but for some reason get the primary up and had snapshots through say, 10am the next day, everything after the 11pm snapshot on the primary would be deleted. --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100210/289ce346/attachment.html>
On Wed, February 10, 2010 16:15, Tim Cook wrote:> On Wed, Feb 10, 2010 at 3:38 PM, Terry Hull <tah at nrg-inc.com> wrote: > >> Thanks for the info. >> >> If that last common snapshot gets destroyed on the primary server, it is >> then a full replication back to the primary server. Is that correct? >> >> -- >> Terry >> >> > > I think a better way of stating it is that it picks the newest common > snapshot.That can''t be right, zfe send-receive communicate unidirectionally, so nobody can "pick" the newest common snapshot. -- 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
On Wed, Feb 10, 2010 at 4:31 PM, David Dyer-Bennet <dd-b at dd-b.net> wrote:> > On Wed, February 10, 2010 16:15, Tim Cook wrote: > > On Wed, Feb 10, 2010 at 3:38 PM, Terry Hull <tah at nrg-inc.com> wrote: > > > >> Thanks for the info. > >> > >> If that last common snapshot gets destroyed on the primary server, it is > >> then a full replication back to the primary server. Is that correct? > >> > >> -- > >> Terry > >> > >> > > > > I think a better way of stating it is that it picks the newest common > > snapshot. > > That can''t be right, zfe send-receive communicate unidirectionally, so > nobody can "pick" the newest common snapshot. > >I have no idea what you''re talking about. If there was no ability to pick a common snapshot, or to figure out which snapshots are common, there would be no incremental zfs send at all. Directly from the zfs documentation: Generate a replication stream package, which will replicate the specified filesystem, and all descendent file systems, up to the named snapshot. When received, all properties, snapshots, descendent file systems, and clones are preserved. *If the -i or -I flags are used in conjunction with the -R flag, an incremental replication stream is generated. The current values of properties, and current snapshot and file system names are set when the stream is received.* If the -F flag is specified when this stream is received, snapshots and file systems that do not exist on the sending side are destroyed. --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100210/0bbeec8d/attachment.html>
On Wed, February 10, 2010 16:51, Tim Cook wrote:> On Wed, Feb 10, 2010 at 4:31 PM, David Dyer-Bennet <dd-b at dd-b.net> wrote: > >> >> On Wed, February 10, 2010 16:15, Tim Cook wrote: >> > On Wed, Feb 10, 2010 at 3:38 PM, Terry Hull <tah at nrg-inc.com> wrote: >> > >> >> Thanks for the info. >> >> >> >> If that last common snapshot gets destroyed on the primary server, it >> is >> >> then a full replication back to the primary server. Is that correct? >> >> >> >> -- >> >> Terry >> >> >> >> >> > >> > I think a better way of stating it is that it picks the newest common >> > snapshot. >> >> That can''t be right, zfe send-receive communicate unidirectionally, so >> nobody can "pick" the newest common snapshot. >> >> > I have no idea what you''re talking about. If there was no ability to pick > a > common snapshot, or to figure out which snapshots are common, there would > be > no incremental zfs send at all. Directly from the zfs documentation: > > Generate a replication stream package, which will replicate the specified > filesystem, and all descendent file systems, up to the named snapshot. > When > received, all properties, snapshots, descendent file systems, and clones > are > preserved. > > *If the -i or -I flags are used in conjunction with the -R flag, an > incremental replication stream is generated. The current values of > properties, and current snapshot and file system names are set when the > stream is received.* If the -F flag is specified when this stream is > received, snapshots and file systems that do not exist on the sending side > are destroyed.That''s all about *ME* picking the suitable base snapshot, as I understand it. I understood the recent reference to be suggesting that I didn''t have to, that zfs would figure it out for me. Which still appears to me to be impossible; the receive node cannot communicate with the sending node (not only is the normal pipe unidirectional, but in fact the data can be stored in a file and then read by a receive process later, when the sender isn''t even running). -- 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
On Wed, Feb 10, 2010 at 05:36:10PM -0600, David Dyer-Bennet wrote:> That''s all about *ME* picking the suitable base snapshot, as I understand > it.Correct.> I understood the recent reference to be suggesting that I didn''t have > to, that zfs would figure it out for me. Which still appears to me to be > impossible; the receive node cannot communicate with the sending nodeCorrect. There is, however, a wrinkle: if you have src at foo src at bar src at baz dst at foo dst at bar and you do a send -RI src at foo src at baz then you well send both @foo->@bar and @bar->@baz However, the receiver will skip over the @foo->@bar part of the stream, since it already has @bar, and pick up receiving @bar->@baz. This doesn''t save you read or network traffic, but does save you write traffic and having to be exactly correct about picking the right base. -- Dan. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100211/598fc99c/attachment.bin>
On 2/10/2010 7:21 PM, Daniel Carosone wrote:> On Wed, Feb 10, 2010 at 05:36:10PM -0600, David Dyer-Bennet wrote: > >> That''s all about *ME* picking the suitable base snapshot, as I understand >> it. >> > Correct. > > >> I understood the recent reference to be suggesting that I didn''t have >> to, that zfs would figure it out for me. Which still appears to me to be >> impossible; the receive node cannot communicate with the sending node >> > Correct. > > There is, however, a wrinkle: if you have > > src at foo > src at bar > src at baz > > dst at foo > dst at bar > > and you do a send -RI src at foo src at baz > > then you well send both @foo->@bar and @bar->@baz > > However, the receiver will skip over the @foo->@bar part of the > stream, since it already has @bar, and pick up receiving @bar->@baz. > > This doesn''t save you read or network traffic, but does save you write > traffic and having to be exactly correct about picking the right base. >Ah. Okay, that''s obviously technically possible (good thing, since it apparently actually happens). I wasn''t considering that possibility because I was thinking of sending everything *from the beginning*; the overhead of sending all that stuff that hasn''t changed in my situation is 5 or so orders of magnitude, not to be seriously considered. But I see how it could indeed be useful in theory to send just a *little* extra if you weren''t sure quite what was needed but could guess pretty closely. Thanks! -- 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
On Wed, Feb 10, 2010 at 10:48:57PM -0600, David Dyer-Bennet wrote:> But I see how it could indeed be useful in > theory to send just a *little* extra if you weren''t sure quite what was > needed but could guess pretty closely.I think it''s mostly for the benefit of retrying the same command, if a send|recv breaks partway (and you''re not sure where). recv is atomic, but only per dataset/snapshot - not for a whole send -R stream. Note it will also break if there are intermediate snapshots missing on the source, but still on the destination, since it will only skip incrementals that match what it already has. recv -F may "help" here. -- Dan. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100211/1a97fa8f/attachment.bin>