snapshot rollback

snapshot rollback

[Ulli Horlacher]

This is a conceptual btrfs question :-)

I have this btrfs filesystem:

root@xerus:~# mount | grep /test
/dev/sdd4 on /test type btrfs (rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)

with some snapshots:

root@xerus:~# btrfs subvolume list /test
ID 736 gen 9722 top level 5 path .snapshot/2018-12-02_1215.test
ID 737 gen 9722 top level 5 path .snapshot/2018-12-02_1216.test
ID 738 gen 9722 top level 5 path .snapshot/2018-12-02_1217.test

I now want to do a rollback to .snapshot/2018-12-02_1217.test
I can do it with:

mount -t btrfs -o subvol=.snapshot/2018-12-02_1217.test /dev/sdd4 /test

But (how) can I delete the original root subvol to free disk space?

  
-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<20190705103823.GA13281@tik.uni-stuttgart.de>

Re: snapshot rollback

[Ulli Horlacher]

On Fri 2019-07-05 (12:38), Ulli Horlacher wrote:

> But (how) can I delete the original root subvol to free disk space?

Found:

https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-subvolume

  A freshly created filesystem is also a subvolume, called top-level,
  internally has an id 5. This subvolume cannot be removed or replaced by
  another subvolume.


Ok, it seems my idea (replacing the original root subvolume with a
snapshot) is not possible. 


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<20190705103823.GA13281@tik.uni-stuttgart.de>

Re: snapshot rollback

[Remi Gauvin]

