WG: How to properly setup for snapshots

WG: How to properly setup for snapshots

[Claudius Ellsel]

Next try (this time text only activated) after my second try was treated as spam (this time I at least got a delivery failed message stating so).

The original message does not seem to have made it through, so here I try again.

Von: Claudius Ellsel <claudius.ellsel@live.de>
Gesendet: Donnerstag, 10. Dezember 2020 15:37
An: linux-btrfs@vger.kernel.org <linux-btrfs@vger.kernel.org>
Betreff: How to properly setup for snapshots 
 
Hello,

I recently started setting up btrfs on Ubuntu 20.04 LTS for usage as an SMB share mainly. Currently I am at the stage that I have two disks set up with RAID1 and automatically mounting them on boot with a fstab entry. Also I have setup samba and have transferred data on it.

Now I wanted to create snapshots, but am not sure how exactly that works. The wiki does not say much and information on the internet is not really reliable.

The problem might be that I currently don't have any subvolumes set up at all. Am I still be able to create snapshots in this stage or do I have to create a subvolume first from which snapshots can be created afterwards?

Also I learned about snapper from SUSE which sounds nice, but I don't want to break things while trying to use it.

Unfortunately I am already at a somewhat production stage where I don't want to lose any data.

Hopefully somebody can shed some light on this, maybe we can also add info to the wiki so there is a somewhat "official" source to rely on.

PS: I am not subscribed to this list, hopefully replies will reach me anyway.

Kind regards
Claudius Ellsel

Re: WG: How to properly setup for snapshots

[Remi Gauvin]

On 2020-12-21 11:11 a.m., Claudius Ellsel wrote:

> Unfortunately I am already at a somewhat production stage where I
don't want to lose any data.
>

You should first and foremost make sure you have backups of everything.

> 
> The problem might be that I currently don't have any subvolumes set up at all. Am I still be able to create snapshots in this stage or do I have to create a subvolume first from which snapshots can be created afterwards?
> 

You have 1 subvolume, which is the root of your filesystem.  You can
make snapshots of it.. (and each snapshot will be a new subvolume)  To
make your life easier, as you start experimenting, I suggest making a
new Read/Write subvolume to put your snapshots into

btrfs subvolume create .my_snapshots
btrfs subvolume snapshot -r /mnt_point /mnt_point/.my_snapshots/snapshot1

(Note: You will not be able to move or rename the snapshot1
folder, but you *will* be able to move or rename the entire
.my_snapshots subvolume



> Also I learned about snapper from SUSE which sounds nice, but I don't want to break things while trying to use it.
> 

Snapper is an amazing tool... You should familiarize yourself and be
comfortable with the btrfs subvolume command first, (things will make
more sense if you know whats going on...), but Snapper makes it a.. snap
to automate the snapshots *and* the clean-up.

Re: WG: How to properly setup for snapshots

[Roman Mamedov]

On Mon, 21 Dec 2020 12:05:37 -0500
Remi Gauvin <remi@georgianit.com> wrote:

> I suggest making a new Read/Write subvolume to put your snapshots into
> 
> btrfs subvolume create .my_snapshots
> btrfs subvolume snapshot -r /mnt_point /mnt_point/.my_snapshots/snapshot1

It sounds like this could plant a misconception right from the get go.

You don't really put snapshot* "into" a subvolume. Subvolumes do not actually
contain other subvolumes, since making a snapshot of the "parent" won't
include any content of the subvolumes with pathnames below it.

As such there's no benefit in storing snapshots "inside" a subvolume. There's
not much of the "inside". Might as well just create a regular directory for
that -- and with less potential for confusion.

* - keep in mind that "snapshot" and "subvolume" mean the same thing in Btrfs,
    the only difference being that "snapshot"-subvolume started its life as
    being a full copy(-on-write) of some other subvolume.

-- 
With respect,
Roman

Re: WG: How to properly setup for snapshots

[Remi Gauvin]

On 2020-12-21 12:37 p.m., Roman Mamedov wrote:

> 
> As such there's no benefit in storing snapshots "inside" a subvolume. There's
> not much of the "inside". Might as well just create a regular directory for
> that -- and with less potential for confusion.

Maybe I was complicating things for a baby step primer,, but there *are*
very good benefits to putting snapshots in a subvolume.  That subvolume
can be moved into other subvolumes,  A directory that contains ro
snapshots can not.

This will not matter if your only subvolume is the filesystem root, but
if things were later be subdivided into other subvolumes, it will make
things much quicker and easier to be able to move the .my_snapshots
subvolume.

Re: WG: How to properly setup for snapshots

[Goffredo Baroncelli]

On 12/21/20 7:14 PM, Remi Gauvin wrote:
> On 2020-12-21 12:37 p.m., Roman Mamedov wrote:
> 
>>
>> As such there's no benefit in storing snapshots "inside" a subvolume. There's
>> not much of the "inside". Might as well just create a regular directory for
>> that -- and with less potential for confusion.
> 
> Maybe I was complicating things for a baby step primer,, but there *are*
> very good benefits to putting snapshots in a subvolume.  That subvolume
> can be moved into other subvolumes,  A directory that contains ro
> snapshots can not.

A subvolume can be moved everywhere with a simple 'mv' command.

$ btrfs sub crea sub1
Create subvolume './sub1'
$ btrfs sub crea sub2
Create subvolume './sub2'
$ btrfs sub crea sub1/sub11
Create subvolume 'sub1/sub11'
$ btrfs sub crea sub1/sub12
Create subvolume 'sub1/sub12'
$ mv sub1 sub2/
$ find sub2/
sub2/
sub2/sub1
sub2/sub1/sub12
sub2/sub1/sub11

> 
> This will not matter if your only subvolume is the filesystem root, but
> if things were later be subdivided into other subvolumes, it will make
> things much quicker and easier to be able to move the .my_snapshots
> subvolume.
> 
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: WG: How to properly setup for snapshots

[Remi Gauvin]

On 2020-12-21 3:14 p.m., Goffredo Baroncelli wrote:

> A subvolume can be moved everywhere with a simple 'mv' command.
>

No, they can not,, try this again with a *read only* snapshot

Re: WG: How to properly setup for snapshots

[Goffredo Baroncelli]

On 12/21/20 9:27 PM, Remi Gauvin wrote:
> On 2020-12-21 3:14 p.m., Goffredo Baroncelli wrote:
> 
>> A subvolume can be moved everywhere with a simple 'mv' command.
>>
> 
> No, they can not,, try this again with a *read only* snapshot
>

The topic was about why put the subvolumes/snapshots in another subvolume.

A readonly snapshot can't be moved from its parent (doesn't matter if it is a diretory or a subvolume). This is true. But the subvolume containing a readonly snapshot can be moved :

$ btrfs sub crea sub1
Create subvolume './sub1'
$ btrfs sub crea sub2
Create subvolume './sub2'
$ mkdir dir1
$ btrfs sub snap -r sub2 sub1/snap2
Create a readonly snapshot of 'sub2' in 'sub1/snap2'
$ btrfs sub snap -r sub2 dir1/snap2
Create a readonly snapshot of 'sub2' in 'dir1/snap2'
$ mv sub1 sub1-renamed
$ mv dir1 dir1-renamed



-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: WG: How to properly setup for snapshots

[Andrei Borzenkov]

21.12.2020 20:37, Roman Mamedov пишет:
> On Mon, 21 Dec 2020 12:05:37 -0500
> Remi Gauvin <remi@georgianit.com> wrote:
> 
>> I suggest making a new Read/Write subvolume to put your snapshots into
>>
>> btrfs subvolume create .my_snapshots
>> btrfs subvolume snapshot -r /mnt_point /mnt_point/.my_snapshots/snapshot1
> 
> It sounds like this could plant a misconception right from the get go.
> 
> You don't really put snapshot* "into" a subvolume. Subvolumes do not actually
> contain other subvolumes, since making a snapshot of the "parent" won't
> include any content of the subvolumes with pathnames below it.
> 
> As such there's no benefit in storing snapshots "inside" a subvolume. There's

Having dedicated subvolume containing snapshots makes it easy to switch
your root between subvolumes (either for roll back or transactional
updates or whatever) and retain access to snapshots by simply mounting
containing subvolume. Having them in subdirectory of your (root)
subvolume means you can no more remove this subvolume without also
destroying snapshots before, so you are stuck with it.

So it makes all sort of sense to think in advance and prepare dedicated
subvolume for this purpose.

> not much of the "inside". Might as well just create a regular directory for
> that -- and with less potential for confusion.
> 
> * - keep in mind that "snapshot" and "subvolume" mean the same thing in Btrfs,
>     the only difference being that "snapshot"-subvolume started its life as
>     being a full copy(-on-write) of some other subvolume.
> 

AW: WG: How to properly setup for snapshots

[Claudius Ellsel]

I was aware that snapshots are basically subvolumes. Currently I am looking for an easy way to achieve what I want. I currently just want to be able to create manual snapshots and an easy way to restore stuff on file level. For that (including the management of snapshots), snapper seems to be the best way, as btrfs does not offer such features (in an easy way) out of the box afaict.

Unfortunately the documentation for snapper is also not nice, I just had a closer look again. The best I could find was the Arch wiki but that also starts right away with how to create a config (without telling whether that is even needed for basic usage).

Ultimately I'd like to have a btrfs Wiki entry for snapshots and am willing to help with it.

Von: Andrei Borzenkov <arvidjaar@gmail.com>
Gesendet: Montag, 21. Dezember 2020 19:26
An: Roman Mamedov <rm@romanrm.net>; Remi Gauvin <remi@georgianit.com>
Cc: Claudius Ellsel <claudius.ellsel@live.de>; linux-btrfs <linux-btrfs@vger.kernel.org>
Betreff: Re: WG: How to properly setup for snapshots 
 
21.12.2020 20:37, Roman Mamedov пишет:
> On Mon, 21 Dec 2020 12:05:37 -0500
> Remi Gauvin <remi@georgianit.com> wrote:
> 
>> I suggest making a new Read/Write subvolume to put your snapshots into
>>
>> btrfs subvolume create .my_snapshots
>> btrfs subvolume snapshot -r /mnt_point /mnt_point/.my_snapshots/snapshot1
> 
> It sounds like this could plant a misconception right from the get go.
> 
> You don't really put snapshot* "into" a subvolume. Subvolumes do not actually
> contain other subvolumes, since making a snapshot of the "parent" won't
> include any content of the subvolumes with pathnames below it.
> 
> As such there's no benefit in storing snapshots "inside" a subvolume. There's

Having dedicated subvolume containing snapshots makes it easy to switch
your root between subvolumes (either for roll back or transactional
updates or whatever) and retain access to snapshots by simply mounting
containing subvolume. Having them in subdirectory of your (root)
subvolume means you can no more remove this subvolume without also
destroying snapshots before, so you are stuck with it.

So it makes all sort of sense to think in advance and prepare dedicated
subvolume for this purpose.

> not much of the "inside". Might as well just create a regular directory for
> that -- and with less potential for confusion.
> 
> * - keep in mind that "snapshot" and "subvolume" mean the same thing in Btrfs,
>     the only difference being that "snapshot"-subvolume started its life as
>     being a full copy(-on-write) of some other subvolume.
> 

Re: AW: WG: How to properly setup for snapshots

[Andrei Borzenkov]

21.12.2020 21:35, Claudius Ellsel пишет:
> I was aware that snapshots are basically subvolumes. Currently I am looking for an easy way to achieve what I want. I currently just want to be able to create manual snapshots

btrfs subvolume snapshot / /snapshot

> and an easy way to restore stuff on file level.

cp /snapshot/sub/dir/file /sub/dir/file

> For that (including the management of snapshots), snapper seems to be the best way, as btrfs does not offer such features (in an easy way) out of the box afaict.

Yes, btrfs does not reimplement cron in kernel space.

> 
> Unfortunately the documentation for snapper is also not nice, I just had a closer look again. The best I could find was the Arch wiki but that also starts right away with how to create a config (without telling whether that is even needed for basic usage).
> 
> Ultimately I'd like to have a btrfs Wiki entry for snapshots and am willing to help with it.
> 
> Von: Andrei Borzenkov <arvidjaar@gmail.com>
> Gesendet: Montag, 21. Dezember 2020 19:26
> An: Roman Mamedov <rm@romanrm.net>; Remi Gauvin <remi@georgianit.com>
> Cc: Claudius Ellsel <claudius.ellsel@live.de>; linux-btrfs <linux-btrfs@vger.kernel.org>
> Betreff: Re: WG: How to properly setup for snapshots 
>  
> 21.12.2020 20:37, Roman Mamedov пишет:
>> On Mon, 21 Dec 2020 12:05:37 -0500
>> Remi Gauvin <remi@georgianit.com> wrote:
>>
>>> I suggest making a new Read/Write subvolume to put your snapshots into
>>>
>>> btrfs subvolume create .my_snapshots
>>> btrfs subvolume snapshot -r /mnt_point /mnt_point/.my_snapshots/snapshot1
>>
>> It sounds like this could plant a misconception right from the get go.
>>
>> You don't really put snapshot* "into" a subvolume. Subvolumes do not actually
>> contain other subvolumes, since making a snapshot of the "parent" won't
>> include any content of the subvolumes with pathnames below it.
>>
>> As such there's no benefit in storing snapshots "inside" a subvolume. There's
> 
> Having dedicated subvolume containing snapshots makes it easy to switch
> your root between subvolumes (either for roll back or transactional
> updates or whatever) and retain access to snapshots by simply mounting
> containing subvolume. Having them in subdirectory of your (root)
> subvolume means you can no more remove this subvolume without also
> destroying snapshots before, so you are stuck with it.
> 
> So it makes all sort of sense to think in advance and prepare dedicated
> subvolume for this purpose.
> 
>> not much of the "inside". Might as well just create a regular directory for
>> that -- and with less potential for confusion.
>>
>> * - keep in mind that "snapshot" and "subvolume" mean the same thing in Btrfs,
>>      the only difference being that "snapshot"-subvolume started its life as
>>      being a full copy(-on-write) of some other subvolume.
>>

AW: AW: WG: How to properly setup for snapshots

[Claudius Ellsel]

I seem to have forgotten to choose "reply all" for this one. So for the sake of completeness my reply again (I now know that there are read-only snapshots):

That command will create a snapshot subvolume and just mount it at the specified directory, correct? I am not such a big fan of this, as the snapshot would then be exposed at file level and I can probably accidentially delete (or modify) those files on the snapshot subvolume making it not a snapshot of a certain point in time anymore?

With management of snapshots I did not mean cron (automating stuff), but having an easy and error prone interface for creating and interacting with already created snapshots (like deleting old ones or comparing things).

Von: Andrei Borzenkov <arvidjaar@gmail.com>
Gesendet: Montag, 21. Dezember 2020 19:40
An: Claudius Ellsel <claudius.ellsel@live.de>; Roman Mamedov <rm@romanrm.net>; Remi Gauvin <remi@georgianit.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Betreff: Re: AW: WG: How to properly setup for snapshots 
 
21.12.2020 21:35, Claudius Ellsel пишет:
> I was aware that snapshots are basically subvolumes. Currently I am looking for an easy way to achieve what I want. I currently just want to be able to create manual snapshots

btrfs subvolume snapshot / /snapshot

> and an easy way to restore stuff on file level.

cp /snapshot/sub/dir/file /sub/dir/file

> For that (including the management of snapshots), snapper seems to be the best way, as btrfs does not offer such features (in an easy way) out of the box afaict.

Yes, btrfs does not reimplement cron in kernel space.

