FreeNAS backup to eSATA with ZFS replication

[Robert Smith]

Has anybody goat a step-by-step tutorial for backing up and restoring a FreeNAS with data to/from eSATA attached disk(s) using ZFS replication? Specifically ZFS replication; not Crashplan, not RSYNC.

If there is no tutorial then what are the recommended strategies? Do everything in GUI? Do everything in CLI? Some kind of mix?

What works? What does not?

Thanks

 

[Robert Trevellyan]

If you want to automate the process, follow the documentation and use the GUI to set up a Periodic Snapshot Task and a corresponding Replication Task, with localhost as the Remote hostname.

If you want to do a one-time replication, e.g. so you can reconfigure your main pool, use the CLI. For me, this works best from the console (option 9), because replication can take a long time. Doing it over SSH means keeping the SSH login alive the whole time, or managing processes, and the built-in Shell isn't 100% reliable.

The zfs manual is your friend here. I don't have a step-by-step guide, but I can tell you that I did a recursive snapshot and a recursive zfs send | zfs receive each time I reconfigured my pool. I also used -v on the zfs receive to get an indication of progress. Always test the commands with the -n option before launching them for real. If necessary, practice in a VM.

 

[Robert Trevellyan]

I did a recursive snapshot and a recursive zfs send | zfs receive each time

Actually, that's not true. Sometimes I send and receive the larger datasets individually.

 

[Robert Smith]

What do you do after the replication is done and you want to disconnect the backup pool to take off-site?

Do you simply shut down FreeNAS and disconnect the drives. Or do you export the backup pool first? Do you export through CLI or through GUI?

 

[Robert Trevellyan]

Do you simply shut down FreeNAS and disconnect the drives. Or do you export the backup pool first? Do you export through CLI or through GUI?

If you want to take the backup offsite, you should definitely detach the pool using the Detach Volume button in GUI, then shut the box down and remove the drives. In this scenario, automated replication isn't going to be very useful.

 

[Robert Smith]

Cool. Thank you.

Have you ever practiced restore from such backup?

Let us say the building burned, and we have the replicated backup and the configuration database from the lost FreeNAS. What is the sequence to restore the FreeNAS back to the same condition with shares and users and everything?

Do we use the Volume Creation Wizard to create a new volume matching the name of the lost volume?

Then what? Replicate the backup pool to the newly created volume? Would there be any conflict with system dataset trying to replicate to the new system dataset in use?

Restore the configuration database as the last step?

 

[cyberjock]

Actually, if you replicate the entire pool and are silly enough (read: smart enough) to have kept the config file you can simply rename the backup pool to the original pool, import the config file and have your backup online and functioning within minutes. ;)

Then, all you have to do is worry about making a new backup of your data. :P

 

[Robert Smith]

Actually, if you replicate the entire pool and are silly enough (read: smart enough) to have kept the config file you can simply rename the backup pool to the original pool, import the config file and have your backup online and functioning within minutes. ;)

That should work...

So, to rename the pool is the following correct?

Do not auto-import the backup pool, instead go to CLI and run

Code:

zpool import backuppoolname mainpoolname

Then run

Code:

zpool export mainpoolname

and only after that do the GUI, Import Volume.

 

[Robert Smith]

How about the following, should that work too (for restore from backup)?

1. On a fresh FreeNAS install, auto-import the backup pool.

2. Create a new pool with the same name as the lost pool, out of fresh disks.

3. Replicate the backup pool to the newly created pool.

4. Detach the backup pool.

5. Shut down FreeNAS and disconnect the backup pool disks.

6. Restart the FreeNAS and restore the configuration database from the lost system.

Any holes in this plan? Would the old system dataset get damaged/overwritten while the FreeNAS is running off of the backup pool?

Why I simply would not rename the backup pool in this case is due to different desired disk configuration. The backup pool could be a simple mirror of big and slow drives, where the working pool I may want to have made out of a larger number of faster drives.

 

[Robert Smith]

Renaming the backup pool seems like a much simpler thing to do, though. May just do that and replicate again to fresh disks, and rename again. I do not see any potential to the system dataset damage/override that way then…

 

[Robert Trevellyan]

Have you ever practiced restore from such backup?

Yes, I reconfigured my pool a couple of times and each time I did a manual replication and restore to the new pool. I made sure the .system dataset was not on the pool that was the receiver during the replication (when you change the setting in the GUI FreeNAS moves the dataset for you).

The only thing I failed at was restoring plugins, but I no longer use any so that won't be an issue again. I did successfully restore my VirtualBox jail.

I didn't replicate the entire pool, so renaming was not an issue.

I have not used automated replication tasks.

 

[cyberjock]

Robert,

That should work. I just figured you may be trying to get up ASAP and don't want to be inconvenienced with making a new pool, replication time, etc.

 

[Robert Trevellyan]

I just figured you may be trying to get up ASAP and don't want to be inconvenienced with making a new pool, replication time, etc.

Yup. I actually considered that approach last time around but my box wouldn't run two eSATA cards at once so I didn't have enough bays to replicate directly to the new pool.