Having used btrfs before, I was surprised to find out that rolling back a snapshot in ZFS not only changes the “working set” of files, but also requires that any snapshots which are newer than the rollback target must be destroyed as well:

 zfs rollback [-Rfr] snapshot
   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 by specifying the -r option.

For comparison, here are some descriptions of non-destructively rolling back to a snapshot in btrfs:

btrfs sub snap -r fs snapshot
# ... do things on fs
btrfs sub del fs # at which point you'll lose those things you've done
                 # if you want to preserve them, just rename fs instead
btrfs sub snap snapshot fs # reinstate snapshot as a read+write fs
btrfs sub del snapshot     # delete the non-longer needed read-only snapshot

and non-destructively rolling back to a snapshot in ZFS:

zfs snapshot pool/project/production@today
zfs clone pool/project/production@today pool/project/beta
# make changes to /pool/project/beta and test them
zfs promote pool/project/beta
zfs rename pool/project/production pool/project/legacy
zfs rename pool/project/beta pool/project/production
# once the legacy version is no longer needed, it can be destroyed
zfs destroy pool/project/legacy

A “snapshot” is obviously a different thing in btrfs and ZFS, but I’m wondering what the advantage of having the destructive zfs rollback operation is, especially since there doesn’t seem to be a self-contained non-destructive rollback command. I would expect that, unless explicitly requested, the most commonly needed rollback operation is one that only affects the current state of files, and not other, unrelated snapshots based on the arbitrary criterion of when they were created.

I can imagine several kinds of reasons (e. g. historical, performance, storage space, simplicity of implementation), although not many which strike me as compelling, so relevant background information would be appreciated!

  • 1
    I wonder the same. Commented Aug 31, 2021 at 5:47

1 Answer 1


My understanding of the design of zfs, rollback is intended for a immediate undo of all changes since the last snapshot. Since this is destructive, the safety measure is to only allow going back one snapshot. However, you could go back one, then go back one, etc... to get to your indented snapshot. How ever, realize you will loose all your dataset chances since that snapshot.

However, if the intention is to access files in the dataset back to a specific snapshot, you can actually just access it anytime without doing any zfs commands. Simply access the snapshot via your file system.

For example: (switch over to root user, i.e. $ sudo -s bash

# zfs mount cypher-pool/data /data # mount dataset onto /data 
# cd /data                              # Where the dataset is mounted.
# cd .zfs                               # Note: system hidden directory
# cd snapshot                           # Location of all dataset snapshots
# ls                                    # List of current dataset snapshots
# cd autosnap_2023-04-01_00:00:02_monthly
# ls 
(all my files in my dataset as of the snapshot on April 1st 2023)

As far as I know, you can manipulate and view these files, just as if it was part of the normal file system.

If you really want to 'restore' the snapshot to current active file system area, you could always 'rsync' or 'cp' the files from a snapshot to the active area.

Take a snapshot of the current state, just in case you have problems. (of course, use your current date and time)

# zfs snapshot cypher-pool/data@backup_2023-08-21_16:20:42_backup

Start with something like. (Please confirm options before using)

# cd /data/.zfs/snapshot`
# rsync -Pav autosnap_2023-04-01_00:00:02_monthly/* /data/

Note: Example snapshots, as if created by ZFS Sanoid, https://github.com/jimsalterjrs/sanoid .

  • 2
    sudo cd doesn't do anything useful.
    – muru
    Commented Aug 22, 2023 at 5:59
  • The first paragraph kind of goes into the right direction, although I still don’t see any reason why you’d design it this way? While the rest of the answer is potentially useful, I wasn’t really asking for workarounds. It seems pretty bizarre that you’d have to use an external program to work around the file system, not to mention that all the information is there for it to do the same thing much faster! And finally, I wouldn’t trust rsync or any other external program to restore the files to the exact same state, including metadata, hard links etc.
    – Socob
    Commented Aug 30, 2023 at 8:32
  • @muru Great catch. sudo cd would not add anything to the process, if logged on as a regular user. I guess my intention is running all of those commands while logged in as root would work ok.
    – Iain4D
    Commented Nov 28, 2023 at 22:38
  • @Socob I hear ya. The intention of my post was to offer some thoughts and different approaches in case the question had actually more details and meaning behind it. I 'rsync' copy from a snapshot all the time and found no issues so far. Just have to be careful with the rsync options. The '-a' option is actually '--archive' which turns on a bunch of features including "copy links as links". This and other options for features, pretty much makes an exact copy of the data.
    – Iain4D
    Commented Nov 28, 2023 at 22:44
  • @Iain4D sudo cd would not do anything useful when run as any user.
    – muru
    Commented Nov 28, 2023 at 23:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .