FreeNas Remote Backups


So I love that ZFS allows automated snapshots and that my FreeNas box is set up with a 3 disk Raid.  However, I’m paranoid.  What if the house burns down, or someone breaks in and steals all our computers?  A smart guy would have a remote backup somewhere.  So, I decided it was time to get my remote backup groove on.

I know that you can do a ZFS replication to another FreeNas box. The issue I have with that approach is that you have to replicate the entire ZFS volume. I needed something more granular.  So, I busted out some python and started working on a remote backup script. To give credit where it is due, my brother helped me get started…so thanks big brother. 

*Disclaimer*

I am not a programmer.  This code and instructions are provided “as is” with no warranty, promise that it works, promise that is won’t melt your computer or even cause the end of the World.  Use at your own risk.

The general overview of how the remote backup program works is like this. First the program connects to the remote computer and rsync’s all of your files. It’s setup so that you can have four different sets of remote backups all running on different days if you want. I personally am only using one backup that runs every day. Next, it determines the disk usage of the remote backup disk. It then calculates how long the backup took. Once it has all of that done, it compiles an email with a general status at the top and the details at the bottom. Continue reading

Advertisement

FreeNas Fix up


So here’s a quick tip. If you ever get your FreeNas install dorked up so bad that the Web-GUI stops working, grab your database file before you reinstall so you don’t have to re-configure.
The db file lives at:
/data/freenas-v1.db

You can then re-install a fresh FreeNas, drop this back in place via the webGUI and you should be up and running right where you were.

Not that I’d ever need to do something like that.

Edit:

So the really slick way to fix this is grab a FreeNas upgrade CD, slam it into the Nas box.  Boot from it.  Then let it “upgrade” your install and preserve your settings.

OpenVPN on FreeNAS 8.2


This article is no longer current, please go here for an updated writeup on OpenVPN on FreeNas

So I’ve been playing around with FreeNAS 8.2.  Decided it would be handy to have OpenVPN running on the fileserver so my wife and I can get to our files if we are away from home.  There are a couple of tricks that I discovered along the way to get this to work right.

***Make sure to read the comments as there are sample configs and a bunch of other useful stuff down there!!!***

If you find this super useful, I wouldn’t turn down paypal donations.

First the easy stuff.  We don’t have a static public IP, so I needed to set up a DynDNS account.  Once I did that, I configured the Dynamic DNS service on the FreeNAS box with my DynDNS account info.  Then started the service.

Next I needed to forward port 1194 on my gateway to the FreeNAS box.  So now I have a domain name to use and a port that forwards to my file server.

FreeNAS 8.2 has OpenVPN built in.  The config files that we need to be concerned with are:

/conf/base/etc/rc.conf
/conf/base/etc/local/openvpn

The thing about /conf/base/etc/local/etc/openvpn is that you need to create it.  Inorder to do that, you need to make the filesystem writeable.

mount -uw /
mkdir /conf/base/etc/local/openvpn

There is a really good tutorial on setting up OpenVPN here.  It goes through all the steps of generating your certificates, setting up your config files and the like. But pay no attention to the Adding routes to the OpenVPN server over at http://www.unix-heaven.org/node/47. The push route and route entries you enter below will handle that.

When you get to the point of configuring the /conf/base/etc/local/etc/openvpn/openvpn.conf file you’ll need to make a bit of a tweak from the norm to get things to work.  Here’s an excerpt of what was needed. You can find my full server and client configs in the comments below.

# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
push "route 192.168.0.0 255.255.255.0"
route 192.168.0.100 255.255.255.0 10.8.0.1

The “special” part is the route line. route (freeNAS-IP) subnet-mask 10.8.0.1
You’ll have to change the push “route” to match your network ip ranges too.

If you don’t make that entry, you’ll get an error like this in your server log:

OpenVPN ROUTE: OpenVPN needs a gateway parameter for a –route option and no default was specified by either –route-gateway or –ifconfig options
OpenVPN ROUTE: failed to parse/resolve route for host/network

Now add this to the end of /conf/base/etc/rc.conf

openvpn_enable="YES"
openvpn_if="tun"
openvpn_configfile="/usr/local/etc/openvpn/openvpn.conf"

If you make your config changes directly to /etc/rc.conf or /usr/local/etc/openvpn they will get blown away on restarts. So, now you should be able to restart your FreeNAS box. Then:

/usr/local/etc/rc.d/openvpn status

to see if OpenVPN is running.

I think that’s pretty much it. Let me know if you have any questions.

FreeNas Follies


Made the mistake of editing my zfs pools from the command line on FreeNas 8.0.2.  Ended up discovering something.  FreeNas uses a database to keep track of things like volumes and the like.  Manually messing with things from the command line throws things out of whack to the point that you have to go in and manually repair them.  So the procedure goes like this.

ssh into freenas.  su to root.  
Then sqlite3 /data/freenas-v1.db

Then list the tables

sqlite> .tables
account_bsdgroupmembership
account_bsdgroups
account_bsdusers
auth_group
auth_group_permissions
auth_message
auth_permission
auth_user
auth_user_groups
auth_user_user_permissions
django_content_type
django_session
network_alias
network_globalconfiguration
network_interfaces
network_lagginterface
network_lagginterfacemembers
network_staticroute
network_vlan
services_activedirectory
services_afp
services_cifs
services_dynamicdns
services_ftp
services_iscsitarget
services_iscsitargetauthcredential
services_iscsitargetauthorizedinitiator
services_iscsitargetextent
services_iscsitargetglobalconfiguration
services_iscsitargetportal
services_iscsitargettoextent
services_ldap
services_nfs
services_rsyncd
services_rsyncmod
services_services
services_smart
services_snmp
services_ssh
services_tftp
services_ups
sharing_afp_share
sharing_cifs_share
sharing_nfs_share
south_migrationhistory
storage_disk
storage_diskgroup
storage_mountpoint
storage_replication
storage_replremote
storage_task
storage_volume
system_advanced
system_cronjob
system_email
system_rsync
system_settings
system_smarttest
system_ssl
Then sqlite> select id, disk_description from storage_disk

Output for me was

1|Member of tank raidz
2|Member of tank raidz
3|Member of tank raidz
4|Member of tank raidz
5|Member of BigWest stripe
6|Member of BigWest stripe1

Now, delete your mistakes.

sqlite> delete from storage_disk where id=5;
sqlite> delete from storage_disk where id=6;

Now do the same for storage_volume and storage_diskgroup

I’m sure there are other ways you can make FreeNas unhappy, so maybe this little hint will help with that too.

Hacking Freenas – zfs replication


If you are trying to replicate your zfs volume to a remote system that doesn’t have port 22 forwarded to it…you can hack Freenas to use a different port.

Cliff notes version for myself is as follows:
ssh into freenas…su to root
“mount -uw /”
“vi /usr/local/www/freenasUI/tools/autorepl.py”
search for sshcmd using “/sshcmd”
After sshcmd = ‘/usr/bin/ssh insert -p and the port needed. Use i to insert in vi. then type -p 2020 or some port that works for you. hit esc then “:wq” to save and quit.

OK…that’s more than the cliff notes for myself. If you have any questions…feel free to ask.    Any hack changes like this will get squashed next time you upgrade freenas.  That said, I’ve heard from a reliable source that this is an option that is headed for a future release.

Also discovered that when you are setting the remote zfs filesystem…that if the filesystem is an existing zfs filesystem, you only need to use the name of the filesystem and not the path.