btrfs root - why so many subvolumes?

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

btrfs root - why so many subvolumes?

Michael Hamilton
I was looking to make an exact copy of a tumbleweed root btrfs filesystem
on removable media.  One aspect that makes this more fiddly is the number
of subvolumes that are part of the root filesystem, including /opt and many
sub-directories of /var.  

Is there any technical document describing the reasons behind having so
many subvolumes?  Someone else was asking the same question at
stackexchange  (with no real answers) :

http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensuse-fstab-contain-so-many-btrfs-subvol-entries

Is there a recommended way to get a faithful offline bootable backup of a
btrfs  rootfs?

Finally, I'm not determined to use btrfs. I'm moving up from 13.1.  I'm evaluating
Leap and Tumbleweed.  It's a simple desktop, no RAID, one user.  Would
ext4 be a better choice?  

Regards,
Michael
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Vojtěch Zeisek-2
Dne pondělí 17. října 2016 21:49:19 CEST, Michael Hamilton napsal(a):
> I was looking to make an exact copy of a tumbleweed root btrfs filesystem
> on removable media.  One aspect that makes this more fiddly is the number
> of subvolumes that are part of the root filesystem, including /opt and many
> sub-directories of /var.

Really? E.g. /var/lib/mariadb is better to handle with tools like
automysqlbackup anyway. I see it OK.

> Is there any technical document describing the reasons behind having so
> many subvolumes?  Someone else was asking the same question at
> stackexchange  (with no real answers) :

Is this enough? https://www.suse.com/documentation/sles-12/stor_admin/data/
sec_filesystems_major.html

> http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu
> se-fstab-contain-so-many-btrfs-subvol-entries
>
> Is there a recommended way to get a faithful offline bootable backup of a
> btrfs  rootfs?

I don't know if recommended, but dd?

> Finally, I'm not determined to use btrfs. I'm moving up from 13.1.  I'm
> evaluating Leap and Tumbleweed.  It's a simple desktop, no RAID, one user.
> Would ext4 be a better choice?

Then I'd keep Btrfs anyway - its possibility of snapshots, i.e. possibility to
roll back to previous version from many failures (power outage in the middle
of big upgrade etc.) is really great. The subvolumes typically exclude quickly
changing temporary, DB, cache, ... directories from snapshots to save space
and the disk.

--
Vojtěch Zeisek

Komunita openSUSE GNU/Linuxu
Community of the openSUSE GNU/Linux

https://www.opensuse.org/
https://trapa.cz/

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Bruno Friedmann-2
In reply to this post by Michael Hamilton
On lundi, 17 octobre 2016 21.49:19 h CEST Michael Hamilton wrote:

> I was looking to make an exact copy of a tumbleweed root btrfs filesystem
> on removable media.  One aspect that makes this more fiddly is the number
> of subvolumes that are part of the root filesystem, including /opt and many
> sub-directories of /var.
>
> Is there any technical document describing the reasons behind having so
> many subvolumes?  Someone else was asking the same question at
> stackexchange  (with no real answers) :
>
> http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu
> se-fstab-contain-so-many-btrfs-subvol-entries
>
> Is there a recommended way to get a faithful offline bootable backup of a
> btrfs  rootfs?
>
> Finally, I'm not determined to use btrfs. I'm moving up from 13.1.  I'm
> evaluating Leap and Tumbleweed.  It's a simple desktop, no RAID, one user.
> Would ext4 be a better choice?
>
> Regards,
> Michael

From my experience, I'm a btrfs breaker guy (The why has still to be
determined :-) ).
So for my own laptop, I using the traditionnal luks encrypted vg/lvm +
lvm with ext4, this as been rock solid for my own usage, even when I trash the
power outlet.
But there's a downside, I'm not using snapper/ext4) and then loose the ability
to use a rollback snapshot. I have to be careful when doing update with TW.

;-)

The main reason of having that much subvolume from some clues I got from
internet is for example, that there's no way to have checksum (interesting for
database for example) without cow (copy on write, which is not interesting for
database). The nocow flag disable also checksumming.
(beware those informations can be outdated since I've test them 6-8 months
ago)
Also subvol are related also to quota.

--

