ZFS Part 4: ZFS Snapshots

Snapshots are another piece of awesome functionality built right into ZFS. Essentially, snapshots are a read-only picture of a filesystem at a particular point-in-time. You can use these snapshots to perform incremental backups of filesystems (sending them to remote systems, too), create filesystem clones, create pre-upgrade backups prior to working with new software on a filesystem, and so on.

The snapshot will, initially, only refer to the files on the parent ZFS dataset from which they were created and not consume any space. They will only start to consume space once the data on the original dataset is changed. The snapshot will refer to these blocks and will not free them, thus the snapshot will start consuming space within the pool. The files on the snapshot can be accessed and read via standard UNIX tools (once you know where to look).

The best way to discuss these concepts is via some examples. Let us start by creating a test dataset:

Copy a few files to the new filesystem:

Verify that the dataset has been created and is using space within the pool:

So, we can see that 35KB is being referenced, and used, by the dataset. Which is all as expected.

Now, let’s take a snapshot of this dataset. Snapshots are named <datasetname>@<arbitrarystring> – you can pretty much use whichever string you want for arbitrarystring, but it’d make sense to use something meaningful, such as the date or some such.

Create the snapshot:

Verify that the snapshot has been created:

You can see here that whilst the snapshot refers to 35KB of data, 0 bytes are currently used. This is expected as we are referencing all the data within datapool/snapshotfs, and haven’t yet changed anything.

Let’s delete a file from the filesystem.

Now, a zfs list -t snapshot shows that the snapshot is consuming 21KB:

This is expected, as the snapshot now has a copy (via copy-on-write) of the data we deleted.

Create another snapshot (note REFER is now 34K as the file copy of /etc/shadow was removed from datapool/snapshotfs) …

and remove another file.

USED will change accordingly:

See that the first snapshot we took HASN’T changed, again due to copy-on-write. Just to labour the point, let’s create another snapshot:

Again, REFER has gone down to 31.5K (due to the copy of /etc/passwd being removed from datapool/snapshotfs) and USED is 0 because we haven’t done anything else to datapool/snapshotfs since creating the snapshot.

Remove the final file:

All as expected. USED is up again. Thus, snapshots contain incremental changes and can be used as the basis of developing incremental backups (once an appropriate full backup has been taken). We can use these to rollback, too. Let’s rollback to datapool/snapshotfs@20130129-3, and get our copy of /etc/group back:

Very cool. Now, let’s rollback the dataset to the first snapshot we took:

Note that we need to specify the -r option to zfs rollback as we have multiple snapshots taken later than snapshotfs@20130129 that must be removed during the rollback to original dataset state. Note, we still have the ORIGINAL snapshot we’ve rolled back to active, and this will still be using space as the dataset is changed.

Our files are now restored.

We can access the copies of the files stored on the snapshot, under <dataset_mountpoint>/.zfs/snapshot/<snapshot_name>, for example:

Let’s destroy the test dataset (remembering -r to zfs destroy so that the snapshot(s) are removed too):

We can now use what we’ve learned about ZFS Snapshots to work with ZFS Clones.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s