[-- Attachment #1.1: Type: text/plain, Size: 1742 bytes --]

On 2019-07-05 7:06 a.m., Ulli Horlacher wrote:

> 
> Ok, it seems my idea (replacing the original root subvolume with a
> snapshot) is not possible. 
> 

Disclaimer: You probably want to wait at least 24 hours before trying my
directions in case anyone has am important correction to make.  You
should have a means of recovering in case I got it completely wrong.
(ie. good backups)

It is common practice with installers now to mount your root and home on
a subvolume for exactly this reason.  (And you can convert your current
system as well.  Boot your system with a removable boot media of your
choice, create a subvolume named @.  Move all existing folders into this
new subvolume.  Edit the @/boot/grub/grub.cfg file so your Linux boot
menu has the @ added to the paths of Linux root and initrd.

Ex:

linux   /@/boot/vmlinuz-4.15.0-43-generic
root=UUID=78d04a41-3786-4140-aeb8-5f2f809e7ba7
initrd  /@/boot/initrd.img-4.15.0-43-generic

(you can make this change directly into the grub menu at boot time
instead of editing  the grub.cfg file, if you prefer.)

Edit the @/etc/fstab file so that mount points to the device we are
changing have the subvol=@ option.

Example:

UUID=78d04a41-3786-4140-aeb8-5f2f809e7ba7 /               btrfs
noatime,nossd,subvol=@ 0       1


Reboot, and if the system successfully boots, you should run update-grub
to fix up the grub.cfg file.

From a running system, if you need to see the root subvolume again, (so
you can see and manipulate the @ subvol,), mount it somewhere else:

mkdir /mnt/sda1
mount /dev/sda1 /mnt/sda1

From that point forward, it's easy to rename /mnt/sda1/@ and replace it
with a snapshot of your choice,. (then reboot.)





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: snapshot rollback

[Graham Cobb]

On 05/07/2019 12:47, Remi Gauvin wrote:
> On 2019-07-05 7:06 a.m., Ulli Horlacher wrote:
> 
>>
>> Ok, it seems my idea (replacing the original root subvolume with a
>> snapshot) is not possible. 
>>
> ...
> It is common practice with installers now to mount your root and home on
> a subvolume for exactly this reason.  (And you can convert your current
> system as well.  Boot your system with a removable boot media of your
> choice, create a subvolume named @.  Move all existing folders into this
> new subvolume.  Edit the @/boot/grub/grub.cfg file so your Linux boot
> menu has the @ added to the paths of Linux root and initrd.

Personally, I use a slightly different strategy. My basic principle is
that no btrfs filesystem should have any files or directories in its
root -- only subvolumes. This makes it easier to do stuff with snapshots
if I want to.

For system disks I use a variant of the "@" approach. I create two
subvolumes when I create a system disk: rootfs and varfs (I separate the
two because I use different btrbk and other backup configurations for /
and /var). I then use btrfs subvolume set-default to set rootfs as the
default mount so I don't have to tell grub, etc about the subvolume (I
should mention that I put /boot in a separate partition, not using btrfs).

In /etc/fstab I mount /var with subvol=varfs. I also mount the whole
filesystem (using subvolid=5) into a separate mount point
(/mnt/rootdisk) so I can easily get at and manipulate all the top-level
subvolumes.

Data disks are similar. I create a "home" subvolume at the top level in
the data disk which gets mounted into /home. Below /home, most
directories are also subvolumes (for example, one for my main account so
I can backup that separately from other parts of /home). I mount the
data disk itself (using subvolid=5) into a separate mount point:
/mnt/datadisk -- which I only use for doing work with messing around
with the subvolume structure.

It sounds more complicated than it is, although it is not supported by
any distro installers that I am aware of. And you should expect to get a
few config things wrong while setting it up and will need to have an
alternative boot to use to get things working (a USB disk or an older
system disk). Particularly if you want to use btrfs-over-LVM-over-LUKS.
And don't forget to fully update grub when you think is working and then
test it again without your old/temporary boot disk in place!

Basically, I make many different subvolumes and use /mount to put them
into the places they should be in the filesystem (except for / for which
I use set-default). The real btrfs root directory for each filesystem is
mounted (using subvolid=5) into a separate place for doing filesystem
operations.

I then have a cron script which checks that every directory within the
top level of each btrfs filesystem (and within /home) is a subvolume and
warns me if it isn't (I use special dotfiles within the few top-level
directories which I don't want to be their own subvolumes).

Contact me directly if you would find my personal "how to set up my
system and root disks, for debian, using btrfs-over-lvm-over-luks" notes
useful.

Graham

Re: snapshot rollback

[Chris Murphy]

On Fri, Jul 5, 2019 at 4:45 AM Ulli Horlacher
<framstag@rus.uni-stuttgart.de> wrote:
>
>
> This is a conceptual btrfs question :-)
>
> I have this btrfs filesystem:
>
> root@xerus:~# mount | grep /test
> /dev/sdd4 on /test type btrfs (rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)
>
> with some snapshots:
>
> root@xerus:~# btrfs subvolume list /test
> ID 736 gen 9722 top level 5 path .snapshot/2018-12-02_1215.test
> ID 737 gen 9722 top level 5 path .snapshot/2018-12-02_1216.test
> ID 738 gen 9722 top level 5 path .snapshot/2018-12-02_1217.test
>
> I now want to do a rollback to .snapshot/2018-12-02_1217.test
> I can do it with:
>
> mount -t btrfs -o subvol=.snapshot/2018-12-02_1217.test /dev/sdd4 /test
>
> But (how) can I delete the original root subvol to free disk space?

Near as I can tell you have to stop using whatever is using the
subvolume you consider stale, so that you can umount the subvolme and
then delete it. I think the more complicated rollback is for system
root because that pretty much takes a reboot to clean everything up.
So for example:

[chris@flap ~]$ sudo btrfs sub list -t /
ID    gen    top level    path
--    ---    ---------    ----
258    38163    5        home
274    38155    5        root
280    36478    5        images
281    12926    5        home.20190624
282    12927    5        root.20190624
283    17109    5        root.20190626
285    17573    5        root.20190626-2
286    17840    5        root.20190626-3
# mount /dev/ /mnt
# mv root rootold
# btrfs sub snap root.20190626-3 root
## reboot when I'm ready to rollback

The system does not get cranky at the rename. The mount command
immediately sees the rename so 'rootold' is still mounted at / and
everything works. But on reboot, I get a rollback. And I don't have to
update grub stuff this way. And then at my leisure I delete the
rootold subvolume.

In any case, I would not do a rollback by directly using the subvolume
I want to rollback to, I would make a snapshot of it and use the
snapshot. That way if I do something stupid during the rollback, I
haven't messed up my only copy of that subvolume.

For /home, it's similar except I just log out instead of reboot. It's
slightly annoying that I need root user enabled, because of course if
I login as chris, the subvolume mounted on /home is pinned. I can't
umount it now. Or alternatively a slightly more complicated setup with
each user getting their own subvolume, and then I could login as some
alternate admin user to do the rollback. But I'd still do it the same
way: umount /home, rename the subvolume, snapshot the snapshot I want
to rollback to giving it the name that's used in fstab, and then I
just 'mount /home' and continue on.


-- 
Chris Murphy

Re: Snapshot rollback

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/24/2011 10:04 PM, Arand Nash wrote:
> Btrfs is unfortunately unable to look for snapshots by name above the
> currently set default root (I do not know why exectly), it can however
> find them by id anywhere.

Ok, so looking up subvols by name uses the default subvol to resolve the
name, and so when I change the default subvol to the snapshot of @,
there is no @home name there pointing to the subvol?  Things make much
more sense knowing that.  I thought that the subvolumes had their own
namespace outside of any one subvolume.

Is there a way to create another name entry in @snap that points to
@home, or can you only have the original @home entry in the default subvol?

> To backup
> ~# mount /dev/sda1 /mnt
> ~# ls /mnt
> @ @home
> ~@ btrfs sub snap /mnt/@ /mnt/@rootsnap
> ~# ls /mnt
> @ @home @rootsnap
> 
> And to rollback:
> ~# mv /mnt/@ /mnt/@rootmessy
> ~# mv /mnt/@rootsnap /mnt/@
> And just reboot, since it just mounts whatever is named "@/".

Perfect... I think I'll keep the default subvol mounted under /.subvols
to make managing them easy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6nYtIACgkQJ4UciIs+XuJ/CQCgsbMLAY/h9opq/T7qBJKKrSz2
v0cAnRq8PKp1jx9r4Q6X4J6Ixjv3KpeS
=GSCn
-----END PGP SIGNATURE-----

Re: Snapshot rollback

[Fajar A. Nugraha]

On Tue, Oct 25, 2011 at 3:54 PM, dima <dolenin@parallels.com> wrote:
>>> Hi Fajar,
>>> I think I am doing just this, but my subvolumes are not visible und=
er
>>> /boot. I
>>> have all my subvolumes set up like this:
>>> /path/to/subvolid_0/boot< =A0a simple directory bind-mounted to /
>>> /path/to/subvolid_0/__active< =A0my / subvolume
>>> /path/to/subvolid_0/__home< =A0my /home subvolume
>>
>> Actually with that setup you're using option (3) that I described.
>>
>> That means all your subvolumes is still visible under
>> /path/to/subvolid_0/, right? I'm not sure how well grub can manage
>> this. Probably it can't, so you'd have to manage boot entries
>> manually.
>
> Yes, you are right. I can see all subvolumes under /path/to/subvolid_=
0
> By the way grub2 can manage this setup correctly and generate the rig=
ht menu
> entries without any problems.
>
> But - /boot is not in its own subvolume in this setup. I think this i=
s the
> reason it works out of the box.
>
> Thank you for your explanations.
> I can see if I can make it work with /boot in its own subvolume.

If you currently have it working, then as long as you have the full
subvolid=3D0 mounted somewhere and use bind-mount from that, it
shouldn't matter whether it's a subdir or a subvol. But if you mount
the subvol directly in /boot, you'll have the same problem I do.

So it's a trade off, I guess. You can have grub manage grub.cfg
correctly, but you need to have the full tree mounted somewhere. Not
ideal, but a possible option which I hadn't thought of before.

Thanks for sharing your setup.

--=20
=46ajar
--
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: Snapshot rollback

[dima]

On 10/25/2011 05:01 PM, Fajar A. Nugraha wrote:
 > On Tue, Oct 25, 2011 at 9:00 AM, dima<dolenin@parallels.com>  wrote:
 >> Fajar A. Nugraha<list<at>  fajar.net>  writes:
 >>
 >>> AFAIK you have three possible ways to use /boot on btrfs:
 >>>
 >>> (1) put /boot on subvolid=0, don't change the default subvolume. That
 >>> works, but all your snapshot/subvols will be visible under /boot. Some
 >>> people might not want that for estetic reason.
 >>
 >> Hi Fajar,
 >> I think I am doing just this, but my subvolumes are not visible 
under /boot. I
 >> have all my subvolumes set up like this:
 >> /path/to/subvolid_0/boot<  a simple directory bind-mounted to /
 >> /path/to/subvolid_0/__active<  my / subvolume
 >> /path/to/subvolid_0/__home<  my /home subvolume
 >
 > Actually with that setup you're using option (3) that I described.
 >
 > That means all your subvolumes is still visible under
 > /path/to/subvolid_0/, right? I'm not sure how well grub can manage
 > this. Probably it can't, so you'd have to manage boot entries
 > manually.

Yes, you are right. I can see all subvolumes under /path/to/subvolid_0
By the way grub2 can manage this setup correctly and generate the right 
menu entries without any problems.

But - /boot is not in its own subvolume in this setup. I think this is 
the reason it works out of the box.

Thank you for your explanations.
I can see if I can make it work with /boot in its own subvolume.

~d

Re: Snapshot rollback

[Fajar A. Nugraha]

On Tue, Oct 25, 2011 at 9:00 AM, dima <dolenin@parallels.com> wrote:
> Fajar A. Nugraha <list <at> fajar.net> writes:
>
>> AFAIK you have three possible ways to use /boot on btrfs:
>>
>> (1) put /boot on subvolid=3D0, don't change the default subvolume. T=
hat
>> works, but all your snapshot/subvols will be visible under /boot. So=
me
>> people might not want that for estetic reason.
>
> Hi Fajar,
> I think I am doing just this, but my subvolumes are not visible under=
 /boot. I
> have all my subvolumes set up like this:
> /path/to/subvolid_0/boot =A0 =A0 =A0 < a simple directory bind-mounte=
d to /
> /path/to/subvolid_0/__active =A0 < my / subvolume
> /path/to/subvolid_0/__home =A0 =A0 < my /home subvolume

Actually with that setup you're using option (3) that I described.

That means all your subvolumes is still visible under
/path/to/subvolid_0/, right? I'm not sure how well grub can manage
this. Probably it can't, so you'd have to manage boot entries
manually.

>
>
>> (3) put /boot on a subvolume, do not change the default subvolume, a=
nd
>> manage grub.cfg manually. This is what I currently do.
>
> Could you elaborate about this option pls., and if possible post your=
 grub.cfg?
> I don't quite understand how it works. Though I am doing syslinux at =
the moment,
> I think the process is the same.

=46or example, with the following subvolume sturcture (using default
subvolid 0, unchanged)

/
/boot
/root
/home

=2E.. and fstab set to mount subvol "boot" on /boot. Then when grub
looks for kernels and initrd it'd see that /boot is it's own block
device, so it's use /vmlinuz and /initrd in grub.cfg.

However, when grub actually boots, it'd see the files located an
/boot/vmlinuz and /boot/initrd, and when reading the configuration
it'd be unable to find the files (since from grub's point of view
there's nothing on /vmlinuz and /initrd). Which is why I said you'd
need to manage grub.cfg manually in this setup.



=46or comparison purposes, I'd just setup two versions of Ubuntu with
zfs / and /boot. In a way it's kinda like having different linux
distros/versions installed on different partitions with one master
bootloader choosing which partition is active. Each distro/version can
manage it's own boot configuration file without disturbing each other
(e.g. oneiric won't be able to see natty's kernel and initrd).
Although the initial setup is done manually, each version's grub will
be able to manage it's own kernels and initrd independently. The setup
is something like this:

# zfs list | grep boot
rpool/ROOT/oneiric/boot             23.3M   369G  23.3M
/rpool/ROOT/oneiric/boot
rpool/ROOT/natty/boot             121M   369G  96.3M  /rpool/ROOT/natty=
/boot
rpool/boot                          1.32M   369G  1.32M  /rpool/boot

rpool/boot is where the "master" configuration file for grub is
installed. It's job is to select which configfile (oneiric or natty)
to use next, so it's something like this

#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
# cat /rpool/boot/grub/grub.cfg
insmod part_msdos
insmod zfs

search --no-floppy --fs-uuid --set=3Droot c4f4006ef59df197
set timeout=3D1

menuentry 'Ubuntu Natty boot menu' {
	configfile	/ROOT/natty/boot/@/grub/grub.cfg
}
menuentry 'Ubuntu Oneiric boot menu' {
	configfile	/ROOT/oneiric/boot/@/grub/grub.cfg
}
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Each Ubuntu version has it's own /boot directory, which will be
mountted as /boot when it's active, but remains unmounted (or mounted
in alternate path) when it's inactive. grub's zfs support will use
dataset name as part of path (regardless where it's currently
mounted), so the config for oneiric looks something like this

