Can ZFS even *do* this? (Restore *file*, not rollback, an *entire* snapshot)

[winnielinnie]

We all know we can revert a dataset to a previous snapshot. It's like hitting the "undo" or "rewind" button.

Simple enough.

Now you have your dataset as it was, record-by-record, in a previous state. Everything you deleted is restored 100%, as long as it lived on the snapshot. No additional space is used up, since these "restored" files that were deleted are not "copied"; but rather, the pointers to their existing records are now in play, once again.

Okay, makes sense...


So here's my question: Is it possible to "restore" specific files from a snapshot, without having to revert back the entire snapshot?



I know that you can "copy" files from the .zfs/snapshot/ directory, but this essentially creates new records. It's not using the existing records.


----------


Here's an example:

Let's say I have a dataset with a very large 5 GB Linux .iso. (The only reason we use bittorrent.)

I create a snapshot named "manual-001".

I do a bunch of stuff afterwards. Deleting, downloading, modifying, etc.

If I later accidentally delete the very-large-linux.iso file (5 GB), I can still find it under .zfs/snapshot/manual-001/

I can even copy it back to my live dataset.

But now this very same file is consuming twice as much space: 5 GB for the (deleted) records that exist in the snapshot, and another 5 GB for the new records created from the copy to the live dataset.


Does ZFS contain a mechanism which restores a particular file by simply using the same records that already exist, without having to revert back the entire snapshot?

 

[jgreco]

So ignoring what's possible for a moment, what you want is something like a clone (a writable snapshot) and a hardlink that makes that available on a persistent basis...? Or directly from a snapshot?

This isn't currently supported as far as I know, but you're right that it theoretically could be done.

# ls -ail 103R-amd64-7ad068e3-std.txz
1242517 -rw-r--r-- 1 2001 wheel 936476636 Jun 8 2020 103R-amd64-7ad068e3-std.txz
# ls -ail ../.zfs/snapshot/auto-2021-05-05_00-00/images/103R-amd64-7ad068e3-std.txz
1242517 -rw-r--r-- 1 2001 wheel 936476636 Jun 8 2020 ../.zfs/snapshot/auto-2021-05-05_00-00/images/103R-amd64-7ad068e3-std.txz

So it has the same inode number, but it does not claim it has multiple links (the number 1 before the "2001" uid). ZFS treats the .zfs subdirectory as a different device.

It may be that deduplication was originally envisioned as the mechanism to handle this. File level rollback has no great mechanism that I'm aware of.

 

[winnielinnie]

So ignoring what's possible for a moment, what you want is something like a clone (a writable snapshot) and a hardlink that makes that available on a persistent basis...? Or directly from a snapshot?

The latter. Essentially exploting the fact that the same records remain, and it's just a matter of restoring the pointers. I realize this might introduce complexities when it comes to metadata, but there could theoretically be ways around this, no?

So it has the same inode number, but it does not claim it has multiple links (the number 1 before the "2001" uid). ZFS treats the .zfs subdirectory as a different device.

Which to me seems like the .zfs/snapshot directory is just a convenient means to browse and copy a deleted/modified file for a "quick retrieval" without having to resort to the shotgun-blast approach of reverting back to an entire snapshot. (What you're showing with the same inode number, but "not really linked" in the same filesystem, seems to hint towards some sort of abstract "translation" for the sake of presenting the user with friendly "browseable" read-only "directories" (which don't really exist as true directories under a live filesystem)?

It may be that deduplication was originally envisioned as the mechanism to handle this. File level rollback has no great mechanism that I'm aware of.

Such a mechanism could be independent of deduplication. It would really come in handy for large files or accidental deletions of folders. [1]

After all, the records that the "deleted" file is comprised of are never truly "gone" until all snapshots which contain it are destroyed. Thus, there's no possible way for these records to be "overwritten".

The frustrating part about this is that trying to restore just a single file while leveraging ZFS's strengths (records-based snapshots) is simply not possible in its entire history since 2001? If you don't want the added consumption of space, you need to rollback an entire snapshot?

Sure, it's nice to be able to browse a "hidden folder" to quickly grab a copy of a previously deleted/modified file, but it still duplicates the size with more "new" records. This is especially evident with large files.

----------

[1] I have a "playground" dataset on an SSD-only pool. I will use it to do some quick, unimportant video editing, as well as temporarily hold large files that I may not need in the future.

Recently, while I was using my file manager (Dolphin, KDE), I deleted some small unimportant files in Folder B, and then wanted to delete the entire Folder A.

I have the file manager configured to "sort by modification date".

What ended up happening is that as my mouse cursor was hovering over Folder A, the moment I right-clicked (to select "delete"), Dolphin re-positioned the order of the folders (due to recent changes), and I didn't realize that I ended up right-clicking Folder B! (Dolphin will sometimes "delay" the re-sorting.)

KABLAMMY! Folder B was deleted, which contained large video files.

Luckily for me, I instinctively created a manual snapshot not too long ago. (I also have the original unedited files elsewhere.)

So I browsed to the hidden .zfs/snapshot directory, found Folder B, and copied it back to the dataset. That's when I realized I am basically duplicating the size used by these large files, since the "copy" operation creates new records.

"Why didn't I just rollback the entire snapshot?" Because I had done many other small things since then, of which I wouldn't be able to memorize nor retrace my steps.

That's why I wondered if ZFS has such a feature to restore only some records; rather than the "all or nothing" approach of an entire snapshot rollback.