Bruno Friedmann
 Ioda-Net Sàrl www.ioda-net.ch
 Bareos Partner, openSUSE Member, fsfe fellowship
 GPG KEY : D5C9B751C4653227
 irc: tigerfoot


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Oliver Kurz-2
In reply to this post by Michael Hamilton
On Monday 17 October 2016 21:49:19 Michael Hamilton wrote:

> I was looking to make an exact copy of a tumbleweed root btrfs filesystem
> on removable media.  One aspect that makes this more fiddly is the number
> of subvolumes that are part of the root filesystem, including /opt and many
> sub-directories of /var.
>
> Is there any technical document describing the reasons behind having so
> many subvolumes?  Someone else was asking the same question at
> stackexchange  (with no real answers) :
>
> http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu
> se-fstab-contain-so-many-btrfs-subvol-entries
>
> Is there a recommended way to get a faithful offline bootable backup of a
> btrfs  rootfs?
>
> Finally, I'm not determined to use btrfs. I'm moving up from 13.1.  I'm
> evaluating Leap and Tumbleweed.  It's a simple desktop, no RAID, one user.
> Would ext4 be a better choice?

Having a low-level copy with dd should not be a problem. On the other hand,
rsync'ing the content from a btrfs volume including all subvolumes to another
volume regardless of the filesystem will copy the content and should work,
without subvolumes, of course. IMHO the openSUSE default of btrfs is a very
good choice for a desktop system, ext4 is no better in general, that's why
btrfs *is* the default choice :-)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Andrei Borzenkov
In reply to this post by Michael Hamilton
On Mon, Oct 17, 2016 at 11:49 AM, Michael Hamilton
<[hidden email]> wrote:
> I was looking to make an exact copy of a tumbleweed root btrfs filesystem
> on removable media.  One aspect that makes this more fiddly is the number
> of subvolumes that are part of the root filesystem, including /opt and many
> sub-directories of /var.
>
> Is there any technical document describing the reasons behind having so
> many subvolumes?

a) SUSE wants to use snapshots of system as safety measure. Snapshots
are per-subvolume, you do not want to revert your database when you
revert failed kernel update, so applications are placed in own
subvolumes. What complicates things, /some/ parts of /var actually
belong to the system as a whole (package database is the best example
of it) so you cannot simply move whole /var to own subvolume. Probably
in the long run filesystem hierarchy needs to be revisited.

b) btrfs is not particularly friendly to some workloads like database
or VM image. Again, storing such data in separate subvolume provides
for disabling offending btrfs features (CoW in the first place)
per-subvolume.

>  Someone else was asking the same question at
> stackexchange  (with no real answers) :
>
> http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensuse-fstab-contain-so-many-btrfs-subvol-entries
>
> Is there a recommended way to get a faithful offline bootable backup of a
> btrfs  rootfs?
>

snapper :)

> Finally, I'm not determined to use btrfs. I'm moving up from 13.1.  I'm evaluating
> Leap and Tumbleweed.  It's a simple desktop, no RAID, one user.  Would
> ext4 be a better choice?
>
> Regards,
> Michael
> --
> To unsubscribe, e-mail: [hidden email]
> To contact the owner, e-mail: [hidden email]
>
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Bruno Friedmann-2
In reply to this post by Oliver Kurz-2
 IMHO the openSUSE default of
> btrfs is a very good choice for a desktop system, ext4 is no better in
> general, that's why btrfs *is* the default choice :-)

May I ask why then /home is proposed with xfs ? ;-)

--

Bruno Friedmann
 Ioda-Net Sàrl www.ioda-net.ch
 Bareos Partner, openSUSE Member, fsfe fellowship
 GPG KEY : D5C9B751C4653227
 irc: tigerfoot


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Simon Lees-3
In reply to this post by Bruno Friedmann-2


On 10/17/2016 08:54 PM, Bruno Friedmann wrote:

> On lundi, 17 octobre 2016 21.49:19 h CEST Michael Hamilton wrote:
>> I was looking to make an exact copy of a tumbleweed root btrfs filesystem
>> on removable media.  One aspect that makes this more fiddly is the number
>> of subvolumes that are part of the root filesystem, including /opt and many
>> sub-directories of /var.
>>
>> Is there any technical document describing the reasons behind having so
>> many subvolumes?  Someone else was asking the same question at
>> stackexchange  (with no real answers) :
>>
>> http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensu
>> se-fstab-contain-so-many-btrfs-subvol-entries
>>
>> Is there a recommended way to get a faithful offline bootable backup of a
>> btrfs  rootfs?
>>
>> Finally, I'm not determined to use btrfs. I'm moving up from 13.1.  I'm
>> evaluating Leap and Tumbleweed.  It's a simple desktop, no RAID, one user.
>> Would ext4 be a better choice?
>>
>> Regards,
>> Michael
>
> From my experience, I'm a btrfs breaker guy (The why has still to be
> determined :-) ).
> So for my own laptop, I using the traditionnal luks encrypted vg/lvm +
> lvm with ext4, this as been rock solid for my own usage, even when I trash the
> power outlet.
> But there's a downside, I'm not using snapper/ext4) and then loose the ability
> to use a rollback snapshot. I have to be careful when doing update with TW.
>
> ;-)
>
> The main reason of having that much subvolume from some clues I got from
> internet is for example, that there's no way to have checksum (interesting for
> database for example) without cow (copy on write, which is not interesting for
> database). The nocow flag disable also checksumming.
> (beware those informations can be outdated since I've test them 6-8 months
> ago)
> Also subvol are related also to quota.
>
The other reason is to avoid the data being captured in a disk snapshot
that can be used too roll back later, for example generally if you need
to roll back to a earlier snapshot to recover your system rolling back
the contents of /tmp /var/cache etc is not useful. You also wouldn't
want to roll back /var/logs as you'd loose data. By having these in a
separate snapshot this wont happen.

Also someone has now answered the stack overflow question covering both
these reasons.

--

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                            Adeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Carlos E. R.-2
On 2016-10-17 13:59, Simon Lees wrote:

>>
> The other reason is to avoid the data being captured in a disk snapshot
> that can be used too roll back later, for example generally if you need
> to roll back to a earlier snapshot to recover your system rolling back
> the contents of /tmp /var/cache etc is not useful. You also wouldn't
> want to roll back /var/logs as you'd loose data. By having these in a
> separate snapshot this wont happen.

Yes.

It would be nice if there were a script or something to create all those
volumes, used during installation, so that the admin could recreate them
easily.

Or a function in the YaST partitioner module to create that layout in a
new or existing empty btrfs partition without doing an install.

Just an idea :-)

--
Cheers / Saludos,

                Carlos E. R.
                (from 13.1 x86_64 "Bottle" at Telcontar)


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Vojtěch Zeisek-2
In reply to this post by Bruno Friedmann-2
Dne pondělí 17. října 2016 13:18:48 CEST, Bruno Friedmann napsal(a):
>  IMHO the openSUSE default of
>
> > btrfs is a very good choice for a desktop system, ext4 is no better in
> > general, that's why btrfs *is* the default choice :-)
>
> May I ask why then /home is proposed with xfs ? ;-)

I think because /home has so many quickly changing files it'd produce huge
snapshots and fragmentation. It is better to use another tools to backup Your
home. When there is no separate XFS /home partition, then there is Btrfs
subvolume to exclude snapshoting.

--
Vojtěch Zeisek

Komunita openSUSE GNU/Linuxu
Community of the openSUSE GNU/Linux

https://www.opensuse.org/
https://trapa.cz/

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Richard Brown
In reply to this post by Andrei Borzenkov
On 17 October 2016 at 13:08, Andrei Borzenkov <[hidden email]> wrote:

> b) btrfs is not particularly friendly to some workloads like database
> or VM image. Again, storing such data in separate subvolume provides
> for disabling offending btrfs features (CoW in the first place)
> per-subvolume.

MINOR CORRECTION (ie. I actually agree with most of what you said and
the thrust of your argument)

You can actually disable CoW on a folder or files within a subvolume -
NoCoW is not an attribute of a Subvolume, but an xattr applied to
files. If applied to a directory, the attribute is automatically set
on all files created in that directory from that point on.