#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
menuentry 'Ubuntu, with Linux 3.0.0-12-generic' --class ubuntu --class
gnu-linux --class gnu --class os {
	search --no-floppy --fs-uuid --set=3Droot c4f4006ef59df197
	linux	/ROOT/oneiric/boot/@/vmlinuz-3.0.0-12-generic root=3D/dev/sda5 r=
o
boot=3Dzfs boot=3Dzfs rpool=3Drpool bootfs=3Drpool/ROOT/oneiric
	initrd	/ROOT/oneiric/boot/@/initrd.img-3.0.0-12-generic
}
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Unfortunately this kind of setup is currently not possible with btrfs.

--=20
=46ajar
--
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: Snapshot rollback

[Arand Nash]

On 25/10/11 02:45, Phillip Susi wrote:
 > (...)
>
> On 10/24/2011 01:45 AM, dima wrote:
>> Hello Phillip,
>> It is hard to judge without seeing your fstab and bootloader config. Maybe your
>> / was directly in subvolid=0 without creating a separate subvolume for it (like
>> __active in Goffredo's reply)? In my very humble opinion, if you have your @home
>> subvolume under subvolid=0 and then change the default subvolume, it just cannot
>> access your @home any more.
>
> Why can't it?
>
> It appears that Ubuntu sets up two subvols, one named @ and one named
> @home, and mounts them at / and /home respectively.  The boot loader was
> set to pass rootflags=subvol=@.  After changing the default volume, the
> system would not boot until I removed that rootflags argument, then it
> mounted the snapshot correctly as the root, but refused to mount /home,
> giving this nonsense error that /dev/sda1 is not a valid block device.
 >
 > (...)

Btrfs is unfortunately unable to look for snapshots by name above the 
currently set default root (I do not know why exectly), it can however 
find them by id anywhere.

In the case of (Debian?) Ubuntu, you should pretty much stay away from 
set-default.

What happens is Ubuntu mounts the _default_ subvolume, which in the 
normal case refers to the top of the btrfs tree (alias subvolid=5), then 
it looks below this for the subvolumes ("directories") named "@/" (given 
by the boot option) and "@home/" (given in fstab).

Now, when you use set-default here, it will instead mount that subvolume 
as the default, and then look _below_ that for "@/" and "@home/", 
obviously, this won't work, since these exist higher up in the tree.

When you disable the rootflags argument, btrfs assumes the default 
subvolume is the root, which works, as noted.

In order to find "@home/", you could rewrite the fstab to instead of 
"subvol=@home" read "subvolid=###", since by specifying id instead of 
name, it can find it anywhere in the tree, the subvolid can be found via
~# btrfs subvolume list /


HOWEVER, this is not the way btrfs is intended to be used on Ubuntu.
As mentioned earlier, you likely will not want to touch set-default, 
instead, when you want to muck around with your mounting sobvolumes, you 
just use mv:

To backup
~# mount /dev/sda1 /mnt
~# ls /mnt
@ @home
~@ btrfs sub snap /mnt/@ /mnt/@rootsnap
~# ls /mnt
@ @home @rootsnap

And to rollback:
~# mv /mnt/@ /mnt/@rootmessy
~# mv /mnt/@rootsnap /mnt/@
And just reboot, since it just mounts whatever is named "@/".


Now in your case, if you want to go back to the Ubuntu default btrfs 
setup, you would:
~# btrfs subvolume set-default 5 /
(since id 5 is always the top of the tree)
And reinstate the rootflags boot option.


Hope that explains some of it.

--
Martin Werner ("arand")

Re: Snapshot rollback

[dima]

Fajar A. Nugraha <list <at> fajar.net> writes:

> AFAIK you have three possible ways to use /boot on btrfs:
> 
> (1) put /boot on subvolid=0, don't change the default subvolume. That
> works, but all your snapshot/subvols will be visible under /boot. Some
> people might not want that for estetic reason.

Hi Fajar,
I think I am doing just this, but my subvolumes are not visible under /boot. I
have all my subvolumes set up like this:
/path/to/subvolid_0/boot       < a simple directory bind-mounted to /
/path/to/subvolid_0/__active   < my / subvolume
/path/to/subvolid_0/__home     < my /home subvolume


> (3) put /boot on a subvolume, do not change the default subvolume, and
> manage grub.cfg manually. This is what I currently do.

Could you elaborate about this option pls., and if possible post your grub.cfg?
I don't quite understand how it works. Though I am doing syslinux at the moment,
I think the process is the same.

thanks
~dima

Re: Snapshot rollback

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/24/2011 01:45 AM, dima wrote:
> Hello Phillip,
> It is hard to judge without seeing your fstab and bootloader config. Maybe your
> / was directly in subvolid=0 without creating a separate subvolume for it (like
> __active in Goffredo's reply)? In my very humble opinion, if you have your @home
> subvolume under subvolid=0 and then change the default subvolume, it just cannot
> access your @home any more.

Why can't it?

It appears that Ubuntu sets up two subvols, one named @ and one named
@home, and mounts them at / and /home respectively.  The boot loader was
set to pass rootflags=subvol=@.  After changing the default volume, the
system would not boot until I removed that rootflags argument, then it
mounted the snapshot correctly as the root, but refused to mount /home,
giving this nonsense error that /dev/sda1 is not a valid block device.

> Here is a very good article that explains the working of subvolumes. I used it
> as reference a lot.
> http://www.funtoo.org/wiki/BTRFS_Fun#Using_snapshots_for_system_recovery_.28aka_Back_to_the_Future.29

This advice seems completely goofy.  It tells you to change the default
subvol and boot from the snapshot, but then to have rsync copy all of
the files back to the default volume, then switch back to using that.
This seems to defeat the entire purpose.  If you are already booting
from the snapshot, why would you want to waste time copying the files
back to the original subvol instead of just deleting it, and using the
snapshot volume from now on?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6mBo4ACgkQJ4UciIs+XuK+wgCeOD0km3GpdseQ0h4y0FKSI7JS
xC0An2JqA4aOHCkZ7+g+TORunVnpmQj7
=6KKf
-----END PGP SIGNATURE-----

Re: Snapshot rollback

[Fajar A. Nugraha]

On Mon, Oct 24, 2011 at 3:24 PM, dima <dolenin@parallels.com> wrote:
> Fajar A. Nugraha <list <at> fajar.net> writes:
>
>> A problem with that, though, if you decide to put /boot on btrfs as
>> well. Grub uses the default subvolume to determine paths (for kernel,
>> initrd, etc). A workaround is to manually create and manage your
>> grub.cfg (or create and use a manual-managed include file, like
>> custom-top.cfg, that gets parsed before the automatically created
>> entries).
>
> Oops, sorry, I was incorrect of course. Thanks Fajar.
> I do have /boot in my subvolid=0 because bootloaders can't read inside
> subvolumes (other than the default) as far as I understand.
> And I just bind /boot through fstab.

AFAIK you have three possible ways to use /boot on btrfs:

(1) put /boot on subvolid=0, don't change the default subvolume. That
works, but all your snapshot/subvols will be visible under /boot. Some
people might not want that for estetic reason.

(2) put /boot (or /, when /boot is part of / ) on a subvolume, then
change the default subvolume. This works cleanly, but there were some
problems in the past when changing the default subvolume (at least I
had problem). Current kernel version might not have this problem
anymore (I haven't tried again)

(3) put /boot on a subvolume, do not change the default subvolume, and
manage grub.cfg manually. This is what I currently do.

I wish grub's btrfs support is more like zfs support, where both the
bootloader and tools (e.g. update-grub, grub-probe, etc) can
intellegently recognize what dataset /boot is on, and create the
correct entry. For example, if you have this

# df -h /boot
Filesystem            Size  Used Avail Use% Mounted on
rpool/ROOT/ubuntu-1   384G  1.2G  383G   1% /
rpool/ROOT/ubuntu-1/boot
                      383G   71M  383G   1% /boot

... then grub.cfg will have an entry like this

	zfs-bootfs ($root) bootfs
	linux	/ROOT/ubuntu-1/boot/@/vmlinuz-2.6.38-10-generic root=/dev/sda5
ro boot=zfs $bootfs rpool=rpool bootfs=rpool/ROOT/ubuntu-1
	initrd	/ROOT/ubuntu-1/boot/@/initrd.img-2.6.38-10-generic

This flexibility allows me (for example) to have multiple version of
kernel, initrd, and root fs in different datasets, all selectable
during boot process (possibly by manually editing grub command line to
suplly the correct path/argument). Good for rescue purposes, just in
case a recent update made the system broken :)

The closest thing we can get to that with btrfs is currently option
(1), as option (2) requires you to boot to an alternate environment
(e.g live cd) to change the default subvol first.

-- 
Fajar

Re: Snapshot rollback

[dima]

Fajar A. Nugraha <list <at> fajar.net> writes:
 
> A problem with that, though, if you decide to put /boot on btrfs as
> well. Grub uses the default subvolume to determine paths (for kernel,
> initrd, etc). A workaround is to manually create and manage your
> grub.cfg (or create and use a manual-managed include file, like
> custom-top.cfg, that gets parsed before the automatically created
> entries).

Oops, sorry, I was incorrect of course. Thanks Fajar.
I do have /boot in my subvolid=0 because bootloaders can't read inside
subvolumes (other than the default) as far as I understand.
And I just bind /boot through fstab.

Re: Snapshot rollback

[Fajar A. Nugraha]

On Mon, Oct 24, 2011 at 12:45 PM, dima <dolenin@parallels.com> wrote:
> Phillip Susi <psusi <at> cfl.rr.com> writes:
>
>> I created a snapshot of my root subvol, then used btrfs-subvolume
>> set-default to make the snapshot the default subvol and rebooted. =A0=
This
>> seems to have correctly gotten the system to boot from the snapshot
>> instead of the original subvol, but now /home ( @home subvol ) refus=
es
>> to mount claiming that /dev/sda1 is not a valid block device. =A0Wha=
t gives?

Try mounting using sobvolid. Use "btrfs su li /" (or wherever it's
mounted) to list the ids.

> Personally I do not store anything in subvolid=3D0 directly and never=
 bothered
> with 'set-default' option - just used a new subvolume/snapshot name

+1

A problem with that, though, if you decide to put /boot on btrfs as
well. Grub uses the default subvolume to determine paths (for kernel,
initrd, etc). A workaround is to manually create and manage your
grub.cfg (or create and use a manual-managed include file, like
custom-top.cfg, that gets parsed before the automatically created
entries).

I really like zfs grub2 support, where it will correctly use the
dataset name for file locations. Unfortunately grub's btrfs support
doesn't have it (yet).

> - create a named snapshot
> - edit bootloader config to include the new
> rootflags=3Dsubvol=3D<your_new_snapshot_name>

I had some problem with subvol option in old version of kernel/btrfs
in Lucid/Natty. I use subvolid now, which seems to be more reliable.

--=20
=46ajar
--
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: Snapshot rollback

[dima]

Phillip Susi <psusi <at> cfl.rr.com> writes:

> I created a snapshot of my root subvol, then used btrfs-subvolume
> set-default to make the snapshot the default subvol and rebooted.  This
> seems to have correctly gotten the system to boot from the snapshot
> instead of the original subvol, but now /home ( @home subvol ) refuses
> to mount claiming that /dev/sda1 is not a valid block device.  What gives?


Hello Phillip,
It is hard to judge without seeing your fstab and bootloader config. Maybe your
/ was directly in subvolid=0 without creating a separate subvolume for it (like
__active in Goffredo's reply)? In my very humble opinion, if you have your @home
subvolume under subvolid=0 and then change the default subvolume, it just cannot
access your @home any more.

Personally I do not store anything in subvolid=0 directly and never bothered
with 'set-default' option - just used a new subvolume/snapshot name
- create a named snapshot
- edit bootloader config to include the new
rootflags=subvol=<your_new_snapshot_name>
- reboot

Here is a very good article that explains the working of subvolumes. I used it
as reference a lot.
http://www.funtoo.org/wiki/BTRFS_Fun#Using_snapshots_for_system_recovery_.28aka_Back_to_the_Future.29

~dima

Re: Snapshot rollback

[Goffredo Baroncelli]

On Sunday, 23 October, 2011 15:42:50 you wrote:
>  there no way to move or hard link subvolumes to somewhere other
> than their original location?

You can use the 'mv' command.

[__active is the subvolume which I use as root]

ghigo@venice:/tmp$ btrfs sub crea a
Create subvolume './a'
ghigo@venice:/tmp$ btrfs sub crea c
Create subvolume './c'
ghigo@venice:/tmp$ btrfs sub crea a/b
Create subvolume 'a/b'
ghigo@venice:/tmp$ sudo btrfs sub list /var/btrfs/
ID 258 top level 5 path __active
ID 259 top level 5 path __active/tmp/a
ID 260 top level 5 path __active/tmp/c
ID 261 top level 5 path __active/tmp/a/b
ghigo@venice:/tmp$ mv a/b c
ghigo@venice:/tmp$ sudo btrfs sub list /var/btrfs/
ID 258 top level 5 path __active
ID 259 top level 5 path __active/tmp/a
ID 260 top level 5 path __active/tmp/c
ID 261 top level 5 path __active/tmp/c/b

-- 
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512

Snapshot rollback

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I created a snapshot of my root subvol, then used btrfs-subvolume
set-default to make the snapshot the default subvol and rebooted.  This
seems to have correctly gotten the system to boot from the snapshot
instead of the original subvol, but now /home ( @home subvol ) refuses
to mount claiming that /dev/sda1 is not a valid block device.  What gives?

Also, is there no way to move or hard link subvolumes to somewhere other
than their original location?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6kbjoACgkQJ4UciIs+XuJ9cgCgplNTWEmJjW+9fC87y9nO9yao
xcQAoLzsOCVgxsm4a28wKudvyX+7OCpB
=rL1g
-----END PGP SIGNATURE-----