Snapshots of root partition
-
Hello,
on solaris systems when you start a system update, there's a boot environment that gets created automatically and in the boot menu you can select the one you want. This makes it easy to boot to boot a previous system if an update introduced a bug for example. You can also go back to the latest version if you need to.It doesn't happen too often but once in a while, a yum update will break the system and then you have to spend time trying to fix it with yum history and such only to give up and reinstall everything either from backup or scratch.
I read that on opensuse, they have a system called snapper with btrfs, on fedora 33 they also introduced btrfs snapshots. Eventually ubuntu will have zsys with zfs, snapper might also work I haven't explored it.
Is there something similar with RedHat and variants? I know RHEL dropped btrfs support some time ago so it's not possible to partition with that. ZFS will probably never happen. Stratis is a technology preview I think.
LVM feels old and quirky. Thanks for introducing me to ssm, that at least made creating LVM partition easier. There's at least 2 things I don't like about LVM:
- You have to specify the size of the snapshot, otherwise you get a warning every single time. That doesn't give me confidence that those snapshots can stay around for a long time.
- If you want to go back to the previous system, you have to merge the snapshot and then you lose it,
I know there's a tool called boom that helps boot from snapshots but it looks half baked. I still have to do a manual lvm snapshot, then create a grub entry with boom.
Is there an easy reliable way to protect your root filesystem before doing an update?
Thanks for pointers.
-
Pierre,
There are plenty of ways to do what you describe, but the "Red Hat" element limits your choices pretty heavily. Red Hat does not support ZFS, BTRFS, Boom, etc. This is mostly due to how inconsistent those tools can be and they default to supporting only tools that are reliable, tested, and tried and true. As frustrating as LVM can be, that is what we are left with if we want support from Red Hat, but doesn't entirely solve the boot problem.
Their recommendation is to test updates in a lab prior to rolling them out to production infrastructure. If something goes wrong, restore the system from a system backup (using dd or a similar tool). I wouldn't expect that to change anytime soon. Today's focus is on rapidly deployable images using automated deployment suites like Terraform, Ansible, OpenShift and Kubernetes. In those scenarios, the containers don't take kernel/boot updates and can easily be shifted to another system in the event an update to the host OS goes bad.