ZFS What is the proper way to take snapshots and do rollbacks of zroot?

[mariourk]

Hi,

I'm sure this question gets asked a lot, but I couldn't find anything that made it absolutely clear. And since I view this as something vitaly important, I want it to be absolutely clear to me, before I start messing around on my servers. So, here it goes.

What is the proper way to take snapshots and do rollbacks of zroot?

I've been searching for a clear and direct explanation and example, how I should properly take a snapshot of zroot and roll it back in case something goes wrong. The closest I can find is this. But it still leaves me with some questions. No example of doing a rollback is given, for instance.

So, say I want to do an upgrade. What are the steps I should take, to take a snapshot of the entire root? And say something goes wrong. What are the steps I need to take, to rollback that snapshot and make everything ok again?

Thanks in advance.

 

[sko]

For this purpose instead of doing it manually, the better way would be using boot environments and sysutils/beadm to create and manage them.
The FreeBSD loader directly supports boot environments, so if something goes horribly wrong, just select the BE created prior to the update at the bootloader, or activate it with beadm and reboot.

If you let the installer create your zfs pool, the

 

[mariourk]

Thanks!

That seems like some mighty powerfull stuff. I'll dive into it and see if I can wrap my head around it.

One question though. Doesn't this mean that snapshots will be used for a long time? I always understood that it's not wise to keep snapshots for too long, as the difference between the snapshot and the original grows bigger and bigger.

 

[usdmatt]

Just to extend the beadm suggestion, there's not really an easy way to rollback the root file system without using single user mode. As such it's easier to clone snapshots to a new dataset, and then reboot using that as the root instead, which is pretty much what beadm is doing for you.

Some filesystems used to have separate snapshot storage that would fill up if you kept snapshots too long, and generally performed worse with snapshots enabled. With ZFS, snapshots are a fundamental part of the design and keeping snapshots is not really an issue regardless of how big they are - as long as you don't actually fill up the pool.

 

[ShelLuser]

Couldn't help notice that the question was never really answered.

What is the proper way to take snapshots and do rollbacks of zroot?

Depends. The proper way to create a snapshot is easy: # zfs snapshot zroot@<name of snapshot>. Assuming you used more virtual filesystems under the root hierarchy (for example: zroot/var which could be mounted on /var) then you can use the -r parameter (recurse) which will create snapshots on all the underlying filesystems as well.

And just to be complete: you'd remove ("destroy") those snapshots with the # zfs destroy zroot@<name of snapshot> command.

Now, rolling back....

The most important thing which I think too many people overlook is that you don't have to roll back an entire snapshot just to get access to certain old files. Let's say you messed up /boot/loader.conf. The proper way to restore that single file is easy: go to /.zfs/snapshot/<name of snapshot>/boot and copy the file to its proper location. Maybe you'd use # cp loader.conf /boot/loader2.conf so that you can use an editor to fix the whole thing later on.

In short: every virtual filesystem will have a (restricted and hidden) .zfs directory which gives you access to these things:

breve:/ $ ls -ad .*
.cshrc          .profile        .rnd
breve:/ $ cd .zfs
breve:/.zfs $ ls
shares/         snapshot/

And then there's the full rollback.

It is actually not that hard. My suggestion is to study zfs(8) manualpage and try to grasp the syntax used there. Because honestly: that shows you all you need to know. So: # zfs rollback zroot@<name of your snapshot>. If you need to rollback to a snapshot which is older than the most recent one then you'll need to use -r in order to destroy all snapshots which have become irrelevant.

So, say I want to do an upgrade. What are the steps I should take, to take a snapshot of the entire root? And say something goes wrong. What are the steps I need to take, to rollback that snapshot and make everything ok again?

Keep in mind that a snapshot is a backup of some sort, but not an offline backup. So if something were to go horribly wrong with your entire filesystem (lets say the upgrade procedure nuked the entire slice through gpart (just to come up with a very destructive yet highly unlikely scenario)... When that happens then a snapshot won't help you anymore because it got destroyed in the process.

Another thing is that depending on how you perform the upgrade you may already have ways to rollback without ZFS. freebsd-update(8) also has a rollback function which allows you to do just that.

Bottom line though: a snapshot is a decent backup, but it's not full proof.

But in short, you'd reboot, use the rollback command and that should basically be it.

 

[Oko]

Vanilla FreeBSD 10.xxx was far inferior to now dead PC-BSD/TrueOS server for this very reason. It was coming with sysutils/beadm pre-installed and FreeBSD boot loader replaced with Grub for easy selection of the boot environment from available snapshots. Not to mention that PC-BSD installer was tuned for root on ZFS mirror installation. Another feature was that pcbsd-update was a wrapper around freebsd-update which was taking beadm ZFS snapshot before the update and properly labeling them for possible use.

PC-BSD is dead. However it spirit lives on in FreeBSD 11. FreeBSD 11 installer is clumsy but perfectly capable for ZFS mirror root installation. Make sure you put swap on ZFS mirror as well since installer will not do that automatically for you even you install zroot on the ZFS mirror. FreeBSD boot-loader will give you an option to boot from a previous kernel snapshots taken by sysutils/beadm which unfortunately still has to be installed from the ports. You will also need to run beadm snapshot manually before running freebsd-update. I see no problems taking beadm snapshots only before the updates and keeping them around for that long. Finally FreeBSD 11 has being out almost a year and 11.1 is around the corner so even most conservative users like me should move on to it.

 

[phoenix]

FreeBSD 10.3 boot loader includes support for BEs, including booting to a different one than the "active" BE. Works quite nicely.