Sinle File Snapshot Restore

[john.robert]

Hello to the group,

I am trying to figure out how to restore a single file from a snapshot that I accidentally deleted in a Windows 7 CIFS session. I have been reading related posts, and have looked into the /.zfs/snapshot directory, but the snapshots that are listed in the GUI do not show up in this location. Numerous snapshots do appear, but not those listed in the GUI. When I list the files in /.zfs/snapshot/2019-09-23-22:42:18/mnt, using ls -a there are no files listed.

I am running FreeNAS 11.2-U6, and logged in as root.

Thanks in advance for your assistance.

John--

 

[anmnz]

You need to look in the .zfs/snapshot directory not in the root of the whole filesystem, but in the dataset that contained the file.

That may be /mnt/<pool name>/.zfs/snapshot, or further down if you've got more datasets.

A simple brute force search is to see if you have .zfs/snapshot in the directory that contained the file; if it's not there then look in its parent directory; and so on.

 

[john.robert]

anmnz,
Thanks for the quick reply.

Is there any reason why I cant create a current snapshot for today from the GUI, then restore it from a snapshot made before I deleted the file. Then grab my file, then restore it back to today's snapshot?

I just do not want to risk being stuck at that earlier snapshot, and then have to restore all the files changed since the earlier snapshot.

 

[garm]

You don’t rollback the snapshot. Just go in to the appropriate .zfs folder and fetch the file

 

[john.robert]

I wrote the following into the shell, at the root directory:

find / -name snapshot

There were no results, even though there are numerous snapshots displayed in the GUI.

 

[anmnz]

The .zfs "directory" normally does not appear in directory listings and so find won't descend into it.

 

[blueether]

From the manual, this would appear to be the correct way?

9. Storage — FreeNAS®11.2-U6 User Guide Table of Contents

www.ixsystems.com

:

Note
Rollback is a potentially dangerous operation and causes any configured replication tasks to fail as the replication system uses the existing snapshot when doing an incremental backup. To restore the data within a snapshot, the recommended steps are:

1. Clone the desired snapshot.
2. Share the clone with the share type or service running on the FreeNAS® system.
3. After users have recovered the needed data, delete the clone in the Active Pools tab.

This approach does not destroy any on-disk data and has no impact on replication.

 

[garm]

Ya but snapshots are already available in the .zfs directory unless the system has been configured otherwise

 

[anmnz]

I think you're going off track with this. You were on the right lines back in your first message when you said

When I list the files in /.zfs/snapshot/2019-09-23-22:42:18/mnt, using ls -a there are no files listed.

You just need to find the right .zfs/snapshot directory. It's the one in the root of the dataset that contained the file you're looking for.

There are several ways to figure out where the root of the dataset is. You can tell from the UI, or zfs list, or other Unix commands (like mount, df, etc.). A simple way is to try ls .zfs/snapshot in the directory the file was in. If it's not there, move up a directory with cd .. and try again. And so on. If you have no other datasets set up, you will eventually find /mnt/<pool name>/.zfs/snapshot.

Once you have found the right .zfs/snapshot directory, find the right snapshot inside it (e.g. with ls) and cp the file you want out of it.

You can run commands like find inside the snapshots directory just fine. It's only ".zfs" itself that confuses people by not normally appearing in a directory listing (because it's not a normal directory, but rather an interface to special ZFS functionality).

 

[john.robert]

anmnz, blueether, garm,
Thank you very much for the detailed explanation.
My problem is that I was not looking into the correct instance of .zfs/snapshot.
I was also looking for instances of .zfs, not .zfs/snapshot - thinking that .zfs was a normal hidden directory.
Finding the correct instance shows the entire directory structure and allows me to cp the file back to the working file system.
Regards,
John