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 following 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 zero 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 mount point for the filesystem. Snapshots are purposefully not intended to be accessed like a filesystem. To do that, you just need to clone the snapshot (which is another tech-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.
