FreeNAS Disaster Recovery Installation

[DerJan]

I'm using bacula to regularly backup the whole user data stored on FreeNAS and in addition the /data directory which contains the FreeNAS configuration database. This backup is stored offsite it is mainly done for disaster recovery where either the ZFS Raid dies completely, the machine burns down or similar. Basically assume I have a brand-new box with new drives and this backup. I wanted to discuss what is required to re-build the box while avoiding to re-configure everything from scratch and then just restore the backup.

One approach I thought about would be to:

1. Install a fresh FreeNAS on the box, create a ZFS Storage and create all datasets with all names as before
   
2. Restore the user data from the backup
3. Restore the FreeNAS config from the backup

Would this allow me to retain most of the settings (like LDAP, Shares, User Permissions) or would there be issues because the ZFS is not the exactly same as was used originally? Is there also a way to store the ZFS structure of datasets and automate re-creating that part as well? Should I include something else in my backup?

Has someone already had a similar case and can share experiences?

 

[cyberjock]

Generally I tell people if your pool gets fried, might as well start with a new setup. You're going to have to redo all of your setup again anyway; zpool creation, dataset creation, permissions, etc, so why not start fresh. If you follow that logic backing up your freenas config file with bacula is just a waste. Not to mention your usernames and passwords for your server are stored in that database in plain text. So anyone that gets their grubby hands on your config file (which could be anyone thanks to "the cloud") will now know your passwords.

I backup my config file with a script that I posted to this forum every night automatically. It gets stored on my pool. The reason I don't store it anywhere else is because if my pool gets trashed I won't give a crap about my config file. I'm as good as starting over from scratch anyway. :P

 

[DerJan]

Generally I tell people if your pool gets fried, might as well start with a new setup. You're going to have to redo all of your setup again anyway; zpool creation, dataset creation, permissions, etc, so why not start fresh. If you follow that logic backing up your freenas config file with bacula is just a waste. Not to mention your usernames and passwords for your server are stored in that database in plain text. So anyone that gets their grubby hands on your config file (which could be anyone thanks to "the cloud") will now know your passwords.

I backup my config file with a script that I posted to this forum every night automatically. It gets stored on my pool. The reason I don't store it anywhere else is because if my pool gets trashed I won't give a crap about my config file. I'm as good as starting over from scratch anyway. :p

Well I feared that this is the current state of affairs so thanks for the honesty. If this was my home NAS, I would not spend a single thought about re-starting from scratch but in this setup, a lot of other services depend on the NAS being configured the way it is now so they can mount their storage and re-using those parts of the configuration would be quite a time-saver.

So I guess it's down to making screenshots of all the configurations or manually scraping out the backed up database with SQLite in case of a disaster.

Why are the passwords stored in plain-text and in which file are those passwords stored? Is that done for Samba which seems to require storing passwords in a plain-text equivalent format? Not that it matters since I backup to encrypted disks and not to the cloud thanks to a crappy internet connection.

 

[cyberjock]

The FreeNAS database, which is nothing more than an SQL database, can be found at /data/freenas-v1.db.

The passwords and such are stored in the database.

 

[titan_rw]

Not to mention your usernames and passwords for your server are stored in that database in plain text. So anyone that gets their grubby hands on your config file (which could be anyone thanks to "the cloud") will now know your passwords.

Can you show how this is so? For which passwords?

A quick parse through the freenas-v1.db file shows the same encrypted passwords that are stored in /etc/master.passwd.

Maybe outgoing mail settings, but my isp's smtp server doesn't need authentication, so there's no password there. Replication happens with ssh keys. I can't think of anything else that would need a saved password.

I personally can see having an off server backup of the config. For DR (stolen freenas box or something), you have to restore the config, and replicate back the pool. Probably reboot, and you should be good to go.

 

[cyberjock]

No, I can't off the top of my head. But this has been well known, even going back to 8.0.4 when I first started playing with FreeNAS. Long story short, back then we actively deleted database files that were posted because they contain sensitive info. Even if I were wrong about the passwords for the users, what about email addresses and passwords? What about passwords for dyndns? There's still *plenty* of stuff that can't be stored encrypted that must be accessible.

 

[titan_rw]

Didn't think about dyndns. My router does that for me, so I've never played with the client in freenas.

My email address will be in there somewhere in plaintext, but there shouldn't be any password for it.

In any case, I definitely wouldn't want to store the database file offsite without it being encrypted, or passworded somehow itself.

 

[DerJan]

Can you show how this is so? For which passwords?

A quick parse through the freenas-v1.db file shows the same encrypted passwords that are stored in /etc/master.passwd.

Maybe outgoing mail settings, but my isp's smtp server doesn't need authentication, so there's no password there. Replication happens with ssh keys. I can't think of anything else that would need a saved password.

It stores the Samba (LM/NTLM) hashes in the database. You can check by running this query on the config database

select bsdusr_smbhash from account_bsdusers;

According to this site it is not required to brute-force back the passwords to authenticate, you can just use the hashes. So this is some kind of clear-text equivalent even though you still don't know the passwords. As for other password information, I have found nothing in the database.

http://en.wikipedia.org/wiki/Pass_the_hash

Nothing I would lose my sleep over. Besides, the backups are encrypted so if they are stolen, tough luck.

I personally can see having an off server backup of the config. For DR (stolen freenas box or something), you have to restore the config, and replicate back the pool. Probably reboot, and you should be good to go.

Have you tried that? How does the system react when giving an old config to a fresh FreeNAS with a yet un-initialized pool?

 

[titan_rw]

Have you tried that? How does the system react when giving an old config to a fresh FreeNAS with a yet un-initialized pool?

It would probably simply give a "unable to mount pool" or something upon bootup of the old config. Replicate back the pool with zfs send / receive using netcat, or ssh, and another reboot would probably put everything back to rights.

 

[solarisguy]

It would probably simply give a "unable to mount pool" or something upon bootup of the old config. Replicate back the pool with zfs send / receive using netcat, or ssh, and another reboot would probably put everything back to rights.

The trick here is proper creation of the new pool. Restoration of the old data is kind of trivial (although you'd better calculate and test beforehand your copying speed).