ZFS: Create a snapshot of a filesystem

Contributed by qmchenry June 14, 2006  
Tagged: Solaris system administration

Of the many cool features of the new ZFS filesystems, one of the coolest is taking snapshots of a live filesystem. This provides a read-only point-in-time copy of the whole filesystem. While this sounds slow and expensive in disk usage, ZFS makes snapshots efficient in time and space.

To create a snapshot of my home directory in techrx/home/qmchenry with the name of today’s date (060614), I used the command:

zfs shapshot techrx/home/qmchenry@060614


Each snapshot has a name (which is useful since you could theoretically create 2^64 or more than 18 billion billion snapshots in each pool) and is referenced as filesystemname@snapshotname.

Snapshots show up in a normal zfs list just as filesystems do:

zfs list
NAME USED AVAIL REFER MOUNTPOINT
techrx 360M 18.8G 25.5K /techrx
techrx/home 360M 18.8G 25.5K /techrx/home
techrx/home/qmchenry 360M 18.8G 360M /techrx/home/qmchenry
.../qmchenry@060614 0 - 360M -


At this point, the snapshot uses 0 bytes of additional space as shown in the USED column (although there is some minor overhead in the pool). The REFER column shows the same size as the USED size of the original filesystem at the time of the snapshot. Note that there is no mountpoint for the fileystem. Snapshots are purposefully not intended to be accessed like a filesystem. To do that, you just need to clone the snapshot (which is another recipe).

The reason that snapshots add no overhead in CPU load is because of the way that ZFS writes changes in data to the disk. ZFS writes its data in units called blocks (which are dynamically sized up to 128KB). When the data in an existing block is changed, ZFS writes the data to a new block on disk before it releases the old block. However, when a shapshot exists for the filesystem, the old block is not released. Instead, it remains as part of the snapshot. Therefore, the only increases in disk space used for snapshots are in keeping around old blocks.