Max Farrior
by Max Farrior



Implementing Snapshots

Snapshots are a very useful feature of ZFS (and many other systems). Like its name suggests, a snapshot is a read-only version of a filessytem at a particular time. It’s literally a picture of the filesystem at a point in time. Interestingly, snapshots do not take up any space upon creation. This is because the snapshot is exactly the same as the filesystem. The snapshot will grow in size when the filesystem changes. A snapshot is a record of the changes since the snapshot was made. To see the filesystem when the snapsnapshot was taken, you simply undo the changes that have been made since then.

I have configured automatic snapshots in FreeNAS. I have several schedules. I take a snapshot of my important datasets once every four hours. These are kept for one week. I also take snapshots of my important datasets once every day, and these daily snapshots are kept for one month. Finally, I also schedule snapshots once a month, and these are kept for a year. The result is that I can see my data, exactly how it was, at any four hour interval in the past week, on any day in the past month, or on any month in the past year.

I think this strategy give me a high level of file protection. If I overwrote a file when saving, I could load up a snapshot from four hours ago and retrieve the original file. If I delete a file and need it a week later, I can load a daily snapshot from last week.

One change I am considering is keeping daily backups longer. Say three months or six months. My data doesn’t change very much, and I have plenty of space. This would give me more flexibility.

Implementing the Offline Backup Drives

ZFS also has a useful feature that allows it to replicate data to other ZFS volumes / systems. Unfortunately, the FreeNAS GUI only decided to implement this feature for remote systems. So FreeNAS allows you to replicate data to remote ZFS systems over SSH. But not locally. My backup plan included replicating data from my main array, locally to my backup drive. One way around this is to send the data to localhost when specifying a host. The problem with this is that now the datastream is going from the main array, through SSH, then to the backup drive. (On the machine.) Not the absolute worst thing, but very unnecessary.

The only solution is to go on FreeNAS’s CLI and run the commands manually. The commands you want are zfs send <snapshot> | zfs receive <destination>. This pipes the snapshot to the backup drive, which is already mounted. The result is that my backup drive will contain the contents of the snapshot.

So my backup strategy (concerning the offline drives) will be to insert the backup drive, mount the drive, copy over whatever snapshots I want, unmount and remove the drive

I want to automate this somehow. Inserting the drive into the machine has to be done manually. I want mounting the drive in the GUI to be done manually, because I keep the encryption keys.. encrypted. I don’t want any automatic decryption taking place. The part that can be automated is after the drive is mounted, choosing which snapshots get copied over and actually copying them over. I also need to better understand if/how multiple snapshots can be backed up. Copying over all my daily snapshots for the last month (the offline backup disk will get updated once a month) would be convenient. I was thinking about using a shell script..

For the time being, I think I will take a snapshot of the whole array and copy over that snapshot. That way all my data, as it looks today, is on the backup drive. I will do this for two drives, one kept local to the machine and one kept remotely.