> 
> Unfortunately the documentation for snapper is also not nice, I just had a closer look again. The best I could find was the Arch wiki but that also starts right away with how to create a config (without telling whether that is even needed for basic usage).
> 
> Ultimately I'd like to have a btrfs Wiki entry for snapshots and am willing to help with it.
> 
> Von: Andrei Borzenkov <arvidjaar@gmail.com>
> Gesendet: Montag, 21. Dezember 2020 19:26
> An: Roman Mamedov <rm@romanrm.net>; Remi Gauvin <remi@georgianit.com>
> Cc: Claudius Ellsel <claudius.ellsel@live.de>; linux-btrfs <linux-btrfs@vger.kernel.org>
> Betreff: Re: WG: How to properly setup for snapshots 
>  
> 21.12.2020 20:37, Roman Mamedov пишет:
>> On Mon, 21 Dec 2020 12:05:37 -0500
>> Remi Gauvin <remi@georgianit.com> wrote:
>>
>>> I suggest making a new Read/Write subvolume to put your snapshots into
>>>
>>> btrfs subvolume create .my_snapshots
>>> btrfs subvolume snapshot -r /mnt_point /mnt_point/.my_snapshots/snapshot1
>>
>> It sounds like this could plant a misconception right from the get go.
>>
>> You don't really put snapshot* "into" a subvolume. Subvolumes do not actually
>> contain other subvolumes, since making a snapshot of the "parent" won't
>> include any content of the subvolumes with pathnames below it.
>>
>> As such there's no benefit in storing snapshots "inside" a subvolume. There's
> 
> Having dedicated subvolume containing snapshots makes it easy to switch
> your root between subvolumes (either for roll back or transactional
> updates or whatever) and retain access to snapshots by simply mounting
> containing subvolume. Having them in subdirectory of your (root)
> subvolume means you can no more remove this subvolume without also
> destroying snapshots before, so you are stuck with it.
> 
> So it makes all sort of sense to think in advance and prepare dedicated
> subvolume for this purpose.
> 
>> not much of the "inside". Might as well just create a regular directory for
>> that -- and with less potential for confusion.
>>
>> * - keep in mind that "snapshot" and "subvolume" mean the same thing in Btrfs,
>>      the only difference being that "snapshot"-subvolume started its life as
>>      being a full copy(-on-write) of some other subvolume.
>>

Re: How to properly setup for snapshots

[Ulli Horlacher]

On Mon 2020-12-21 (20:51), Claudius Ellsel wrote:

> With management of snapshots I did not mean cron (automating stuff), but
> having an easy and error prone interface for creating and interacting
> with already created snapshots (like deleting old ones or comparing
> things).

http://fex.belwue.de/snaprotate.html

-- 
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:<AM9P191MB1650A8C71F588CC759C7FAB6E2C00@AM9P191MB1650.EURP191.PROD.OUTLOOK.COM>

Re: WG: How to properly setup for snapshots

[Goffredo Baroncelli]

On 12/21/20 7:26 PM, Andrei Borzenkov wrote:
> 21.12.2020 20:37, Roman Mamedov пишет:
[...]
> Having dedicated subvolume containing snapshots makes it easy to switch
> your root between subvolumes (either for roll back or transactional
> updates or whatever) and retain access to snapshots by simply mounting
> containing subvolume. Having them in subdirectory of your (root)
> subvolume means you can no more remove this subvolume without also
> destroying snapshots before, so you are stuck with it.
> 
> So it makes all sort of sense to think in advance and prepare dedicated
> subvolume for this purpose.

There is an asymmetry of the '/' subvolume; it can't be deleted, so it is not easy and cheap to swap it with its snapshot.

In my setup, I uses the '/' subvolume as container of all the other subvolumes, one of these is the root of my filesystem. Then each subvolume is mounted where it is needed:

$ findmnt  | egrep sdg3
/                                     /dev/sdg3[/@rootfs]       btrfs       rw,noatime,nodiratime,nossd,space_cache,subvolid=448,subvol=/@rootfs
├─/boot                               /dev/sdg3[/@boot]         btrfs       rw,noatime,nodiratime,nossd,space_cache,subvolid=258,subvol=/@boot
├─/var/btrfs                          /dev/sdg3                 btrfs       rw,noatime,nodiratime,nossd,space_cache,subvolid=5,subvol=/
├─/var/lib/machines/vm-sqlserver      /dev/sdg3[/@vm-sqlserver] btrfs       rw,noatime,nodiratime,nossd,space_cache,subvolid=454,subvol=/@vm-sqlserver
├─/var/lib/portables                  /dev/sdg3[/@portables]    btrfs       rw,noatime,nodiratime,nossd,space_cache,subvolid=282,subvol=/@portables
├─/var/log                            /dev/sdg3[/@log]          btrfs       rw,noatime,nodiratime,nossd,space_cache,subvolid=447,subvol=/@log

I mount the '/' subvolume under /var/btrfs, where i manage the subvolume. With this setup is easy to snapshot the root filesystem (/dev/sdg3[/@rootfs]) and mount the snapshot instead the old root. The other part of the filesystem which are better to not involve in the snapshot-rollback process (like /boot, /var/log...) are in a separate subvolumes which are mounted at boot time using /etc/fstab