In openSUSE, the YaST installer will set NoCoW on certain mountpoints
of certain subvolumes, so the effect is exactly as you described above

But I just wanted to clear up it's not a Subvolume feature, you can
turn CoW off wherever you want :)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Bruno Friedmann-2
In reply to this post by Vojtěch Zeisek-2
On lundi, 17 octobre 2016 14.44:44 h CEST Vojtěch Zeisek wrote:

> Dne pondělí 17. října 2016 13:18:48 CEST, Bruno Friedmann napsal(a):
> >  IMHO the openSUSE default of
> >  
> > > btrfs is a very good choice for a desktop system, ext4 is no better in
> > > general, that's why btrfs *is* the default choice :-)
> >
> > May I ask why then /home is proposed with xfs ? ;-)
>
> I think because /home has so many quickly changing files it'd produce huge
> snapshots and fragmentation. It is better to use another tools to backup
> Your home. When there is no separate XFS /home partition, then there is
> Btrfs subvolume to exclude snapshoting.

I know a system tool that produce a lot of changes too :-)
journald

One of the use case I would like to see covered is the use of btrfs + samba4
this (at least for me on paper) offering nice feature like move file on server
side, snapshots for end user to have x version of their files etc.

But ultimately, then how to save properly a snapshot to be able to restore a
system in a point in time ?

--

Bruno Friedmann
 Ioda-Net Sàrl www.ioda-net.ch
 Bareos Partner, openSUSE Member, fsfe fellowship
 GPG KEY : D5C9B751C4653227
 irc: tigerfoot


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Richard Brown
In reply to this post by Vojtěch Zeisek-2
On 17 October 2016 at 14:44, Vojtěch Zeisek <[hidden email]> wrote:

> Dne pondělí 17. října 2016 13:18:48 CEST, Bruno Friedmann napsal(a):
>>  IMHO the openSUSE default of
>>
>> > btrfs is a very good choice for a desktop system, ext4 is no better in
>> > general, that's why btrfs *is* the default choice :-)
>>
>> May I ask why then /home is proposed with xfs ? ;-)
>
> I think because /home has so many quickly changing files it'd produce huge
> snapshots and fragmentation. It is better to use another tools to backup Your
> home. When there is no separate XFS /home partition, then there is Btrfs
> subvolume to exclude snapshoting.

Pretty accurate

Also, when you are not benefiting from snapshotting, XFS is a little
faster in a broader collection of use cases, such as those you see in
/home, so it's a good default choice for /home

Personally on my systems with a single disk/SSD I'm BTRFS all the way,
because I don't like the additional complexity of managing partitions,
especially when btrfs subvolumes gives me most of the controls I
actually want

XFS is only my filesystem of choice on dedicated data disks

Which is pretty well aligned with what the openSUSE default is
encoraging.. btrfs for root, XFS for data.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Vojtěch Zeisek-2
In reply to this post by Bruno Friedmann-2
Dne pondělí 17. října 2016 16:38:23 CEST, Bruno Friedmann napsal(a):

> On lundi, 17 octobre 2016 14.44:44 h CEST Vojtěch Zeisek wrote:
> > Dne pondělí 17. října 2016 13:18:48 CEST, Bruno Friedmann napsal(a):
> > >  IMHO the openSUSE default of
> > >  
> > > > btrfs is a very good choice for a desktop system, ext4 is no better in
> > > > general, that's why btrfs *is* the default choice :-)
> > >
> > > May I ask why then /home is proposed with xfs ? ;-)
> >
> > I think because /home has so many quickly changing files it'd produce huge
> > snapshots and fragmentation. It is better to use another tools to backup
> > Your home. When there is no separate XFS /home partition, then there is
> > Btrfs subvolume to exclude snapshoting.
>
> I know a system tool that produce a lot of changes too :-)
> journald
Yes, logs are also in excluded subvolume. ;-)

> One of the use case I would like to see covered is the use of btrfs + samba4
> this (at least for me on paper) offering nice feature like move file on
> server side, snapshots for end user to have x version of their files etc.

I have similar principle to keep backups on the server - separated disc has
Btrfs. Make a snapshot and rsync current data on it. Like this one has
incremental (in our case daily) backups of whole user directory.

