Backing up the FreeNAS flash drive itself

[mvt]

The only discussions I can find dealing with backup are about backing
up a client computer or data.
I am wondering how to back up (and restore) the flash drive containing
the FreeNAS operating system and all the additions and settings.

It seems to me that if you are running a FreeNAS with significant
tailoring, such as OwnCloud running in a jail, that a failure of the
flash drive would easily take down the system for an extended time
of rebuild and reconfigure. (right?)

How does one backup/restore the Flash Drive running everything?

Thanks.

Background:
I am still very new to this, although experienced in programming,
UNIX, local networks, etc. I have made one attempt at installing
FreeNAS, which looked successful but then failed to boot. So no
experience with FreeNAS.

My goal is a FreeNAS on new (cheap) hardware for a non-profit...
holding our newsletter editing files (for both Mac and PC), and
preferably with easy web access to allow photograph uploads from
our volunteers (most over 75 years of age). No need for speed,
such as streaming video.

 

[Bidule0hm]

The jails are on the data pool and you can backup the settings (System --> General --> Save Config button) so you don't backup/restore the system, if something goes wrong you just reinstall it and upload the saved config ;)

 

[danb35]

To elaborate a bit--the only thing on the flash drive that you need to back up is the config file. You can download it through the web GUI, and there are scripts floating around here to back it up to your pool on a schedule. Do a fresh install, upload the saved config, and you're good to go.

 

[DrKK]

I agree.

You are badly overestimating what's on the thumb drive. It's almost nothing, the only intersection between your various customizations and the boot drive is the configuration file. If you save that, then: you could make a brand new usb drive, from scratch, install a virginal FreeNAS on it, boot it, upload the configuration file you saved, then you will LITERALLY have the same system as you had before.

You don't read anything about backing up the FreeNAS boot device for the simple reason that no one would want to.

 

[mvt]

To all 3 who replied:
Thank you so much. That is a good clarification, and great news.

 

[nello]

… there are scripts floating around here to back it up to your pool on a schedule.

I presume this is one of the better configuration backup scripts:

https://forums.freenas.org/index.ph...backup-configuration-file-when-changed.12333/

Is another better for some reason or in certain circumstances?

- nello

 

[danb35]

That looks like a good one. I'm using @cyberjock's script, which is somewhat different, but there are many ways to skin this cat.

 

[nello]

I'm using @cyberjock's script …

I presume you are referring to:

https://forums.freenas.org/index.php?threads/backup-config-file-every-night-automatically.8237/

 

[Bidule0hm]

I've also made one who send the backup to an email address. If you're interested look at the link Useful Scripts in my signature.

 

[cyberjock]

I've also made one who send the backup to an email address. If you're interested look at the link Useful Scripts in my signature.

I personally find that option a very bad idea. Your passwords are stored in the SQL database in plain text, so anyone that happens to get that email, or anyone that intercept the email, has access to your configuration. Very dangerous game if you ask me. ;)

Before anyone cries foul about storing the passwords in plain text, there is no reason to encrypt them either. Anything you do to encrypt them must be 'decrypted' for the purposes of satisfying the configuration's function. So the bottom line is you should strongly control where and who has access to their config files.

 

[Bidule0hm]

I read that in the last updates of 9.3.0 the passwords are (finally...) hashed, it's not the case?

Because if they are in plain text I'll add a warning about that of course.

I'd say there's no excuse in 2015 to not hash passwords...

 

[cyberjock]

AFAIK they can never be hashed because you *have* to have them in plaintext to apply them in all of the various aspects, etc. Of course, I can be wrong, but when we had this argument about plain text with a few (very) vocal users back in 8.2.0 or so the argument was basically "they can't be encrypted without being easily decrypted and the code is freely available for FreeNAS there is no way to make it easily 'unhackable' so it isn't encrypted and don't bother asking for more because it's basically impossible."

At one point I had my script allow for emailing the passwords. I removed that function on purpose because the 'vulnerability' of that configuration is so high that anyone reading the warning, in my opinion, should be either capable of implementing the feature themself (which means they are technical enough to understand the very real risks) or likely incapable of understanding the risk and therefore shouldn't be doing it either. In both cases, it is unnecessary for me to provide the function in my script to satisfy 'reasonable' security requirements.

Just like I said above, there's something about the hashes not being useful enough for all of the functions we use them for.

I agree that "in 2015 to not hash passwords" but there are times where that is just flat out not an option. In the case of FreeNAS, since the OS is literally assembled on-the-fly on bootup you can't always use hashes since you aren't using a static setup. At least, that was the justtification for why it wasn't an option before. :p

Edit: Just asked a dev. They are now hashes (as of 9.3). So a little safer than plaintext. Still not something I'd recommend doing, but I guess the risk isn't as bad (for various definitions of bad, of course) but it's still something I'd never ever recommend doing. :p

For those that are curious.. it uses AES CTR.

 

[Bidule0hm]

the thing is you don't de-hash a hashed password (that's the whole point of hashes), you hash the one the user typed and you compare this hash to one in the config.

So, I'll look directly in one of my saved config to see with my own eyes if the pass are hashed or not, once for all :D

 

[cyberjock]

the thing is you don't de-hash a hashed password (that's the whole point of hashes), you hash the one the user typed and you compare this hash to one in the config.

So, I'll look directly in one of my saved config to see with my own eyes if the pass are hashed or not, once for all :D

I edited my post above.

I totally agree with the 'de-hashing' except the problem was that you couldn't store a hash and use it for all of the required functions, so you either stored it plaintext or config files won't work. Looks like the devs have it working as a hash now though.

 

[Bidule0hm]

Ok, now I wonder what hash type is used... because md5 isn't safe enough for important usages for several years now but despite that is still used in some new apps... I'll look at that but I'm busy right now.

Edit: I checked and FreeNAS use the SHA-512 hash (with a salt) so no problem at all. You can almost post your hash publicly on the net without any risks...

And I didn't think about it in the previous posts but if someone as access to your email box then there's something really wrong with your security policy in the first place...

 

[danb35]

if someone as access to your email box then there's something really wrong with your security policy in the first place

No doubt. But email travels through the Internet in plain-text, and a vulnerability on any system it passes through can expose its contents. Now, if you have your own mail server, and it's on the same LAN as your FreeNAS server, you should be pretty safe. If you're sending the config database to gmail/hotmail/yahoo/whatever, I wouldn't trust it without end-to-end encryption. You could probably script that too, but FreeNAS doesn't ship with gpg.

 

[Bidule0hm]

Yep, but the pass is (correctly) hashed so I wouldn't be worried about the config backup but more with any others sensitive emails in plain text if there was a vuln on the email path.