What if the FreeNAS host fails?

[aravindh]

Hello.
Newbie here, never built a FreeNAS setup or ZFS setup before this. Please pardon my innocence.

I'm thinking of building out a backup NFS server for our cluster based on a SuperMicro server as specified in my prior question: FreeNAS on SuperMicro SuperStorage Server 6049P-E1CR36H?

Thinking more about it, I'm wondering about failure scenarios. I trust ZFS to handle disk failures gracefully and not eat up all our data, but what about the host failure (say a hardware failure) that prevents me from booting back in to FreeNAS again...
Would I be able to build out another FreeNAS server and just move the disks (with ZFS data) to the new server and have them recognised?
I did some Googling before, and read everywhere as a migration scenario to issue a "zfs export" on the pools and then do a "zfs import" on the new system. I can't do that on a host crash. What would the solution be?

Thanks.

 

[Ericloewe]

Would I be able to build out another FreeNAS server and just move the disks (with ZFS data) to the new server and have them recognised?

Yes.

I did some Googling before, and read everywhere as a migration scenario to issue a "zfs export" on the pools and then do a "zfs import" on the new system. I can't do that on a host crash. What would the solution be?

ZFS can easily recover from most improperly exported pools. It's not magic and doesn't absolve you from maintaining your backups, but it's better than other filesystems.

 

[Chris Moore]

Thinking more about it, I'm wondering about failure scenarios.

You should not need a whole new server. That is pretty drastic.
Most likely, you can just fix whatever broke and be back online.
I have had boot drives fail in a couple different servers over the years, and after replacement of the boot drive, and reinstall the OS, the pool was imported and services restored with just a couple hours of down time.
I also have had a SAS controller failure that took the storage offline. Once the SAS HBA was replaced, the server was able to boot as normal and the system fully recovered with no problems. Time to fix was less than one hour.
ZFS was designed to be a enterprise solution. It is very robust.

Sent from my SAMSUNG-SGH-I537 using Tapatalk

 

[Arwen]

2 things;

1. Backup your configuration, both off server and in pool.
2. Second, while ZFS is widely used in the server market, it's much less used on Linux, or the desktop. (I do use it on my desktop and laptop.) So understand that generic Linux, (and of course MS-Windows), won't have ZFS support.

I am aware that Ubuntu has started ZFS, but it's not as straight forward as FreeBSD/NAS.

 

[NAS-Plus]

What do you mean when you say:

1. Backup your configuration, both off server and in pool.

I'm only aware of one configuration backup method.

 

[Arwen]

What do you mean when you say:

1. Backup your configuration, both off server and in pool.

I'm only aware of one configuration backup method.

The is a script that people run on the FreeNAS via cron that saves the configuration to disk. I chose my data pool, backup dataset for the destination. Thus, it might be more current than the one I have stored off server. I have enough Unix & ZFS skills to extract it if I loose both of my mirrored boot devices.

Sorry, I don't have a pointer to it handy.

 

[danb35]

The is a script that people run on the FreeNAS via cron that saves the configuration to disk.

Not only that, FreeNAS itself backs up the config file whenever it's changed. It's been doing that for years now. Those backups go into the .system dataset, which by default is stored on your first data pool.

 

[Chris Moore]

Sorry, I don't have a pointer to it handy.

@NAS-Plus I think that the script that Arwen is referring to can be found here:
https://forums.freenas.org/index.ph...or-freenas-and-vmware-esxi.52298/#post-361299
I have not looked lately, but I think there is also an option to have the config file emailed.
I have the script run by cron on a weekly basis and the location it saves to on my pool gets rsynced to another server so I can access it even if the server the backup is for goes down.

 

[Jatrabari]

I also have had a SAS controller failure that took the storage offline. Once the SAS HBA was replaced, the server was able to boot as normal and the system fully recovered with no problems. Time to fix was less than one hour.
ZFS was designed to be a enterprise solution. It is very robust.

Sent from my SAMSUNG-SGH-I537 using Tapatalk

So you just replaced the broken one with the new one and it was recognized straight away and also the pools were recovered just fine?

 

[Chris Moore]

So you just replaced the broken one with the new one and it was recognized straight away and also the pools were recovered just fine?

Yes. Half the disks in the pool were connected to one SAS controller and were still visible but the pool was not available because too many devices were missing. When the system booted after the failed SAS controller was replaced, all the drives were available and the pool was imported and worked normally again. The whole thing was very painless.

 

[Jatrabari]

Yes. Half the disks in the pool were connected to one SAS controller and were still visible but the pool was not available because too many devices were missing. When the system booted after the failed SAS controller was replaced, all the drives were available and the pool was imported and worked normally again. The whole thing was very painless.

Ok, great to know. And import was done just using zfs import command?

Would it matter if you have a different brand HBA if the original wasn't available or you would switch from for example 2x 8 port HBAs to 1x 16 port or vice versa?

 

[Chris Moore]

Ok, great to know. And import was done just using zfs import command?

Would it matter if you have a different brand HBA if the original wasn't available or you would switch from for example 2x 8 port HBAs to 1x 16 port or vice versa?

Something to understand about FreeNAS, the way it works, it exports the pool every time you shutdown the server and imports the pool every time you boot the server. As long as there is a viable data path to the disks, they could be connected in almost any combination of ways. You could (for example) have a pool that was created while connected to a SATA controller and import that pool in a different server that has part of the disks connected by SATA and the rest connected by SAS. Then you could bring the same set of disks to another server where all the disks were connected by SAS. The order of the disks in not important and the type of controller (as long as it is supported hardware) is not important. The operating system just needs to be able to find them all and it will spend time probing all the available controllers and disks to see what is out there.