BTRFS/Rollback & Yum Snapshot Plugin

[Chris Murphy]

On Feb 5, 2014, at 4:23 AM, Jorge Fábregas <jorge.fabregas at gmail.com> wrote:
> 
> I haven't follow the openSUSE community for years.  Do you think they've
> nailed most of these issues? or all distros on the same boat ?

I'd say it's all pretty much up in the air. openSUSE uses snapper by default, so they take snapshots right before and right after an update. But it also has some interactivity, so you can list things and say you want to rollback to a certain state/time and it will do that for you.

> 
> My impression is that , until it gets to be the default filesystem on
> most distros, these issues (of rolling back system via snapshots) won't
> get much attention.  Do you agree?

Yes. It's going to be like a first time cattle rustle. It's not like you get to do a trial run for practice. When you do one for real, some people simply are going to get broken legs. The lack of urgency on many issues is due to it not being default. 

But everyone keeps at least two pristine backups, right? And they've done a full blown restore procedure to confirm both backup strategies are really working (i.e. restorable), right?


> At this point I don't see any value for the yum plugin.  It simply does
> the autoamtic snapshotting before applying updates.  It flies the
> airplaine but doesn't land it.  That is, the advanced user who knows how
> to: modify GRUB, fstab, specify subvolume, in order to rollback its
> system, already knows how to create the snapshot in the first place.

It's a good proof of concept. But it is a bit like a game of cards with just a dealer. But that just means we need some decisions on other details, and find someone to implement them!


> I haven't played with snapper.  I don't know if it just a tool to
> create/delete/manage/rotate snapshots or if it automates all of these
> things in order to rollback your system.  I'm still learning the basics
> of btrs so I wanted to avoid any front-end tools.

It automates some of this, I'm not sure of the extent by which it "ages" snapshots and cleans them up. It doesn't automatically do rollbacks, but if you tell it to go back to a state then it uses those snapshots to do it. I don't know for sure, but I think, by default it will rollback just the system, separate from home. That's the default behavior we'd probably want.

And yes it's understandable to use the btrfs tools directly to gain familiarity.


> 
> 
>> Note also that opensuse has a different layout for all of this than
>> Fedora. They make the default subvolume ID 5 (the top level of the Btrfs
>> file system, the first subvolume, the one that can't be deleted or named)
>> the parent and mount it at /. And then create the following subvolumes:
>> 
>> boot/grub2/x86_64-efi
>> home
>> opt
>> srv
>> tmp
>> usr/local
>> var/crash
>> var/log
>> var/opt
>> var/spool
>> var/tmp
> 
> Interesting.  I think Fedora's way looks more simple.  I guess there are
> pros & cons for each.

It's all about granularity of what should be rolled back and when. The Fedora method is simple. If we rollback all of root that's pretty safe from a strictly system rollback perspective, but it does mean you're also rolling back logs (which users may expect, I'm not sure), and if you're running a server it means rolling back /var/spool which actually may be a problem if mail is stored there.

While I think the FHS needs updating (it's 10 years old), the reality is there's no way to organize the file system for a one size fits all snapshot-rollback policy. The data loss [1] with a single policy would almost always be unacceptable. A bad update might take an hour, day, or even a week to realize that a rollback is a good way to solve the problem, in the meantime /home has accumulated valuable user data. The simplest practical policy, is a dual policy: rollback /home, or rollback everything except /home. It only gets more involved there, i.e. there isn't such a thing is one kind of rollback. It'll depend on the circumstances.

[1] Not really lost, it's just not available. It's in a snapshot somewhere.



Chris Murphy