Snapshots

If you ever had to recover a deleted file or roll back to an older version, you'll love snapshot functionality. Once you set up snapshots, you can access files as they were from the point in time at which the snapshot was made. Previous snapshots can also be cloned and used to recover data from that snapshot in time. Snapshots can also be replicated (copied) to another remote system. With FreeNAS, you can do one-time snapshots or periodically scheduled them. In this case, I want to set up periodic or scheduled snapshots, so I go to the FreeNAS web interface and navigate to Storage | Volumes | Periodic Snapshot Tasks | Add Periodic Snapshot (Figure 4; Table 1).

Figure 4: Scheduling snapshots.

Select the lifetime and frequency of the snapshots based on your particular needs to schedule a snapshot at your specified time. It is important to note that snapshots are not the same as backups. Although snapshots are very powerful, they don't replace backups and a full disaster recovery plan. Now that you have scheduled snapshots, you replicate them to an off-site system. This process enhances your ability to recover and restore your most valuable asset: your data.

Replication

For increased fault tolerance, you want to replicate your ZFS dataset or pool to another server. Replication occurs over a secure SSH tunnel, which is an additional security benefit. For the sake of the example, you will have two nodes:

• FreeNAS1 – The original FreeNAS server (PUSH)
• FreeNAS2 – Your FreeNAS Secondary/Backup Server (PULL)

When setting up replication [4], the original server on which you created your snapshot is always the push server (FreeNAS1) and the server receiving the snapshots is the pull server (FreeNAS2). In my configuration, I have two FreeNAS boxes, but you could just as easily replicate to another Linux/Unix server with ZFS. The push and pull servers must each have a ZFS pool, and the push server must have a periodic snapshot task. SSH should be running on the pull server.

You will be using key-based authentication, so you first need to set up the pull configuration on the FreeNAS box. To assure SSH is up and running, visit Services | Control Services and click SSH to the ON position.

Next, navigate to Storage | Replication Tasks | View Replication Tasks | View Public Key to set up key-based authorization. On the PULL (FreeNAS2) machine, copy the contents of this public key and navigate to Account | Users | View Users . Click the Modify User button of the user you will be using for replication and paste in the copied key (Figure 5).

Figure 5: Adding the public key.

Before continuing, you should verify that your periodic snapshots are working by going to Storage | Replication Tasks | Add Replication Tasks . The Remote ZFS Volume/Dataset is the name of the ZFS filesystem on the remote side (the pull server), and the Remote hostname is the IP of the pull server. By default, replication occurs when a snapshot is created. Generally, you might want to schedule replication with the Begin and End times during non-peak working hours.

All other settings can accept the defaults unless your configuration requires something different. Now when you click SSH Key Scan , your push server will grab the SSH key for you. Finally, click OK : The screen should flash that the replication task was updated successfully.

Backup

Now that you have a share set up and your clients access it, you should plan some basic disaster recovery. A major part of this planning is having the proper backups in multiple places. In this case, you will set up both configuration and local data backups. Above and beyond that, I recommend you also do some form of encrypted offsite backup of your critical data either online, in the cloud, or at a secure storage facility.

FreeNAS natively supports many options for backup, including:

• Bacula via a plugin
• Almost any general backup software for a local backup to an external device
• Backup to the cloud with CrashPlan
• Backup to the cloud via any number of online backup SaaS services

Given the many options, you have a lot of choice as to how to configure for fault tolerance and disaster recovery. To make your life a bit easier – just in case you have to recover your FreeNAS box – you should always back up your configuration, ZFS layout, and data. In the web interface, choose System | Advanced | Backup .

You will see the backup window in Figure 6. Fill this in with the required information for the target server to which you will backing up. Once you are done, simply click Do backup . To verify that the backup has taken place, look at the server you backed up to and see if it is there. As you can see in Figure 7, the metal music backed up as planned.

Figure 6: Getting ready to back up.

Figure 7: Metal music, FreeNAS configuration, and ZFS layout backed up!

This backs up your FreeNAS configuration, ZFS layout, and (if you so choose) your data. It occurs over an encrypted SSH connection to another server. This other backup server only needs to have an SSH daemon running and sufficient storage to save the data from your FreeNAS box. I highly recommend you use key-based authentication rather than just passwords everywhere. To do so, place your public key of the root user in ~root/.ssh/authorized_keys.

If you want more fault tolerance in your FreeNAS install, you can mirror the boot device. This means that whatever storage you use for the install (compact flash, USB flash drive, SSD, or regular SATA hard drive as the boot device), you need two of them so the install is mirrored. However, always remember that this doesn't magically back up your FreeNAS configuration if both drives should fail. You should still plan on backing up your data [5].