I tough quite often that mkfs.btrfs should allow to create a "default" subvolume inside the '/'. It would simplify the management of the root filesystem in case if the user want to srollback the system to a previous snapshot.

BR

> 
>> not much of the "inside". Might as well just create a regular directory for
>> that -- and with less potential for confusion.
>>
>> * - keep in mind that "snapshot" and "subvolume" mean the same thing in Btrfs,
>>      the only difference being that "snapshot"-subvolume started its life as
>>      being a full copy(-on-write) of some other subvolume.
>>
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

AW: WG: How to properly setup for snapshots

[Claudius Ellsel]

I have backups of the important data, but not for all data on that volume. Thus I wanted to make clear that I don't just want to copy paste stuff I find on the internet and motivate why I am asking here and want to have reliable sources. But thanks for the hint anyway, I also plan to have a better backup strategy once this project is finished. Unfortunately I don't have a better one right now where this is in an intermediate state.

> You have 1 subvolume, which is the root of your filesystem.

I still doubt that a bit, `sudo btrfs subvolume list /media/clel/NAS` (which is where I mount the volume with an fstab entry based on the UUID) does not output anything. Additionally I read (I guess on a reddit post) that in this case one has to create a subvolume first. That might have been problematic information, though.

I don't like experimenting and thus try to get the relevant information first. Also I want to state again that I hope, we can improve the Wiki to contain the information, so there is somewhat "official" documentation for this.

I'll probably read some more about snapper, although what I have read so far did not seem that well documented for first time users (for example I still don't know whether it will "just work" or needs some prerequisites).

Von: Remi Gauvin <remi@georgianit.com>
Gesendet: Montag, 21. Dezember 2020 18:05
An: Claudius Ellsel <claudius.ellsel@live.de>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Betreff: Re: WG: How to properly setup for snapshots 
 
On 2020-12-21 11:11 a.m., Claudius Ellsel wrote:

> Unfortunately I am already at a somewhat production stage where I
don't want to lose any data.
>

You should first and foremost make sure you have backups of everything.

> 
> The problem might be that I currently don't have any subvolumes set up at all. Am I still be able to create snapshots in this stage or do I have to create a subvolume first from which snapshots can be created afterwards?
> 

You have 1 subvolume, which is the root of your filesystem.  You can
make snapshots of it.. (and each snapshot will be a new subvolume)  To
make your life easier, as you start experimenting, I suggest making a
new Read/Write subvolume to put your snapshots into

btrfs subvolume create .my_snapshots
btrfs subvolume snapshot -r /mnt_point /mnt_point/.my_snapshots/snapshot1

(Note: You will not be able to move or rename the snapshot1
folder, but you *will* be able to move or rename the entire
my_snapshots subvolume



> Also I learned about snapper from SUSE which sounds nice, but I don't want to break things while trying to use it.
> 

Snapper is an amazing tool... You should familiarize yourself and be
comfortable with the btrfs subvolume command first, (things will make
more sense if you know whats going on...), but Snapper makes it a.. snap
to automate the snapshots *and* the clean-up.

Re: AW: WG: How to properly setup for snapshots

[Remi Gauvin]

On 2020-12-21 1:04 p.m., Claudius Ellsel wrote:

> 
> I still doubt that a bit, `sudo btrfs subvolume list /media/clel/NAS` (which is where I mount the volume with an fstab entry based on the UUID) does not output anything. Additionally I read (I guess on a reddit post) that in this case one has to create a subvolume first. That might have been problematic information, though.
> 
>

Ok, you got me there.  Technically, the file system root is not a
*Sub*volume, because it's not *sub* to anything... but you can still
make snapshots of it, just as I described.

AW: AW: WG: How to properly setup for snapshots

[Claudius Ellsel]

Nice, thanks for clarifying it, that is a first step towards clearing up my confusion 🙂

Von: Remi Gauvin <remi@georgianit.com>
Gesendet: Montag, 21. Dezember 2020 19:32
An: Claudius Ellsel <claudius.ellsel@live.de>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Betreff: Re: AW: WG: How to properly setup for snapshots 
 
On 2020-12-21 1:04 p.m., Claudius Ellsel wrote:

> 
> I still doubt that a bit, `sudo btrfs subvolume list /media/clel/NAS` (which is where I mount the volume with an fstab entry based on the UUID) does not output anything. Additionally I read (I guess on a reddit post) that in this case one has to create a subvolume first. That might have been problematic information, though.
> 
>

Ok, you got me there.  Technically, the file system root is not a
*Sub*volume, because it's not *sub* to anything... but you can still
make snapshots of it, just as I described.

AW: WG: How to properly setup for snapshots

[Claudius Ellsel]

I had a closer look at snapper now and have installed and set it up. This seems to be really the easiest way for me, I guess. My main confusion was probably that I was unsure whether I had to create a subvolume prior to this or not, which got sorted out now. The situation is apparently still not ideal, as to my current understanding it would have been preferable to set up a subvolume first at root level directly after creating the files system. However, as this is only the data drive in the machine (OS runs on an ext4 SSD) it is at least not planned to simply swap the entire volume to a snapshot but rather to restore snapshots at file / folder level, where snapper can also be used for.

One can possibly also safely achieve the same with only using btrfs commandline tools (I made the mistake of not thinking about read only snapshots when I wrote about my fear to delete / modify mounted snapshots). Still I have a better feeling when using snapper, as I hope it is less easy to screw things up with it :)

