Four Ways To Use ZFS Snapshots

January 17, 2017

Four Ways To Use ZFS Snapshots

By Henry Washburn

For those of you about to read this blog, don’t. First, read the prior blog I wrote called “Configure Backup Storage with ZFS” for background. Now that that’s out of the way we can continue.

ZFS snapshots are incredibly helpful for restores. Datto uses ZFS snapshots to store changes to backup and NAS data over time, and each snapshot can be addressed as a full version of the data from the timestamp if necessary. Datto calls this capability Inverse Chain Technology. This article is for those of you who want to open your mind to the possibilities that ZFS can afford. Below you’ll find four ways you can use ZFS snapshots on Datto devices. For ZFS command usage guidelines, check out the ZFS Man page.

Get efficient storage of data change

ZFS snapshots can happen at any time of day and can be stored as long as you have enough space in the zpool. If you want to free up some space in the zpool, all you need to do is delete the snapshots with the ZFS destroy command at any point in the list of snapshots, it will not affect the data within the other snapshots. ZFS handles what each snapshot has to store to continue to reference the same data. In the aforementioned blog, I explained what happens when data within the mountpoint is removed, the snapshot that referenced the deleted mountpoint data stored what was lost so it could be restored if needed.  The same holds true when deleting snapshots over time.  

Most backup software products must “roll-up” snapshots into a new file to restore data—this is highly inefficient. First, it takes time to create the file, and if there are issues creating the new file the chain can be corrupted and you are S.O.L. from that roll-up point to the newest snapshot. Second, it is a new file, meaning that whole file has to be sent to another location for disaster recovery purposes, which can result in slower recovery time. With ZFS, if you have a snapshot in one location and send it to another location it is the same and doesn’t need to be resent if the snapshot is deleted from the original location.

Restore data from a point-in-time, instantly

ZFS snapshots are read-only pictures of the data they represent, so to make the data writeable you have to ZFS clone it. A clone is a fork in time from the data that existed in the filesystem from the chosen snapshot and it acts as a new filesystem with its own mountpoint. Similarly to a new snapshot, a clone also creates instantly and takes up no space until you affect the data within its mountpoint. That means that you can read, write, copy, or move any of the data within the new mountpoint created and if you don’t want it any more, just delete it. If you store flat files within the original filesystem, then your clone will have versions of those files from the snapshot’s point-in-time and your restore is a simple copy and paste into the original location. If the data is in a different format, you will most likely have to enact a conversion process to get it into a format that you need. Datto clones out data for all types of restores: local virtualisations, file restores, diskless restores, hybrid virtualisations and more.

In contrast, most backup software takes time to create a version of the data to restore. This is because it has to walk a portion or the whole chain of incremental backups to complete a restore. This is because each snapshot is dependent on the previous snap in the backup chain. Reverse incrementals try to overcome this issue by keeping a fully constructed copy of the most recent backup for restore. However, if you need to restore to an earlier point in time, the software must rebuild a full backup from incrementals.

Send data from one location to another incrementally

You can send data incrementally with pretty much any backup solution, but with ZFS any snapshot can be used as the first version of the data to send to another location. Once the first snapshot is fully sent to another location then you can choose to send all subsequent snapshots or skip snapshots. When you skip snapshots you reduce the amount of data that needs to be sent, so that route makes sense for many. OpenZFS recently added the ability to send compressed snapshots as well. Previously the ZFS send operation had to send the full amount of data that it was referencing, even though at the source and destination it was immensely compressed.

Promote a clone to the live data

Say you have a ZFS filesystem that is storing the virtualisation information for a server you are looking to update Windows. Smartly, you decide to clone snapshots to test windows updates on the cloned data without impacting the production server. You virtualise the cloned server on its own and run Windows updates on it to see what happens. It turns out the windows update fails and BSODs the server, but it is not a disaster because you are only working on a temporary version of the server. You take the time to fix the issue and your server is updated and working as it should. But now what? You don’t want to have to perform the update and fixes on the live data? 

Well, that’s where ZFS promote comes in. ZFS promote makes the clone the new true filesystem and moves the old filesystem to a clone with all the old snapshots intact.  In the aforementioned scenario, you would promote the updated server clone, after powering off the original server and the cloned one, and then promote the clone. Once completed, and it happens fairly quickly, you can simply power on the updated server.

These are only four ways of using snapshots, and I am sure there are others that I haven’t considered. If you are using snapshots in a unique way, I’d love to hear about it. It doesn’t have to be ZFS-specific either, I’m interested in any data protection process that starts with snapshots. Contact me via @TEHenrywashburn or via LinkedIN and I would be happy to discuss.

Relevant Articles

Subscribe to the Blog