reversoid

[danboid]

reversoid because rollbackoid doesn't sound right to me.

reversoid should/could be a script included with sanoid for recursively rolling back snapshots of groups of datasets (or a full pool?) by a specified amount of time for snapshots created with sanoid.

I very much needed such a tool about a week ago.

Hows about it Jim?

Thanks

[jimsalterjrs]

If you use recursive=zfs (instead of recursive=yes) in sanoid, you can just zfs rollback -r to do a recursive rollback on a series of nested datasets. Does that mitigate your issue? The only real downside to recursive=zfs on the sanoid side is that you can no longer change policies effectively for child datasets, they get every setting the recursion parent has, period, no ifs ands or buts.

…

On March 14, 2023 17:31:21 Dan MacDonald ***@***.***> wrote: reversoid because rollbackoid doesn't sound right to me. reversoid should/could be a script included with sanoid for recursively rolling back snapshots of groups of datasets (or a full pool?) by a specified amount of time for snapshots created with sanoid. I very much needed such a tool about a week ago. Hows about it Jim? Thanks — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[danboid]

I don't understand how that could work. I thought zfs rollback (with or without -r) was independent of sanoid and its config file so how would changing a sanoid config option cause zfs rollback to work differently? In my testing, using rollback -r doesn't rollback child datasets.

Am I OK to change the sanoid recursive option when I please or must I first remove all previous/existing snapshots first?

Please give an example command of how I would rollback every dataset under /home (for example) by 24 hours or whatever.

Thanks

[jimsalterjrs]

I thought zfs rollback (with or without -r) was independent of sanoid

It is.

using rollback -r doesn't rollback child datasets.

You're correct; I misremembered. Actually, I misremembered what the capital R version did, then misremembered that I was misremembering the effect of -R not of -r, so I'm not firing on all cylinders today, clearly. :)

Please give an example command of how I would rollback every dataset under /home (for example) by 24 hours or whatever.

OK, if you're using recursive=zfs (not recursive=yes) then you know for a fact that all child datasets of the dataset specified in the sanoid config module will have the exact same timestamp and name. This makes it pretty trivial to script a mass rollback of them all:

root@elden:/tmp# zfs list -r rpool/test | grep -v NAME | awk '{print $1}'
rpool/test
rpool/test/1
rpool/test/1/2
rpool/test/1/2/3

This gave us a list of the dataset specified, /rpool/test, and all its child datasets. If we've been snapshotting them all using recursive=zfs, we know that any given hourly, daily, monthly, etc will have the same name across this entire group of sets. Which in turn means that we can iterate over the list to roll them all back at once.

First, which snapshot do we want to roll back to? Let's assume we want to roll back to the most recent daily:

root@elden:/tmp# zfs list -rt snap rpool/test | grep -v rpool/test/ | grep daily | tail -n 1`
rpool/test@autosnap_2023-03-15_00:00:01_daily

We piped the output of zfs list -rt snap rpool/test through grep -v rpool/test/ to remove child datasets (and their snapshots) from the list, so that what we see is snapshots of rpool/test only. Then we pipe it again through grep daily to only get dailies, and again through tail -n 1 to only get the most recent daily.

Now, we can roll everything back to that single daily snapshot:

root@elden:/tmp# for set in `zfs list -r rpool/test | grep -v NAME | awk '{print $1}'` ; do echo zfs rollback -r $set@autosnap_2023-03-15_00:00:01_daily; done
zfs rollback -r rpool/test@autosnap_2023-03-15_00:00:01_daily
zfs rollback -r rpool/test/1@autosnap_2023-03-15_00:00:01_daily
zfs rollback -r rpool/test/1/2@autosnap_2023-03-15_00:00:01_daily
zfs rollback -r rpool/test/1/2/3@autosnap_2023-03-15_00:00:01_daily

As you can see, we're generating the correct commands to roll back rpool/test and all of its child datasets to the same snapshot name. And since we know they'll all have the exact same name for each snapshot, we know it'll work when executed. So the next step is literally just to remove the "echo" from our loop above, changing it from a dry run into a real set of executed commands:

root@elden:/tmp# for set in `zfs list -r rpool/test | grep -v NAME | awk '{print $1}'` ; do echo zfs rollback -r $set@autosnap_2023-03-15_00:00:01_daily; done
root@elden:/tmp#

And we're done.

[danboid]

Thanks for the explanation Jim!

I don't have to remove all of the existing snapshots, I can simply change the sanoid recursive setting and then I can use that recursive rollback procedure from that point on right?

[jimsalterjrs]

Correct!

[danboid]

Thats what I thought. Good to know I should be ready if this ever happens again.

In a way it wasn't so bad because we had a current syncoid backup of it all and I was forced to work out and test the procedure of restoring all the datasets from our backup server 'from scratch' with syncoid and now I know how long that takes as a result. It was the data equivalent of a NDE.

Thanks again for your help and the fantastic tools Jim!

[danboid]

Unfortunately I had to test these instructions today. They omitted to mention that after rolling back all snapshots the user should run:

zfs mount -a

To mount / refresh all the datasets.

Wouldn't it also be recommended to stop sanoid before rolling back any datasets? Certainly when rolling back hundreds? Thats what I did anyway just to be safe.

Thanks Jim!