Thanks all for your input and help!

Let me know if somebody want to improve the Wiki together to make entry easier for beginners.

Von: Claudius Ellsel <claudius.ellsel@live.de>
Gesendet: Montag, 21. Dezember 2020 19:04
An: Remi Gauvin <remi@georgianit.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Betreff: AW: WG: How to properly setup for snapshots 
 
I have backups of the important data, but not for all data on that volume. Thus I wanted to make clear that I don't just want to copy paste stuff I find on the internet and motivate why I am asking here and want to have reliable sources. But thanks for the hint anyway, I also plan to have a better backup strategy once this project is finished. Unfortunately I don't have a better one right now where this is in an intermediate state.

> You have 1 subvolume, which is the root of your filesystem.

I still doubt that a bit, `sudo btrfs subvolume list /media/clel/NAS` (which is where I mount the volume with an fstab entry based on the UUID) does not output anything. Additionally I read (I guess on a reddit post) that in this case one has to create a subvolume first. That might have been problematic information, though.

I don't like experimenting and thus try to get the relevant information first. Also I want to state again that I hope, we can improve the Wiki to contain the information, so there is somewhat "official" documentation for this.

I'll probably read some more about snapper, although what I have read so far did not seem that well documented for first time users (for example I still don't know whether it will "just work" or needs some prerequisites).

Von: Remi Gauvin <remi@georgianit.com>
Gesendet: Montag, 21. Dezember 2020 18:05
An: Claudius Ellsel <claudius.ellsel@live.de>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Betreff: Re: WG: How to properly setup for snapshots 
 
On 2020-12-21 11:11 a.m., Claudius Ellsel wrote:

> Unfortunately I am already at a somewhat production stage where I
don't want to lose any data.
>

You should first and foremost make sure you have backups of everything.

> 
> The problem might be that I currently don't have any subvolumes set up at all. Am I still be able to create snapshots in this stage or do I have to create a subvolume first from which snapshots can be created afterwards?
> 

You have 1 subvolume, which is the root of your filesystem.  You can
make snapshots of it.. (and each snapshot will be a new subvolume)  To
make your life easier, as you start experimenting, I suggest making a
new Read/Write subvolume to put your snapshots into

btrfs subvolume create .my_snapshots
btrfs subvolume snapshot -r /mnt_point /mnt_point/.my_snapshots/snapshot1

