Overview of ZFS Snapshots

A snapshot is a read-only copy of a file system or volume. Snapshots
can be created almost instantly, and they initially consume no additional disk space
within the pool. However, as data within the active dataset changes, the snapshot
consumes disk space by continuing to reference the old data, thus preventing the
disk space from being freed.

ZFS snapshots include the following features:

The persist across system reboots.

The theoretical maximum number of snapshots is 264.

Snapshots use no separate backing store. Snapshots consume disk space directly from the same storage pool as the file system or volume from which they were created.

Recursive snapshots are created quickly as one atomic operation. The snapshots are created together (all at once) or not created at all. The benefit of atomic snapshot operations is that the snapshot data is always taken at one consistent time, even across descendent file systems.

Snapshots of volumes cannot be accessed directly, but they can be cloned, backed
up, rolled back to, and so on. For information about backing up
a ZFS snapshot, see Sending and Receiving ZFS Data.

Holding ZFS Snapshots

If you have different automatic snapshot policies such that older snapshots are
being inadvertently destroyed by zfs receive because they no longer exist on the
sending side, you might consider using the snapshots hold feature.

Holding a snapshot prevents it from being destroyed. In addition, this feature allows
a snapshot with clones to be deleted pending the removal of the last
clone by using the zfs destroy-d command. Each snapshot has an associated
user-reference count, which is initialized to zero. This count increases by 1 whenever
a hold is put on a snapshot and decreases by 1 whenever a
hold is released.

In the previous Oracle Solaris release, a snapshot could only be destroyed by
using the zfs destroy command if it had no clones. In this Oracle Solaris
release, the snapshot must also have a zero user-reference count.

You can hold a snapshot or set of snapshots. For example, the
following syntax puts a hold tag, keep, on tank/home/cindy/snap@1:

# zfs hold keep tank/home/cindy@snap1

You can use the -r option to recursively hold the snapshots of all
descendent file systems. For example:

# zfs snapshot -r tank/home@now
# zfs hold -r keep tank/home@now

This syntax adds a single reference, keep, to the given snapshot or set
of snapshots. Each snapshot has its own tag namespace and hold tags must
be unique within that space. If a hold exists on a snapshot, attempts
to destroy that held snapshot by using the zfs destroy command will fail. For
example:

Displaying and Accessing ZFS Snapshots

By default, snapshots are no longer displayed in the zfs list output. You must use
the zfs list-t snapshot command to display snapshot information. Or, enable the listsnapshots pool property.
For example:

Snapshots of file systems are accessible in the .zfs/snapshot directory within the root
of the file system. For example, if tank/home/matt is mounted on /home/matt, then
the tank/home/matt@thursday snapshot data is accessible in the /home/matt/.zfs/snapshot/thursday directory.

Disk Space Accounting for ZFS Snapshots

When a snapshot is created, its disk space is initially shared between the
snapshot and the file system, and possibly with previous snapshots. As the file
system changes, disk space that was previously shared becomes unique to the snapshot,
and thus is counted in the snapshot's used property. Additionally, deleting snapshots can
increase the amount of disk space unique to (and thus used by) other
snapshots.

A snapshot's space referenced property value is the same as the file system's
was when the snapshot was created.

You can identify additional information about how the values of the used
property are consumed. New read-only file system properties describe disk space usage for
clones, file systems, and volumes. For example:

Rolling Back a ZFS Snapshot

You can use the zfs rollback command to discard all changes made to a
file system since a specific snapshot was created. The file system reverts to
its state at the time the snapshot was taken. By default, the command
cannot roll back to a snapshot other than the most recent snapshot.

To roll back to an earlier snapshot, all intermediate snapshots must be destroyed.
You can destroy earlier snapshots by specifying the -r option.

If clones of any intermediate snapshots exist, the -R option must be specified
to destroy the clones as well.

Note - The file system that you want to roll back is unmounted and
remounted, if it is currently mounted. If the file system cannot be unmounted,
the rollback fails. The -f option forces the file system to be unmounted, if
necessary.

In the following example, the tank/home/matt file system is rolled back to the
tuesday snapshot: