[rear-users] Btrfs subvolume snapshots backup and restore

Johannes Meixner jsmeix at suse.de
Wed Sep 25 17:49:19 CEST 2013


Hello,

On Sep 25 13:15 Schlomo Schapiro wrote (excerpt):
>
> I am not sure that this request fits into the ReaR mindset.
...
> I would also be careful to keep ReaR focused on what it does
> really well:
> Restoring the partitioning, file systems layout and boot loader
> on a naked system and restoring the files into the file systems.

Exactly the latter does no longer work really well
if btrfs subvolume snapshots are there.

But I agree that the root cause is not at all ReaR.

The root cause is that - as far as I currently know - that
btrfs does not provide a tool to backup and restore
a btrfs filesystem so that after the restore one gets
the btrfs filesystem back basically as it was before
(in particular subvolume snapshots are restored
as subvolume snapshots).

I do not talk about backup and restore of data that is not visible
(i.e. files in filesystems that are not mounted).
When data is not accessible it cannot be in the backup.
That is perfectly correct.
When an admin has made data not accessible, he cannot want
to have that data in his backup.

But btrfs subvolume snapshot data is accessible by default.

Therefore for the admin who knows that ReaR restores
the partitioning, file systems layout and boot loader
on a naked system and restoring the files into the file systems
expects that this will also work for a btrfs file system.

But - as far as I currently know - this does no longer work
when the btrfs file system contains subvolume snapshots.

On an openSUSE 13.1 beta1 virtual machine set up from scratch
with btrfs as it happens by default one gets automated hourly
snapshots of almost the whole '/' file system:
--------------------------------------------------------------------
# btrfs subvolume list /
ID 256 gen 35 top level 5 path boot/grub2/i386-pc
ID 258 gen 1025 top level 5 path home
ID 259 gen 18 top level 5 path opt
ID 260 gen 26 top level 5 path srv
ID 261 gen 1523 top level 5 path tmp
ID 262 gen 41 top level 5 path usr/local
ID 263 gen 18 top level 5 path var/crash
ID 264 gen 1524 top level 5 path var/log
ID 265 gen 18 top level 5 path var/opt
ID 266 gen 1526 top level 5 path var/spool
ID 267 gen 44 top level 5 path var/tmp
ID 272 gen 1494 top level 5 path .snapshots
ID 273 gen 58 top level 5 path .snapshots/1/snapshot
ID 274 gen 122 top level 5 path .snapshots/2/snapshot
...
ID 300 gen 1493 top level 5 path .snapshots/24/snapshot
--------------------------------------------------------------------

Via the /.snapshots/1/snapshot/ ... /.snapshots/24/snapshot/
directories all data in the btrfs subvolume snapshots
is accessible so that it can be in the backup.

When I use the traditional "du" tool that doesn't know
about the actual disk usage of btrfs subvolume snapshots
you get strange looking results:
--------------------------------------------------------------------
# du -hs /
70G     /

# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       7.1G  2.8G  4.0G  41% /

# btrfs filesystem df /
Data: total=2.82GiB, used=2.32GiB
System, DUP: total=8.00MiB, used=4.00KiB
System: total=4.00MiB, used=0.00
Metadata, DUP: total=359.38MiB, used=206.96MiB
Metadata: total=8.00MiB, used=0.00
--------------------------------------------------------------------

Wow!
I have 70G of accessible files stored on my 7.1G disk
and still have 59% free space there ;-)

If I made an usual file-based backup of '/' (e.g. via 'tar')
I got a tarball with 70G that I cannot restore on my 7.1G disk.

Therefore I fear that what you wrote
"ReaR should evolve with the btrfs challange"
cannot be avoided.

But that does of course not mean that ReaR must right now
"just work" with btrfs subvolume snapshots.

"Evolve" is the exact right wording here.


> Is there somebody behind this request

There is one who asked for it and currently I am evaluating it.


> if there would be a btrfs-aware backup tool similar to dump for
> ext2/3/4 that might help a lot!

I agree.

I even think that btrfs-aware backup tool must be provided
by btrfs itself to ensure that it works correctly.

>From my current point of view it seems the root cause is
that btrfs does not provide such a tool (see above).


> PS: Maybe combined with https://github.com/g2p/bedup

https://github.com/g2p/bedup/blob/master/README.rst
reads:
-----------------------------------------------------------------
Subvolumes

The clone call is considered a write operation and won't work
on read-only snapshots.
-----------------------------------------------------------------

But for a btrfs subvolume snapshot it is recommended to be created
read-only to avoid that the data in the snapshot could be changed
later by accident.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer


More information about the rear-users mailing list