> But ultimately, then how to save properly a snapshot to be able to restore a
> system in a point in time ?

https://en.opensuse.org/Portal:Snapper
https://doc.opensuse.org/documentation/leap/reference/html/
book.opensuse.reference/cha.snapper.html

--
Vojtěch Zeisek

Komunita openSUSE GNU/Linuxu
Community of the openSUSE GNU/Linux

https://www.opensuse.org/
https://trapa.cz/

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Bruno Friedmann-2
In reply to this post by Richard Brown
On lundi, 17 octobre 2016 15.57:06 h CEST Richard Brown wrote:
> But I just wanted to clear up it's not a Subvolume feature, you can
> turn CoW off wherever you want :)

For my sake, putting this attribute, keep the checksuming function ?

--

Bruno Friedmann
 Ioda-Net Sàrl www.ioda-net.ch
 Bareos Partner, openSUSE Member, fsfe fellowship
 GPG KEY : D5C9B751C4653227
 irc: tigerfoot


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Carlos E. R.-2
In reply to this post by Richard Brown
On 2016-10-17 17:02, Richard Brown wrote:

> Personally on my systems with a single disk/SSD I'm BTRFS all the way,
> because I don't like the additional complexity of managing partitions,
> especially when btrfs subvolumes gives me most of the controls I
> actually want

What about installation of new version, keeping home intact? YaST
normally would format the system partition and keep /home.

--
Cheers / Saludos,

                Carlos E. R.
                (from 13.1 x86_64 "Bottle" at Telcontar)


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Andrei Borzenkov
In reply to this post by Bruno Friedmann-2
17.10.2016 20:22, Bruno Friedmann пишет:
> On lundi, 17 octobre 2016 15.57:06 h CEST Richard Brown wrote:
>> But I just wanted to clear up it's not a Subvolume feature, you can
>> turn CoW off wherever you want :)
>
> For my sake, putting this attribute, keep the checksuming function ?
>

No. Once CoW is disabled for a file, checksumming for this file is also
disabled.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Michael Hamilton
In reply to this post by Carlos E. R.-2
On Tue, 18 Oct 2016, Carlos E. R. wrote:

> On 2016-10-17 13:59, Simon Lees wrote:
>
> >>
> > The other reason is to avoid the data being captured in a disk snapshot
> > that can be used too roll back later, for example generally if you need
> > to roll back to a earlier snapshot to recover your system rolling back
> > the contents of /tmp /var/cache etc is not useful. You also wouldn't
> > want to roll back /var/logs as you'd loose data. By having these in a
> > separate snapshot this wont happen.
>
> Yes.
>
> It would be nice if there were a script or something to create all those
> volumes, used during installation, so that the admin could recreate them
> easily.
>
> Or a function in the YaST partitioner module to create that layout in a
> new or existing empty btrfs partition without doing an install.
>
> Just an idea :-)
>

Yes, this would be quite useful.  It would then be straight forward to use
snapper to create a snapshot, rsync the snapshot to the new structure
and then followup with an rsync of any subvolumes that should also
be backed up.  This would also make cpio/tar based backups more
straight forward.

Regards,
Michael
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Michael Hamilton
In reply to this post by Michael Hamilton
On Mon, 17 Oct 2016, Matthias G. Eckermann wrote:

> Hello Michael and all,
>
> On 2016-10-17 T 21:49 +1300 Michael Hamilton wrote:
>
> > I was looking to make an exact copy of a tumbleweed root btrfs
> > filesystem on removable media.  One aspect that makes this
> > more fiddly is the number of subvolumes that are part of the
> > root filesystem, including /opt and many sub-directories of
> > /var.  
> >
> > Is there any technical document describing the reasons behind
> > having so many subvolumes?  Someone else was asking the same
> > question at stackexchange  (with no real answers) :
> >
> > http://unix.stackexchange.com/questions/285011/why-does-my-tumbleweed-opensuse-fstab-contain-so-many-btrfs-subvol-entries
>
> the reason is that these subdirectories/subvolumes must be
> excluded from being snapshotted, or more exactly from being
> rolled-back; a short explanation can be found in this old blog,
> for example:
>
> https://www.suse.com/communities/blog/introduction-system-rollbacks-btrfs-and-snapper-sles-11-sp2/
>
> To make this better understood, just imagine /var/log/ being
> snapshotted and rolled back: This would destroy the continuity
> of log files and thus create confusion for normal use cases and
> break "compliance" where this is required (e.g. financial
> applications and environemnts).
>
> > Is there a recommended way to get a faithful offline bootable
> > backup of a btrfs rootfs?
>
> Can you describe your use case for an "offline bootable backup"
> in more detail?
>
> > Finally, I'm not determined to use btrfs. I'm moving up from
> > 13.1.  I'm evaluating Leap and Tumbleweed.  It's a simple
> > desktop, no RAID, one user.  Would ext4 be a better choice?  
>
> I would use Leap with btrfs, if I would not be using SLES with
> btrfs already:-)
>
> So long -
> MgE
>

