Bug #11847

Replication task

Added by Roger Hayter almost 6 years ago. Updated almost 4 years ago.

No priority
Dru Lavigne
Reason for Closing:
Reason for Blocked:
Needs QA:
Needs Doc:
Needs Merging:
Needs Automation:
Support Suite Ticket:
Hardware Configuration:
ChangeLog Required:


For top level dataset A on PUSH pool p1, set up a snapshot task for p1/A

On PULL with pool p2, and a toplevel dataset backup already created and used for various things, create a dataset A, p2/backup/A

Set up a replication task on PUSH for p1/A, with the tickbox for initialise on first run ticked, destination p2/backup

It then starts replicating A snapshots on PUSH to p2/backup/A on PULL without further intervention.

I expect it would work using the destination p2/A, but I prefer not to put my replicated snapshots in the main pool on PULL, so I can't easily test this.

Previously the step of creating p2/backup/A was done by the replication task, as long as p2/backup already existed, but it now appears to be necessary to do it manually.

The guide does not suggest that the top level of the replicated snapshot (pool or dataset name) has to be manually created on PULL for the replication task to work, and, especially for those who have used the previous replication task, this is not obvious.

autorepl-initial-replication-fix.patch (1.1 KB) autorepl-initial-replication-fix.patch Richard Kojedzinszky, 10/09/2015 12:14 AM

Associated revisions

Revision 37479bde (diff)
Added by Dru Lavigne over 5 years ago

Fix grammo. Fixes #11847.


#1 Updated by Dru Lavigne almost 6 years ago

  • Status changed from Unscreened to 15
  • Assignee changed from Dru Lavigne to Xin Li

Xin, can you comment on this so that the docs can be updated correctly? The current replication docs are here:

#2 Updated by Roger Hayter almost 6 years ago

  • Seen in changed from Unspecified to 9.3.1-STABLE-201509282017

#3 Updated by Richard Kojedzinszky almost 6 years ago

And earlier versions of freenas created the destination dataset as well. If replicating a zvol for example, one may expect that the replication process create the remote dataset with exactly the same parameters as the source.

#4 Updated by Richard Kojedzinszky almost 6 years ago

The attached patch fixes the first-time replication.

#5 Updated by Joe Maloney almost 6 years ago

I just bought a new server from IX, and couldn't figure out why replication wasn't working. This was the culprit for me as well.

#6 Updated by Dru Lavigne almost 6 years ago

  • Status changed from 15 to Investigation
  • Assignee changed from Xin Li to Dru Lavigne

#7 Updated by Roger Hayter almost 6 years ago

Just a comment. I do not know if the behaviour is different if the whole pool on PUSH is to be replicated. I suspect it is different, as the old replication task did not use the name of the PUSH dataset at all, just inserted it in either the PULL root pool or an allocated dataset on PULL, whichever was requested, allowing the whole pool snapshot to adopt the name of the pool or dataset it was replicated to. Whereas if you replicate a snapshot of a child dataset on PUSH, it requires you to create, on PULL, a dataset of the same name as the PUSH dataset you are replicating below the PULL path inserted in the GUI task. At least I believe it does.

Reading 8.3.2 in the guide it is unclear as to any difference between replicating the whole pool or replicating a child dataset of the the pool. The first paragraphs refer to duplicating a dataset, but lower down in 8.3.2 it refers to "the initial replication can take a significant period of time, from many hours to possibly days, as the structure of the entire ZFS pool needs to be recreated on the remote system.", referring to a whole pool replication.

I think you need to establish whether a whole pool replication is indeed treated differently (I can't check now as it would be too destructive to my setup), and then carefully distinguish the two cases, starting with distinguishing the two different choices of snapshot task needed to implement the replication. Then add the need to create the destination dataset in one case.

#8 Updated by Roger Hayter almost 6 years ago

Line two above I mean "the name of the PUSH pool" - sorry!

#9 Updated by Roger Hayter almost 6 years ago

Sorry, another useful comment! In table 8.2a in the guide under "Lifetime" it says "if the snapshot is replicated, it is not removed from the receiving system when the lifetime expires" That is now a successful option in the replication task again so it may or may not be removed at the user's choice.

#10 Updated by Roger Hayter almost 6 years ago

And a typo in table 8.2a. Under 'Enabled" it refers to "the scheduled replication task" when it should refer to "the scheduled snapshot task".

#11 Updated by Jordan Hubbard over 5 years ago

Is this still applicable?

#12 Updated by Roger Hayter over 5 years ago

I'm afraid I am not brave enough to test this all again now my home system is saving and replicating all my live data. (But the typo in Table 8.2a is still there.)

#13 Updated by Dru Lavigne over 5 years ago fixes the Table error.

I have still not recieved an answer on your original question so no changes there.

#14 Updated by Dru Lavigne about 5 years ago

  • Status changed from Investigation to Resolved

#15 Updated by Dru Lavigne almost 4 years ago

  • Target version set to Master - FreeNAS Nightlies

Also available in: Atom PDF