ZFS Snapshots and Clones

This chapter describes how to create and manage ZFS snapshots and clones.

The following sections are provided in this chapter.

• 6.1 ZFS Snapshots

• 6.1.1 Creating and Destroying ZFS Snapshots

• 6.1.2 Displaying and Accessing ZFS Snapshots

• 6.1.3 Rolling Back to a Snapshot

• 6.2 ZFS Clones

• 6.2.1 Creating a Clone

• 6.2.2 Destroying a Clone

6.1 ZFS Snapshots

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

ZFS snapshots include the following features:

• Persistence across system reboots.

• Theoretical maximum number of snapshots is 2⁶⁴.

• Use no separate backing store. They consume space directly from the same storage pool as the file system from which they were created.

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

6.1.1 Creating and Destroying ZFS Snapshots

Snapshots are created by using the zfs snapshot command, which takes as its only argument the name of the snapshot to create. The snapshot name is specified as follows:

filesystem@snapname
volume@snapname

The snapshot name must satisfy the naming conventions defined in 1.3 ZFS Component Naming Conventions.

The following example creates a snapshot of tank/home/ahrens that is named friday.

# zfs snapshot tank/home/ahrens@friday

Snapshots have no modifiable properties. Nor can dataset properties be applied to a snapshot.

# zfs set compression=on pool/home/ahrens@tuesday
cannot set compression property for 'pool/home/ahrens@tuesday': snapshot
properties cannot be modified

Snapshots are destroyed by using the zfs destroy command.

# zfs destroy tank/home/ahrens@friday

A dataset cannot be destroyed if snapshots of the dataset exists. For example:

# zfs destroy pool/home/ahrens
cannot destroy 'pool/home/ahrens': filesystem has children
use '-r' to destroy the following datasets:
pool/home/ahrens@tuesday
pool/home/ahrens@wednesday
pool/home/ahrens@thursday

In addition, if clones have been created from a snapshot, then they must be destroyed before the snapshot can be destroyed.

For more information on the destroy subcommand, see 5.1.2 Destroying a Filesystem.

6.1.1.1 Renaming ZFS Snapshots

You can rename snapshots but they must be renamed within the pool and dataset from which they were created.

# zfs rename tank/home/cindys@111205 pool/home/cindys@today

The following snapshot rename operation is not supported.

# zfs rename tank/home/cindys@111205 pool/home/cindys@saturday
cannot rename to 'pool/home/cindys@today': snapshots must be part of same 
dataset

6.1.2 Displaying and Accessing ZFS Snapshots

Snapshots of filesystems are accessible in the .zfs/snapshot directory within the root of the containing filesystem. For example, if tank/home/ahrens is mounted on /home/ahrens, then the tank/home/ahrens@friday snapshot data is accessible in the /home/ahrens/.zfs/snapshot/friday directory.

# ls /home/ahrens/.zfs/snapshot
tuesday wednesday thursday friday

Currently, the .zfs/snapshot/ directories can only be accessed locally or over NFSv4. Accessing these directories over earlier NFS versions is not supported.

Snapshots can be listed as follows:

# zfs list -t snapshot
NAME                      USED  AVAIL  REFER  MOUNTPOINT
pool/home/ahrens@tuesday  13.3M      -  2.13G  -

6.1.2.1 Snapshot Space Accounting

When a snapshot is created, its space is initially shared between the snapshot and the filesystem, and possibly with previous snapshots. As the filesystem changes, 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 space unique to (and thus used by) other snapshots.

A snapshot's space referenced property is the same as the filesystem's was when the snapshot was created.

6.1.3 Rolling Back to a Snapshot

The zfs rollback command can be used to discard all changes made since a specific snapshot. The filesystem reverts to its state at the time the snapshot was taken. By default, the command refuses to rollback to a snapshot other than the most recent one. To rollback to an earlier snapshot, all intermediate snapshots must be destroyed. You can destroy earlier snapshots by specifying the -r flag.

If there are clones of any intermediate snapshots, the -R flag must be specified to destroy the clones as well.

Note - The filesystem must be unmounted and remounted, if it is currently mounted. If the filesystem cannot be unmounted, the rollback fails. The -f flag forces the filesystem to be unmounted, if necessary.

The following example rolls back the pool/home/ahrens filesystem to the tuesday snapshot:

# zfs rollback pool/home/ahrens@tuesday
cannot rollback to 'pool/home/ahrens@tuesday': more recent snapshots exist
use '-r' to force deletion of the following snapshots:
pool/home/ahrens@wednesday
pool/home/ahrens@thursday
# zfs rollback -r pool/home/ahrens@tuesday