From your answer and others, I can see that the existing structure
of /var provides a tough problem in respect to keeping things
simple for a btrfs based root.  I see that /opt is similar - sometimes
databases live in there.  (Ideally a new simpler structure might be
nice - but I guess we have standards to obey).

In answer to your question about my use case:  I want a copy of
the root filesystem is for reasonably quick recovery from the
loss of the underlying SSD/HD and for recovery from admin
mistakes.  So this would be for bootable backups to some other
media, and with the option to rotate the media off site (I
currently use USB-3 external drives).

To a degree btrfs snaphots should protect me from
admin mistakes,  but not from big stuff-ups such as formatting
the wrong device.  

For example, during the my initial install of tumbleweed, my SSD
died (it was only 5 years old!).  The SSD was also where my 13.1
root was kept.  Because I had made an exact backup of 13.1
onto another drive, it only took a few minutes to replace the drive
and get back in business.  So I'd like to do the same kind of
backup for tumbleweed.  In the past I have used RAID, but
that was prone to errors/mistakes that were faithfully replicated
to all RAID members.  Periodic backups to offline media is
not as seemless for recovery, but it's very safe.

Btrfs send|receive doesn't appear to make an exact replica,
subfolders are created.  I guess I could combine it with a bunch
of shell scripts to get a bootable replica.

From reading the answers so far, the closest I can get would
be to create a btrfs volume and manually recreate the subvolume
structure.  Tedious, possibly error prone, but only needed once -
maybe do a dummy install or dd to get it right.  Then periodically
use snapper to create a snapshot and rsync that.  Also have rsync
replicate any subvolumes I thing would be useful (e.g. /var/log
and /opt).


Regards,
Michael


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Anton Aylward-2
In reply to this post by Vojtěch Zeisek-2
On 10/17/2016 06:13 AM, Vojtěch Zeisek wrote:
> The subvolumes typically exclude quickly
> changing temporary, DB, cache, ... directories from snapshots to save space
> and the disk.

Yes but what about 'filters as in /etc/snapper/filters ??

# ls /etc/snapper/filters/
base.txt  logfiles.txt  lvm.txt  x11.txt

Is this another exclusion mechanism?

I can't, on a quick read, find mention of this in the man page on snapper-config.

--
When languishing for solutions, don't ask "Have I got the correct answer?"
The correct question is "Have I got the correct question?"
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs root - why so many subvolumes?

Bruno Friedmann-2
In reply to this post by Andrei Borzenkov
On lundi, 17 octobre 2016 22.49:09 h CEST Andrei Borzenkov wrote:
> 17.10.2016 20:22, Bruno Friedmann пишет:
> > On lundi, 17 octobre 2016 15.57:06 h CEST Richard Brown wrote:
> >> But I just wanted to clear up it's not a Subvolume feature, you can
> >> turn CoW off wherever you want :)
> >
> > For my sake, putting this attribute, keep the checksuming function ?
>
> No. Once CoW is disabled for a file, checksumming for this file is also
> disabled.

ok thank you, then it become less interesting for myself and use case than
how things works with luks/lvm and ext4/xfs

--

Bruno Friedmann
 Ioda-Net Sàrl www.ioda-net.ch
 Bareos Partner, openSUSE Member, fsfe fellowship
 GPG KEY : D5C9B751C4653227
 irc: tigerfoot


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12