[rear-users] Btrfs subvolume snapshots backup and restore

Johannes Meixner jsmeix at suse.de
Tue Oct 1 13:27:22 CEST 2013


On Sep 28 22:48 Schlomo Schapiro wrote (excerpt):
> OK, so do we all agree that ReaR can use only the tools
> that already exist?

I do fully agree.
ReaR should never ever implememt its own backup and restore tools.

> As long as there is no "smart" btrfs backup tool
> there is not much we can do.

I got the information that "The "initial bootstrapping" section at
describes how to dump and restore even a whole btrfs filesystem
by using btrfs send and btrfs receive.

Curently I am evaluating it.

But even if there is a "smart" btrfs backup tool, it conflicts
with the third party backup tools that can be used by Rear.
In particular for the third-party backup and restore software
solutions I currently do not see how that could work for btrfs
with some snapshot subvolumes when the admin wants to have
also his snapshots back after a recovery.

> BTW, should we automatically exclude the snapshot subvolumes?

All btrfs subvolumes are automatically excluded by 'tar' because
Rear calls 'tar --one-file-system' and at least for 'tar'
btrfs subvolumes behave as if they were a different filesystem.

Therefore the Rear user must explicitly include btrfs subvolumes
(via BACKUP_PROG_INCLUDE in /etc/rear/local.conf)
to have them at least in a 'tar' backup.

> I also think that the loss of snapshots could be forgiven
> in the case of a real disaster that made you recover the
> server on fresh hardware :-) After all all snapshot systems
> utilize the same disks for the snapshots and don't offload
> the snapshots to secure storage.

I do not agree.

Assume the admin does a major rework on his server that takes some days.
To be safe he creates a btrfs snapshot before he starts his rework.
At some day while the major rework is still done and while the server
system as a whole is in a very inconsistent state a disaster happens.
If the admin cannot also have his btrfs snapshot back after disaster
recovery he can onyl get back the inconsistent state.

Of course a really careful admin should not rely on btrfs snapshots
but do a real backup on separated media instead.

But btrfs snapshots is so much advertised as major feature of btrfs
that I think it is "just expected" that this "just works" even
for disaster recovery.

I think first and foremost we need documentation (i.e. we need at least
basic understanding) how to do backup and restore of btrfs filesystems
properly with "normal" subvolumes and with snapshot subvolumes.

For example if "btrfs send/receive" is used, one cannot backup a
btrfs filesystem and restore it on a different filesystem.

I think a generic method which could work with plain 'tar'
(and also other plain file-based backup solutions)
independent of the used filesystem during recovery
if there are only a few btrfs snapshot subvolumes
could be like this:

Assume there is only / and /snapshot.old and /snapshot.new

- tar all files in / but exclude the snapshots into current.tar.gz
- tar the files in /snapshot.old into snapshot.old.tar.gz
- tar the files in /snapshot.new into snapshot.new.tar.gz

When btrfs is used for recovery:

- restore snapshot.old.tar.gz into /
- make a btrfs snapshot of / as /snapshot.old
- overwrite / by restoring snapshot.new.tar.gz into /
- make a btrfs snapshot of / as /snapshot.new
- overwrite / by restoring current.tar.gz into /

Of course recovery on btrfs with the snapshots back
by using this generic method needs tree times more time.

If a differnt filesystem should be used for recovery (e.g. ext3):

- restore current.tar.gz or snapshot.old.tar.gz or snapshot.new.tar.gz
   into / depending on to what state the admin likes to recover.

This may lead to a feature during recovery that there could be
a dialog where the admin can choose what backup to restore.

I am evaluating it.
Please be patient - I will report my findings here...

And of course I would very much appreciate feedback how others do
their backup and restore for btrfs filesystems with snapshots.

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