[rear-users] Btrfs subvolume snapshots backup and restore

Schlomo Schapiro schlomo at schapiro.org
Wed Sep 25 13:15:16 CEST 2013


Hi,

I am not sure that this request fits into the ReaR mindset.

We need to separate two different usage scenarios here:

   1. ReaR makes the backup with tar or rsync and also restores the backup
   2. ReaR uses existing backup software to restore the backup data

ReaR's concept of backup is completely file-based, not block-based. As long
as the snapshots also appear as mounted file systems, that might indeed be
possible (But it might be highly inefficient as each snapshot would
probably appear as an independant filesystem and content thus duplicated).

If the old snapshots are "hidden" from the regular file-system view, then
ReaR also does not see them! Same is probably true for other file-based
backup software. I did a quick search for backup or cloning of btrfs and
only found
http://unix.stackexchange.com/questions/63528/how-to-clone-btrfs-filesystem-into-different-medium-preserving-snapshots-sharin
with
meaningful content.

In any case, I suspect that the file-based thinking that is now the core of
ReaR is very much in the way of doing backup and restore for stuff that is
not visible as a file.

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. Maybe it is even
worth to split ReaR into a recovery and a restore part to keep both parts
simple.

Maybe I also completely wrong and ReaR should evolve with the btrfs
challange. Is there somebody behind this request who would be willing to
invest into ReaR doing this?

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

Regards,
Schlomo

PS: Maybe combined with https://github.com/g2p/bedup it could be feasible
to restore the snapshots file-based and use the deduplcation at restore
time to prevent the disk from beeing filled up by the duplicate files (in
current and N snapshots).


On 24 September 2013 17:45, Johannes Meixner <jsmeix at suse.de> wrote:

>
> Hello,
>
> I was asked whether or not Rear can be used to backup and
> restore a system with btrfs filesystems that have subvolumes
> which contain snapshots.
>
> The request is to also have all the snapshots back.
>
> Because I am not at all a btrfs expert I would like to get
> some more information or feedback here.
>
> http://relax-and-recover.org/**documentation/release-notes-1-**15<http://relax-and-recover.org/documentation/release-notes-1-15>
> reads:
> ------------------------------**------------------------------**
> ------------
> Version 1.15.0 (September 2013)
> ...
> Deal with BTRFS subvolumes correctly (issue #233 and #252)
> .
> .
> .
> Version 1.12.0
> ...
> (NEW! EXPERIMENTAL!) Basic btrfs file system backup and restore works.
> Advise is not to trust it (yet).
> ------------------------------**------------------------------**
> ------------
>
> Since Rear 1.15.0 it should work that Rear re-creates the disk layout
> when btrfs file systems with subvolumes are used.
>
> On first glance it seems when there are btrfs subvolume snapshots,
> all what the admin must do is that the data in the snapshot
> subvolumes is accessible by the backup program when he wants
> to also have all his snapshots back after a system recovery.
>
> But because btrfs snapshot data is not a copy of the files
> but only of the changes (via btrfs' copy on write functionality),
> the backup program would backup the content of the files twice
> (the original file and the same content via the btrfs snapshot)
> so that a restore would need basically twice as much disk space
> (under the assumption that there are only little changes).
>
> Therefore I wonder if the request for backup and restore
> of btrfs subvolume snapshots actually makes sense
> from a low-level btrfs point of view?
>
> From an end-user point of view that request makes sense because
> the admin may make btrfs snapshots only from time to time when needed
> and even after a system recovery he may not want to lose his ability
> to go back to this or that older btrfs snapshot state.
>
>
> Kind Regards
> Johannes Meixner
> --
> SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
> HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
> ______________________________**_________________
> rear-users mailing list
> rear-users at lists.relax-and-**recover.org<rear-users at lists.relax-and-recover.org>
> http://pikachu.3ti.be/mailman/**listinfo/rear-users<http://pikachu.3ti.be/mailman/listinfo/rear-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pikachu.3ti.be/pipermail/rear-users/attachments/20130925/417f4d78/attachment.html>


More information about the rear-users mailing list