Recover snapshot from backup server

[wegisan]

Hello,
I'am new to freenas. To get used with it i setup two system for testing.
Primary and backup Server. Up to now, the systems are running and access to shares i build are ok.
Now, i'am testing backup and restore.
Created a periodic snapshot and did a Replication Task on this snaphot to the backup sever. Worked well so far.
But now, how i'am going to restore this snapshot back to the primary server. Assumption: primary dataset is lost.
1.
Using the GUI - I tried to setup a replication task in the reverse direction. For this, i need a snapshot first (first parameter in the GUI).
There is already a snapshot from the replication but this one cannot be selected in the 'Add Replication' GUI?
What are the tasks/steps to get this dataset back to the primary server?
2. Do i have to use the cmd line with zfs send/receive?

Thanks for your feedback.
regards wegisan

 

[Ericloewe]

Yes, for a one-time replication, you need to use the command line. Google "FreeBSD man ZFS" for details.

You will also need to remove read-only from the destination after it's replicated.

 

[wegisan]

Thanks for the feedback. I will try to reocover the snapshot with the zfs send / receive commands.

 

[Johnny Fartpants]

Hello,
I'am new to freenas. To get used with it i setup two system for testing.
Primary and backup Server. Up to now, the systems are running and access to shares i build are ok.
Now, i'am testing backup and restore.
Created a periodic snapshot and did a Replication Task on this snaphot to the backup sever. Worked well so far.
But now, how i'am going to restore this snapshot back to the primary server. Assumption: primary dataset is lost.
1.
Using the GUI - I tried to setup a replication task in the reverse direction. For this, i need a snapshot first (first parameter in the GUI).
There is already a snapshot from the replication but this one cannot be selected in the 'Add Replication' GUI?
What are the tasks/steps to get this dataset back to the primary server?
2. Do i have to use the cmd line with zfs send/receive?

Thanks for your feedback.
regards wegisan

Other option is to setup a new snapshot schedule on the replica and replicate back. You could set the schedule to something like every four weeks that way you will only have the one snapshot (depending on children) and after replication you could destroy the schedule. Then like @Ericloewe said from the command line remove readonly on the dataset 'zfs set readonly=off pool/dataset/whatever' That way you get to keep all those old snapshots (recovery points) you had on the primary before it was deleted.

What I would say however is in the real world if you had replication set to always run and you had a tick in the check-box 'Delete stale snapshots on remote system' if you ever managed to delete a dataset on your primary server it would have already deleted the dataset and snapshots on your replica and your data would be lost so bare that in mind.

 

[wegisan]

@Johnny Fartpants
Thanks for your answer. Working with zfs send/receive was successful. I now know how to recover in case of missing datasets.

 

[steve.long]

What I would say however is in the real world if you had replication set to always run and you had a tick in the check-box 'Delete stale snapshots on remote system' if you ever managed to delete a dataset on your primary server it would have already deleted the dataset and snapshots on your replica and your data would be lost so bare that in mind.

Sorry to dig up an old thread, but I'm confused. If you accidentally delete/lose a dataset on the primary server and your replication was set to delete stale snapshots, all your replicated snapshots would just go bye bye, even if they hadn't expired?

 

[Johnny Fartpants]

Sorry to dig up an old thread, but I'm confused. If you accidentally delete/lose a dataset on the primary server and your replication was set to delete stale snapshots, all your replicated snapshots would just go bye bye, even if they hadn't expired?

Yes. To be fair it doesn’t matter if you have delete stale snapshots enabled or not if you have replication set on a parent dataset and tick recursive with the snapshot schedule if you ever accidentally delete a child dataset on the primary that will destroy all that datasets snapshots and will destroy the dataset and snapshots on the replica. Personally I don’t like this behaviour and would rather another step be required on the secondary system before losing all the data but worth being aware of.

 

[steve.long]

Personally I don’t like this behaviour

Yeah. I don't like that either.

If I set my snapshot to be recursive but don't set my replication task to 'Recursively replicate child dataset’s snapshots', will I have the child datasets backed up, but not their snapshots? Or does not replicating their snapshots mean I don't have them backed up?

The language used in the manual seems confusing.

 

[Ericloewe]

Or does not replicating their snapshots mean I don't have them backed up?

This. You never backup the current version (you wouldn't have an atomic, single-point-in-time filesystem), you can only send snapshots. This is the same behavior as any backup system, really, except that it's neatly integrated in ZFS. You may be familiar with the Volume Shadow copy Service in Windows, it's the same concept.

 

[Johnny Fartpants]

Yeah. I don't like that either.

If I set my snapshot to be recursive but don't set my replication task to 'Recursively replicate child dataset’s snapshots', will I have the child datasets backed up, but not their snapshots? Or does not replicating their snapshots mean I don't have them backed up?

The language used in the manual seems confusing.

Yeah like @Ericloewe said. A snapshot is a snapshot but only when replicated to another system does it become a backup. If you don't replicate the snapshot of a given dataset then you don't have a backup of that data. One way around the accidental deletion of a dataset and its auto deletion on the backup system is to disable replication and only enable it periodically when you are happy with everything. Naturally this a manual process and would become very annoying and the risk would be you would forget to do it but it depends on how paranoid you are of you or someone else getting access to your box and blowing your data. It really shouldn't be a two click process to destroy all your data on your primary and secondary in my eyes. Ideally I would say having multiple 'roles' on FreeNAS would fix this. Perhaps only 'root' could perform the action of deleting a dataset or pool and by default root login would be disabled. An 'admin' role would be the account you would use to carryout day to day tasks but couldn't cause too much trouble if you clicked the wrong thing.