btrfs ways to travel back in time

btrfs ways to travel back in time

[Vytautas D]

I can think of few ways to revert changes with btrfs, but I wonder
what are the trade-offs between each method and perhaps there is
already research done on this?

ways to restore a snapshot ( post kernel 3.* ):
a) via set-default
 1. btrfs subvolume set-default / $id
 2. reboot
b) always mount into snapshot
 1. mount -o suvol=/.current $disk # at initrd
 2. btrfs subvol del /.current
 3. btrfs subvol snapshot /.snapshotA /.current
 4. reboot
c) rsync
 1. rsync $options /.snapshotA /.current
 2. reboot

- Vytas Dauksa

Re: btrfs ways to travel back in time

[Austin S. Hemmelgarn]

On 2016-03-23 13:41, Vytautas D wrote:
> I can think of few ways to revert changes with btrfs, but I wonder
> what are the trade-offs between each method and perhaps there is
> already research done on this?
>
> ways to restore a snapshot ( post kernel 3.* ):
> a) via set-default
>   1. btrfs subvolume set-default / $id
>   2. reboot
> b) always mount into snapshot
>   1. mount -o suvol=/.current $disk # at initrd
>   2. btrfs subvol del /.current
>   3. btrfs subvol snapshot /.snapshotA /.current
>   4. reboot
> c) rsync
>   1. rsync $options /.snapshotA /.current
>   2. reboot
>
I can't give much advice on these except to say that the last one listed 
is horribly inefficient and may break things (and use large amounts of 
space).

That said, I can share what I use on my systems to do this.  On all of 
my systems, I intentionally do not use the default subvolume feature, 
and always specify what subvolume to mount.  This allows me to take 
snapshots of the system prior to upgrades (or in other cases where I 
need a snapshot), and then roll back by doing the following:
1. mount LABEL=root /mnt/tmp
2. mv /mnt/tmp/root /mnt/tmp/old-root
3. mv /mnt/tmp/snap1 /mnt/tmp/root
4. touch /mnt/tmp/root/.rollback
3. reboot
6. An custom init script sees the file /.rollback, and then copies over 
any nested subvolumes from the old-root subvolume, renames old-root to 
old-$(date +%FT%T), and deletes /.rollback

This works because mounting with the 'subvol=' mount option only pays 
attention to the path, not the subvolume id or inode.

This can be done on a live system which is actively using the subvolume 
without disrupting normal operation, provided the subvolume itself is 
mounted as part of the FS hierarchy and not implicitly used via nesting. 
  All writes to the mounted subvolume still get sent to the old 
subvolume until the reboot happens (which is usually a good thing).

Re: btrfs ways to travel back in time

[Alexander Fougner]

2016-03-23 18:41 GMT+01:00 Vytautas D <vytdau@gmail.com>:
> I can think of few ways to revert changes with btrfs, but I wonder
> what are the trade-offs between each method and perhaps there is
> already research done on this?
>
> ways to restore a snapshot ( post kernel 3.* ):
> a) via set-default
>  1. btrfs subvolume set-default / $id

Usually snapshots are readonly because we want the ability to use
btrfs send/receive and not mistakenly change anything on them (such as
atime). Also, this might break some configurations not expecting the
set-default method.

>  2. reboot
> b) always mount into snapshot
>  1. mount -o suvol=/.current $disk # at initrd
>  2. btrfs subvol del /.current
>  3. btrfs subvol snapshot /.snapshotA /.current
>  4. reboot
> c) rsync
>  1. rsync $options /.snapshotA /.current
>  2. reboot

Depending on how broken the setup is, I'd probably go for the btrfs
sub snap ./__snapshots/@oldsnap ./@current approach.
If it is very broken (as in not bootable), then a temporary boot into
a readonly snapshot might be required. This is quite easy to do in
the grub menu, changing the boot parameter. I've also heard of
symlinking to the actual subvolume you want to use, and resymlink it
when an older snapshot is desired.

>
> - Vytas Dauksa
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs ways to travel back in time

[Vytautas D]

> atime). Also, this might break some configurations not expecting the
> set-default method

I have never seen this before. Can you extend on this or provide a
link so i can read more about such limitation?
>
> >  2. reboot
> > b) always mount into snapshot
> >  1. mount -o suvol=/.current $disk # at initrd
> >  2. btrfs subvol del /.current
> >  3. btrfs subvol snapshot /.snapshotA /.current
> >  4. reboot
> > c) rsync
> >  1. rsync $options /.snapshotA /.current
> >  2. reboot
>
> Depending on how broken the setup is, I'd probably go for the btrfs
> sub snap ./__snapshots/@oldsnap ./@current approach.
Is there a technical reason behind this ?

> If it is very broken (as in not bootable), then a temporary boot into
> a readonly snapshot might be required. This is quite easy to do in
> the grub menu, changing the boot parameter. I've also heard of
> symlinking to the actual subvolume you want to use, and resymlink it
> when an older snapshot is desired.

Just to make it clear, i don't have broken system and have full
control. I am interested in strategies and reasoning.

Re: btrfs ways to travel back in time

[Alexander Fougner]

2016-03-23 23:31 GMT+01:00 Vytautas D <vytdau@gmail.com>:
>
>> atime). Also, this might break some configurations not expecting the
>> set-default method
>
> I have never seen this before. Can you extend on this or provide a link so i
> can read more about such limitation?
>>

Ubuntu, for instance. Layout as /@ for root FS and /@home for /home.
Set-default will break this.

>> >  2. reboot
>> > b) always mount into snapshot
>> >  1. mount -o suvol=/.current $disk # at initrd
>> >  2. btrfs subvol del /.current
>> >  3. btrfs subvol snapshot /.snapshotA /.current
>> >  4. reboot
>> > c) rsync
>> >  1. rsync $options /.snapshotA /.current
>> >  2. reboot
>>
>> Depending on how broken the setup is, I'd probably go for the btrfs
>> sub snap ./__snapshots/@oldsnap ./@current approach.
> Is there a technical reason behind this ?
>

I'm not sure I understand what "this" refers to, but another way to do
it would be to just move the snap and set it as rw. But that consumes
the snapshot for further use.


>> If it is very broken (as in not bootable), then a temporary boot into
>> a readonly snapshot might be required. This is quite easy to do in
>> the grub menu, changing the boot parameter. I've also heard of
>> symlinking to the actual subvolume you want to use, and resymlink it
>> when an older snapshot is desired.
>
> Just to make it clear, i don't have broken system and have full control. I
> am interested in strategies and reasoning.

What I meant was that there are different levels of "breaking".
Depending on how bad the failure is, a rollback on the live FS might
be sufficient.

mv @ @broken
btrfs sub snap __snap/@_$date @
reboot

>>
>> >
>> > - Vytas Dauksa
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
>> > in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html