6 minute read.Last Modified 2021-04-01 15:09 EDT
Snapshots are one of the most powerful features of ZFS. A snapshot provides a read-only point-in-time copy of a file system or volume. This copy does not consume extra space in the ZFS pool. The snapshot only records the differences between storage block references whenever the data is modified.
To save time and regularly create fresh snapshots, consider making a Periodic Snapshot Task instead.
To quickly snapshot existing storage, go to Storage > Snapshots and click ADD.
Use the Dataset drop down to select an existing ZFS pool, dataset, or zvol to snapshot.
The suggested Name is automatically generated but can be overridden with any custom string. Choosing a proper Naming Schema instead allows including the snapshot in Replication Tasks. The Naming Schema drop-down is populated with previously created schemas from periodic snapshot tasks.
To include child datasets with the snapshot, set Recursive.
Go to Storage > Snapshots to manage created snapshots.
Each entry in the list includes the dataset and snapshot names. Click chevron_right to view options for a snapshot:
Amount of space consumed by this dataset and all of its descendants. This value is checked against the dataset quota and reservation. The space used does not include the dataset reservation, but does take into account the reservations of any descendant datasets. The amount of space that a dataset consumes from its parent, as well as the amount of space freed if this dataset is recursively deleted, is the greater of its space used and its reservation.
Creating a snapshot initially shares space between the snapshot, filesystem, and possibly with previous snapshots.
Filesystem changes reduces the shared space and counts toward the snapshot’s used space.
Snapshot deletion often increases the space that is unique and used in other snapshots.
Another method to view the space used by an individual snapshot is to go to the Shell and enter
zfs list -t snapshot.
The space used, available, or referenced does not account for pending changes. Pending changes generally update within a few seconds, but larger disk changes slow usage updates.
Destroys the snapshot. Child clones must be deleted before their parent snapshot can be deleted. While creating a snapshot is instantaneous, deleting a snapshot is I/O intensive and can take a long time, especially when deduplication is enabled.
Creates a new snapshot “clone” (dataset) from the snapshot contents.
A dialog prompts for the new dataset Name. The suggested Name derives from the snapshot name.
Revert the Dataset back to the point in time saved by the Snapshot.
Rollback is a dangerous operation that causes any configured replication tasks to fail. Replications use the existing snapshot when doing an incremental backup, and rolling back can put the snapshots “out of order”. To restore the data within a snapshot, the recommended steps are:
- Clone the desired snapshot.
- Share the clone with the share type or service running on the TrueNAS system.
- After users have recovered the needed data, delete the clone from Storage > Pools.
This approach does not destroy any on-disk data and has no impact on replication.
TrueNAS asks for confirmation before rolling back to the chosen snapshot state. Clicking Yes reverts all dataset files to the state they were in when the snapshot was created.
To delete multiple snapshots, set the left column boxes for each snapshot and click the delete Delete button that appears.
To quickly search through the snapshots list by name, type a matching criteria into the search Filter Snapshots text area. The list changes to only display the snapshot names that match the filter text.
This is an advanced capability which requires ZFS and command line experience.
All dataset snapshots are accessible as an ordinary hierarchical filesystem
This is reached from a hidden
A snapshot and any files it contains are not accessible or searchable when the snapshot mount path is longer than 88 characters. The data within the snapshot is safe and the snapshot is accessible again when the mount path is shortened.
A user with permission to access the hidden file can view and explore all snapshots for a dataset from the Shell or using Sharing services like SMB, NFS, and SFTP. In summary, the main required changes to settings are:
- Snapshot visibility must be manually enabled in the ZFS properties of the dataset.
- In Samba auxiliary settings, the
veto filescommand must be modified to not hide the
.zfs, and the setting
zfsacl:expose_snapdir=truemust be added.
The effect is that any user who can access the dataset contents can view the list of snapshots by going to the dataset
A user’s ability to view files within a snapshot is limited by any permissions or ACLs set on the files when the snapshot was taken. Snapshots are fixed as “read-only”, so this access does not permit the user to change any files in the snapshots, or to modify or delete any snapshot, even if they had write permission at the time when the snapshot was taken.
ZFS has a
zfs diff command which can be run in the Shell.
This command lists all changed files between any two snapshot versions within a dataset, or between any snapshot and the current data.