Synopsis #
The safest response to an accidentally changed or deleted file is usually to copy that file from a snapshot into a separate staging path, inspect it, and then place it deliberately. Rolling back an entire dataset can destroy all changes made after the selected snapshot.
This procedure assumes that a suitable snapshot already exists. If every copy is on the same damaged or unavailable pool, use an independent backup instead.
Identify the dataset and snapshots #
Find the dataset that owns the affected path. If the file was deleted, query its nearest existing parent directory rather than the missing path:
$ df /srv/data
$ zfs list -o name,mountpoint
$ zfs list -t snapshot -o name,creation,used -s creation
Confirm the snapshot time against the event being recovered. The newest snapshot is not automatically the correct source if it already contains the unwanted change.
Inspect the snapshot directory #
Check the snapshot directory by addressing it explicitly:
$ zfs get snapdir tank/data
$ ls /srv/data/.zfs/snapshot/
If snapdir is hidden, .zfs is not shown by a normal directory listing but can ordinarily be addressed explicitly. Recovery does not require changing the property.
Inspect the candidate without changing the live file:
$ stat /srv/data/.zfs/snapshot/hourly-2026-08-13-1400/report.db
$ if [ -e /srv/data/report.db ]; then cmp /srv/data/report.db /srv/data/.zfs/snapshot/hourly-2026-08-13-1400/report.db; else echo "live file is absent"; fi
cmp returning a difference is expected when the live file was modified. The existence check distinguishes that case from deletion, where there is no live file to compare.
Restore through a staging path #
Create a staging directory on a filesystem with enough space, then preserve the candidate’s metadata while copying:
# mkdir -m 0700 /var/tmp/zfs-restore
# cp -a /srv/data/.zfs/snapshot/hourly-2026-08-13-1400/report.db /var/tmp/zfs-restore/
Validate the staged file with the application that owns it. A filesystem snapshot is crash-consistent, but a database or other stateful application may require its own recovery or consistency check.
Stop or quiesce the application when its procedure requires that boundary. Preserve the current file before replacing it, but only when a current file exists:
# test ! -e /srv/data/report.db || cp -a /srv/data/report.db /var/tmp/zfs-restore/report.db.before-restore
# install -o appuser -g appgroup -m 0600 /var/tmp/zfs-restore/report.db /srv/data/report.db
The owner, group, and mode are examples. Derive the real values from the service and the prior file; do not copy them blindly.
Restore a directory carefully #
Copying a directory from a snapshot does not remove newer files from the live directory. That behavior is often safer than synchronizing deletion. Stage the directory first and compare trees before selecting an application-aware restore command.
Avoid adding --delete, recursive ownership changes, or a dataset rollback merely to make two trees identical. Each can remove or reclassify data outside the intended recovery set.
Do not use rollback as a file restore shortcut #
zfs rollback rewinds the entire dataset. Options that remove newer snapshots or dependent clones expand the loss. Use it only under a separately reviewed recovery plan after newer data has been preserved.
If many files or the whole dataset must be recovered, create or receive a clone in an alternate namespace and validate it before changing the production mount point.