napp-it: Replicate to an old/formerly Filesystem

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

Bronko

Member
May 13, 2016
111
10
18
105
Hi @gea ,

after my complete data loss on storage pool the ZFS Filesystems replicated back from Backup System fine.
The question now arising:

Can I use the "old" source file system on backup server as the replication target for the new replication of the same file system on storage to backup system by Replication Option "Force job id"?
 

Bronko

Member
May 13, 2016
111
10
18
105
Ok, I think yes and the answer is given by
Then create a new replication job with the same source and target filesystem.
Enter the former job-id in the field „Force jobid“. You can then continue the replication job without the need
of a new initial transfer.
on napp-it Docu page 54 and should catch my situation too, isn't it?
 
Last edited:

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
Yes, you can reverse an incremental replication as you have the same base-snaps on both sides (Just care about job-id and the readonly setting)
 

Bronko

Member
May 13, 2016
111
10
18
105
Didn't work.
Reverse Backup failed by different snap name, because hostname is different for Storage (tanker) and Backup (btanker)...

Once more the Docu:
Code:
Then create a new replication job with the same source and target filesystem.
Enter the former job-id in the field „Force jobid“. You can then continue the replication job without the need
of a new initial transfer.
Following this, but source path (content the same, backup was written to new zfs file system) has changed form "tank1/data/silo" to "tank1/data/inst/silo". Old replication job overwritten by new due to "forced jobid".

First run, old snap was missing:
Code:
1277, source-dest snap-pair 99 not found;: 1,0
Create a current snap on source and renamed:
Code:
zfs rename tank1/data/inst/silo@2019.03.15.16.57.28  tank1/data/inst/silo@1475869927_repli_zfs_btanker_nr_99
and it fails too:
Code:
receiving incremental stream of tank1/data/inst/silo@1475869927_repli_zfs_btanker_nr_100 into
btank1/tanker/silo@1475869927_repli_zfs_btanker_nr_100 cannot; receive incremental stream: most recent snapshot of btank1/silo/projects does not match incremental source
Any hints?
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
If you replicate for example tank/data to backup you get the readonly filesystem backup/data with an identical base snap pair.

To reverse incremental replicate:
Set backup/data to rw and create a new replication job with same jobid from
backup/data to tank (will update tank/data to newest version from backup)

In case of a non existent tank/data, you do not need a snap-pair for rollback as this initiates a full initial replicate.
 

Bronko

Member
May 13, 2016
111
10
18
105
If you replicate for example tank/data to backup you get the readonly filesystem backup/data with an identical base snap pair.

To reverse incremental replicate:
Set backup/data to rw and create a new replication job with same jobid from
backup/data to tank (will update tank/data to newest version from backup)
This failed as mentioned above, because replication snapshots name doesn't match for reverse replication due to hostname included (determined by targets host name for both sides) and the same job_id is awaiting the reverse hostname.

Am I wrong? But this is what my test is showing...

In case of a non existent tank/data, you do not need a snap-pair for rollback as this initiates a full initial replicate.
For sure, but without corresponding snap pair the idea is reduced to have a file system on both sides and initiate an incremental replicate between them.
This is wrong, isn't it?
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
Repli Snapnames contains the poolname not the hostname.
If you create a reverse replicaton job with same source/destination filesystem and same jobid it will continue the incremental replication as this only requires the presence of the target filesystem and a snap-pair.

Without the identical snap-pair that is required for a rollback of the target filesystem to the common snap-pair base, you cannot do an incremental replication. This is because ZFS does not do a file compare like rsync but simply sends the modified datablocks between the common base snap and a new source snap.
 

Bronko

Member
May 13, 2016
111
10
18
105
Repli Snapnames contains the poolname not the hostname.
Sorry @gea ,but I have the hostname (btanker) in the napp-it Repli-Job Snap name:
Code:
1552935751_repli_zfs_btanker_nr_1
 
Last edited:

Bronko

Member
May 13, 2016
111
10
18
105
If you create a reverse replicaton job with same source/destination filesystem and same jobid it will continue the incremental replication as this only requires the presence of the target filesystem and a snap-pair.
You are right, it works as described with the second and all following filesystems.
Don't know what happened by the first one... sorry.

(But hostname is a part of napp-it Repli-Job Snap name)
 
Last edited: