Snapshot Rollback

[Glorious1]

I thought it would all make sense by now, but I remain vaguely confused about snapshots and replication. I have three questions at the moment.

1. In the GUI snapshots list, there is a button called "Rollback Snapshot", but it is only on the most recent snapshot of a set. Can't you roll back to an earlier snapshot than the last one?

2. I make daily snapshots of a dataset, set to live for 2 weeks, and they replicate to another volume. I find that the snapshot list contains snapshots in the target volume as well as the source volume. I don't really understand why. So I guess I could roll back or clone any of those snapshots on the target volume also?

3. Finally, those snapshots on the target volume don't seem to get deleted when they are two weeks old (the ones on the source volume do). Should they be? Do I have to delete them manually? (Deleting a bunch of snapshots is the most tedious thing of all in FreeNAS.)

 

[Bidule0hm]

1) I'm interested by the answer too :)

2) This is normal, when you replicate you replicate the snapshots ;)

3) This is normal too, the replicated snapshots don't get deleted after their expiration time.

 

[dlavigne]

From man zfs:

Roll back the given dataset to a previous snapshot. When a dataset is rolled back, all data that has changed since the snapshot is discarded, and the dataset reverts to the state at the time of the snapshot. By default, the command refuses to roll back to a snapshot
other than the most recent one. In order to do so, all intermediate snapshots and bookmarks must be destroyed...

 

[enemy85]

1) you can just "clone" an old snapshot. This means it's created a copy of that dataset in a new place (you need to have enought free space on the target place to do so), and you can access the files in it keeping the original dataset indipendent

 

[Glorious1]

@enemy85 - yes, I saw the clone feature, though I haven't tried it. For this dataset it seems more trouble than rolling back. This is a Time Machine backup. Rarely, they get corrupted and you would have to nuke it and start over. Rolling back to a time before corruption would be a cinch. Then Time Machine would automatically fill in everything new since that snapshot.

But if you can only rollback to the last one (a restriction that doesn't seem necessary, but what do I know), in this case that's probably not far enough.

@dlavigne - "In order to do so, all intermediate snapshots and bookmarks must be destroyed..." I don't get that - if you can only rollback to the last snapshot, there are no intermediate snapshots between now and then to destroy. Or do they mean OLDER snapshots are destroyed?

 

[Tywin]

@dlavigne - "In order to do so, all intermediate snapshots and bookmarks must be destroyed..." I don't get that - if you can only rollback to the last snapshot, there are no intermediate snapshots between now and then to destroy. Or do they mean OLDER snapshots are destroyed?

He means if you want to go to a snapshot further back than the latest one, you must first destroy the intervening snapshots such that the one you wish to go to becomes the latest one. Then you can rollback to it.

 

[Glorious1]

Oh, now it makes sense. I was reading that differently. Well that could work then, just delete snapshots until I get back to a likely pre-corruption one, then roll back. Thanks all.

 

[Jailer]

I recently was inquiring about snapshots myself.

https://forums.freenas.org/index.php?threads/help-me-understand-snapshots-better.28226/#post-184252

The cloning is pretty neat if you have something specific you need to get at and you don't won't to destroy the intermediate snapshots. Just clone it, grab what you need and then delete the clone.

 

[zambanini]

a solution for 3) would be interesting

 

[cyberjock]

a solution for 3) would be interesting

There is...

 

[Glorious1]

OK, I had forgotten about that option. But now that you bring that up, that is another question I had. Why are "recursively replicate" and "remove stale snapshots on remote side" linked together in that one option? They don't seem very related. Why can't you do one without the other?

 

[cyberjock]

The official answer (if I'm going to explain this well) is that the two are intertwined because of how ZFS replication works. If you don't want to recursively handle snapshots BUT you want to remove stale snapshots you would have to do independent snapshot tasks without recursion, and then check the box. On the "cleanup" side of things with the replication, if you are doing snapshots with replication *and* recursion it is an "all or none" type of thing.

So either you do:

- Snapshots with recursion and check the box for recursion and remove stale snapshots (all recursive locations will replicate *AND* cleanup automatically)
- Snapshots without recursion and check the box for recursion and remove stale snapshots (no recursive locations will replicate *AND* cleanup of that one location and only that one location will occur)
- Don't check the box to remove stale snapshots and nothing ever gets cleaned up. :P

But because of the way that recursion works, you have to handle it along with any snapshot deletion to keep things in sync.

I haven't tested this, so if I'm wrong and you figure out I'm wrong let me know and we'll do more research. ;)

 

[fracai]

This is a Time Machine backup. Rarely, they get corrupted and you would have to nuke it and start over. Rolling back to a time before corruption would be a cinch. Then Time Machine would automatically fill in everything new since that snapshot.

I usually check the logs on my Mac and rollback to whatever snapshot occurs between TimeMachine backups prior to the corruption.

For a long time now, I've wanted to put together a script that would monitor the system.log on my Mac and create a new snapshot of my TimeMachine dataset whenever a backup is completed. The backupd logs include what the name of the new backup is as well as indicating when the volume has been properly ejected. These are the "safe points" to roll back to whenever a backup is corrupted.

There is one issue that I've seen where it looks like TimeMachine thinks it can use the fsevent log to determine changed files, but really it needs to do a full scan because you've rolled back to an earlier state. The result is that you're missing files that were modified between the last clean backup and the corrupt one. Ideally there'd be a way to instruct TimeMachine to perform that full scan, but I haven't found a way yet. Maybe deleting the fsevents cache would do it?

Anyway, sorry to derail this, if I get such a script together along with a solution to the rollback problem I'll start a new thread.