(Note: You will not be able to move or rename the snapshot1
folder, but you *will* be able to move or rename the entire
my_snapshots subvolume



> Also I learned about snapper from SUSE which sounds nice, but I don't want to break things while trying to use it.
> 

Snapper is an amazing tool... You should familiarize yourself and be
comfortable with the btrfs subvolume command first, (things will make
more sense if you know whats going on...), but Snapper makes it a.. snap
to automate the snapshots *and* the clean-up.

Re: AW: WG: How to properly setup for snapshots

[Graham Cobb]

On 21/12/2020 20:45, Claudius Ellsel wrote:
> I had a closer look at snapper now and have installed and set it up. This seems to be really the easiest way for me, I guess. My main confusion was probably that I was unsure whether I had to create a subvolume prior to this or not, which got sorted out now. The situation is apparently still not ideal, as to my current understanding it would have been preferable to set up a subvolume first at root level directly after creating the files system. However, as this is only the data drive in the machine (OS runs on an ext4 SSD) it is at least not planned to simply swap the entire volume to a snapshot but rather to restore snapshots at file / folder level, where snapper can also be used for.
> 
> One can possibly also safely achieve the same with only using btrfs commandline tools (I made the mistake of not thinking about read only snapshots when I wrote about my fear to delete / modify mounted snapshots). Still I have a better feeling when using snapper, as I hope it is less easy to screw things up with it :)

I have never used snapper but I know it is a popular tool. But there are
many other tools - with their own advantages, disadvantages and ways of
working. You may want to experiment with several of them. Personally I
use btrbk for automation of snapshots.

Just remember that btrfs snapshots are not a backup tool. At best, they
are a convenience tool, for quickly restoring deleted or modified files
(or full subvolumes) to an earlier (snapshotted) state without having to
access your backups. But they are completely useless if a hardware or
software problem (kernel bug, disk problem, system memory error, faulty
cable, etc) corrupts the filesystem. You don't have a backup solution
unless you are copying the files to another physical disk, preferably on
a different system. btrbk can help with that as well (but it is just
automating btrfs send and btrfs receive underneath).

AW: AW: WG: How to properly setup for snapshots

[Claudius Ellsel]

True, ideally I'd have done proper research first (I usually do that, else I wouldn't be using btrfs probably).

I just had a short look. Currently snapper luckily fulfills my needs.

Currently I have RAID1 set up via btrfs (not a good backup, or depending of the definition of "backup" not a backup at all - I still think one cannot deny that it reduces the risk of data loss). On top of that I have important data on an external drive that I plan to sync to manually regularly (this might be where btrbk might come in useful, as it is probably able to retain all the snapshots (history) on the backup drive instead of just overwriting the data when syncing. Currently I don't have the time to thoroughly look into it, though). Also I plan to use rclone to sync with a cloud service. I also think that depending of the definition of "backup", snapshots can be seen as one. But again of course not a safe one.

It all comes down to lowering the risk of data loss in the end. And finding a solution that is an acceptable balance between cost (or effort) and risk.

Von: Graham Cobb <g.btrfs@cobb.uk.net>
Gesendet: Dienstag, 22. Dezember 2020 00:33
An: Claudius Ellsel <claudius.ellsel@live.de>; Remi Gauvin <remi@georgianit.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Betreff: Re: AW: WG: How to properly setup for snapshots 
 
On 21/12/2020 20:45, Claudius Ellsel wrote:
> I had a closer look at snapper now and have installed and set it up. This seems to be really the easiest way for me, I guess. My main confusion was probably that I was unsure whether I had to create a subvolume prior to this or not, which got sorted out now. The situation is apparently still not ideal, as to my current understanding it would have been preferable to set up a subvolume first at root level directly after creating the files system. However, as this is only the data drive in the machine (OS runs on an ext4 SSD) it is at least not planned to simply swap the entire volume to a snapshot but rather to restore snapshots at file / folder level, where snapper can also be used for.
> 
> One can possibly also safely achieve the same with only using btrfs commandline tools (I made the mistake of not thinking about read only snapshots when I wrote about my fear to delete / modify mounted snapshots). Still I have a better feeling when using snapper, as I hope it is less easy to screw things up with it :)

I have never used snapper but I know it is a popular tool. But there are
many other tools - with their own advantages, disadvantages and ways of
working. You may want to experiment with several of them. Personally I
use btrbk for automation of snapshots.

Just remember that btrfs snapshots are not a backup tool. At best, they
are a convenience tool, for quickly restoring deleted or modified files
(or full subvolumes) to an earlier (snapshotted) state without having to
access your backups. But they are completely useless if a hardware or
software problem (kernel bug, disk problem, system memory error, faulty
cable, etc) corrupts the filesystem. You don't have a backup solution
unless you are copying the files to another physical disk, preferably on
a different system. btrbk can help with that as well (but it is just
automating btrfs send and btrfs receive underneath).