From: Kai Krakow <hurikhan77@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: backing up a collection of snapshot subvolumes
Date: Tue, 25 Apr 2017 22:20:02 +0200 [thread overview]
Message-ID: <20170425222002.4f119fc6@jupiter.sol.kaishome.de> (raw)
In-Reply-To: 58FECA45.1010107@gmail.com
Am Tue, 25 Apr 2017 00:02:13 -0400
schrieb "J. Hart" <jfhart085@gmail.com>:
> I have a remote machine with a filesystem for which I periodically
> take incremental snapshots for historical reasons. These snapshots
> are stored in an archival filesystem tree on a file server. Older
> snapshots are removed and newer ones added on a rotational basis. I
> need to be able to backup this archive by syncing it with a set of
> backup drives. Due to the size, I need to back it up incrementally
> rather than sending the entire content each time. Due to the
> snapshot rotation, I need to be able to update the state of the
> archive backup filesystem as a whole, in much the same manner that
> rsync handles file trees.
>
> It seems that I cannot use "btrfs send", as the archive directory
> contains the snapshots as subvolumes.
>
> I cannot use rsync as it treats subvolumes as simple directories, and
> does not preserve subvolume attributes. Rsync also does not support
> reflinks, so the snapshot directory content will no longer be
> reflinked to other snapshots on the archive backup. I cannot use
> hard links in the incrementals as hard links do not cross subvolume
> boundaries.
>
> Thoughts anyone ?
If this is for archival purpose only and storage efficiency and speed is
your primary concern, try borgbackup.
Borgbackup deploys its own deduplication and doesn't rely on btrfs
snapshot capabilities. You can store your archives wherever you want
(even on non-btrfs), and it won't store any data blocks twice.
Upon restore, you could simply recreate the snapshot/subvolume from a
similar tree and then rsync a tree restored from borgbackup back to
this snapshot to get back a state with the benefits of btrfs snapshots.
Borg also has an adapter for fuse to get a mounted view into the
archives, tho, it is slow and probably takes a lot of RAM. But it is
good enough for single file lookups and navigation.
--
Regards,
Kai
Replies to list-only preferred.
prev parent reply other threads:[~2017-04-25 20:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-25 4:02 backing up a collection of snapshot subvolumes J. Hart
2017-04-25 14:13 ` Graham Cobb
2017-04-25 20:20 ` Kai Krakow [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170425222002.4f119fc6@jupiter.sol.kaishome.de \
--to=hurikhan77@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.