4 ms·

I think for me I am more concerned about trying to get the OS bootable again, if something becomes corrupted on the OS level. Even with MD RAID it came be a bit

I think for me I am more concerned about trying to get the OS bootable again, if something becomes corrupted on the OS level. Even with MD RAID it came be a bit of a struggle to recover, but ZFS on Root seemed much harder to troubleshoot and repair. Perhaps I am mistaken in this belief though?

aborsy 4y ago
Isn’t ZFS there precisely to address your concern?! If OS doesn’t boot, you boot from the latest snapshot! Every time you run apt-get upgrade, a system snapshots is taken automatically and an entry is added to boot menu.
- AviationAtom 4y ago
  I guess I was referring to more to corruption resulting in an unbootable system. If you can't boot in then how would you roll it back?
  - GekkePrutser 4y ago
    That's where backups come in. Any filesystem can get corrupted. Though for ZFS it's less likely than with something like ext4. Even though both have journalling, only ZFS has copy on write.
    - vetinari 4y ago
      My problem was rather with problematic updates of zfs itself. The update "helpfully" updated initramfs for older kernels too... and if something broke, it broke previous versions too, so they all were unbootable. Eventually I ended up with an USB stick at hand with known bootable environment :(
aborsy 4y ago
In Ubuntu’s implementation, root and boot are separate pools (bpool, rpool). Both are (and can be manually) snapshoted. So if boot is corrupted, you roll back. I should say I haven’t tried it though, to see how boot selection works (rolling back rpool is straightforward though). The boot corruption could occur with the default file system ext4 also, except with ext4 there l is no recourse. Needless to say, you can always boot from a live USB and mount your ZFS pool (and perhaps roll back).
mustache_kimono 4y ago
I've had to recover a ZFS on root system, whose bootloader installation I had somehow screwed up, and the process is pretty straight forward. See: https://openzfs.github.io/openzfs-docs/Getting%20Started/Ubuntu/Ubuntu%2020.04%20Root%20on%20ZFS.html#rescuing-using-a-live-cd https://openzfs.github.io/openzfs-docs/Getting%20Started/Ubu...

aborsy 4y ago

Isn’t ZFS there precisely to address your concern?! If OS doesn’t boot, you boot from the latest snapshot! Every time you run apt-get upgrade, a system snapshots is taken automatically and an entry is added to boot menu.

AviationAtom 4y ago
I guess I was referring to more to corruption resulting in an unbootable system. If you can't boot in then how would you roll it back?
- GekkePrutser 4y ago
  That's where backups come in. Any filesystem can get corrupted. Though for ZFS it's less likely than with something like ext4. Even though both have journalling, only ZFS has copy on write.
  - vetinari 4y ago
    My problem was rather with problematic updates of zfs itself. The update "helpfully" updated initramfs for older kernels too... and if something broke, it broke previous versions too, so they all were unbootable. Eventually I ended up with an USB stick at hand with known bootable environment :(

aborsy 4y ago

In Ubuntu’s implementation, root and boot are separate pools (bpool, rpool). Both are (and can be manually) snapshoted. So if boot is corrupted, you roll back. I should say I haven’t tried it though, to see how boot selection works (rolling back rpool is straightforward though). The boot corruption could occur with the default file system ext4 also, except with ext4 there l is no recourse. Needless to say, you can always boot from a live USB and mount your ZFS pool (and perhaps roll back).

mustache_kimono 4y ago

I've had to recover a ZFS on root system, whose bootloader installation I had somehow screwed up, and the process is pretty straight forward. See: https://openzfs.github.io/openzfs-docs/Getting%20Started/Ubuntu/Ubuntu%2020.04%20Root%20on%20ZFS.html#rescuing-using-a-live-cd https://openzfs.github.io/openzfs-docs/Getting%20Started/Ubu...