In my experimentation with FreeNAS one thing I found lacking was the quality of reports it generated. I suppose one philosophy is that the smaller the e-mail the better, but my philosophy is that the e-mail should still be legible. Some of the e-mails I get from FreeNAS are simply bizarre and cryptic.
FreeNAS has an option to replicate your ZFS volumes to a remote source for backup. As far as I can tell there is no report e-mail when the replication is done, although there may be a cryptic e-mail if anything failed. I have grown used to daily status e-mails from my previous NAS solution (Debian with homegrown scripts.) I set out to do this with FreeNAS and added a few added features along the way.
My script requires that you have already created an appropriate user and private/public key pair for both the source and destination machines (to allow for passwordless logins.) Instructions on how to do this are detailed below. You can download the script here.
Notes and observations
I learned quite a bit when creating this script. The end result is a script that e-mails me a beautiful report telling me anything that was added or removed since the last backup.
- I used dd for greater speed as suggested here
- I learned from here that the -R switch for ZFS send sends the entire snapshot tree.
- The ZFS diff command currently has a bug where it does not always report deleted files / folders. It was opened two years ago, closed, and then recently re-opened as it is still an issue. It is the reason my script uses both ZFS dff and rsync – so I can continually see the bug in action.
- When dealing with rsync, remember the / at the end!
- In bash you can pipe output from a command to a variable.
- When echoing above variable, make sure you enclose it in quotes to preserve formatting.
- Use the -r flag in sed -r for extended regex functions
- In my testing the built in freeNAS replication script didn’t appear to replicated the latest snapshot. Interesting…
Below are the preliminary steps that are needed in order for the script to run properly.
Configure a user for replication
Either manually or through the FreeNAS UI, create a user that will run the backup script. Create that same user on the remote box (backup server.)
Generate RSA keys
Log into local host and generate RSA keys to allow for passwordless login to the system
cd .ssh ssh-keygen
Make note of the filenames you gave it (the default is id-rsa and id-rsa.pub)
Authorize the resulting public key
Log into remote host and add the public key of local host in ~/username/.ssh/authorized_keys where username is the user you created above. One way to accomplish this is to copy the public key on the main server and paste it into the authorized keys file of the backup server.
On the main server
(assuming the keyfile name is id-rsa)
cd .ssh less id-rsa.pub
Copy the output on the screen in its entirety
On the backup server
Paste that public key into the authorized_keys file of the backup user
cd .ssh vi authorized_keys
Allow the new user to mount filesystems
FreeNAS requires you to specifically allow regular users to mount filesystems as described here.
- In the web interface under System > Sysctls > Add sysctl:
Grant ZFS permissions to the new user
In order for the dataset creation (full backup) feature to work the user we’ve created needs to have specific ZFS permissions granted as outlined here.
Run this command on both the main and backup servers:
zfs allow backup create,destroy,snapshot,rollback,clone,promote,rename,mount,send,receive,quota,reservation,hold storage
where backup is the new user and storage is the dataset name. I’m pretty sure you can make those permissions a little more fine grained but I threw a bunch of them in there for simplicity’s sake.
Configure HP iLo (optional)
My current backup server is an old HP Proliant server equipped with HP iLo. I decided to add a section in my script that, when enabled in the variables section, would have the script use iLo to power the machine on. If you do not have / wish to use iLo to control your backup server you can skip this section.
First, create a user in ILo and grant it Virtual Power and Reset permissions (all the rest can be denied.)
Next, copy the .pub file you created earlier to your computer so you can go into iLo web interface and upload it. Make sure an iLo user exists and the last part (the username) of the public key file matches exactly with the user you created in HP iLo.
When I first tried this no matter what I tried I couldn’t get passwordless login to work. After much weeping, wailing, and gnashing of teeth. I finally discovered from here that the -f and -C options of the ssh-keygen command are required for iLo to accept the key. I had to regenerate a private/public key pair via the following options, where backup is the user I created in iLo:
ssh-keygen -b 1024 -f backup -C backup