From: Roman Mamedov <rm@romanrm.net>
To: "J. Hart" <jfhart085@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: backing up a file server with many subvolumes
Date: Sun, 26 Mar 2017 14:14:36 +0500 [thread overview]
Message-ID: <20170326141436.4ffffca9@natsu> (raw)
In-Reply-To: <58D72EC4.9020101@gmail.com>
On Sat, 25 Mar 2017 23:00:20 -0400
"J. Hart" <jfhart085@gmail.com> wrote:
> I have a Btrfs filesystem on a backup server. This filesystem has a
> directory to hold backups for filesystems from remote machines. In this
> directory is a subdirectory for each machine. Under each machine
> subdirectory is one directory for each filesystem (ex /boot, /home, etc)
> on that machine. In each filesystem subdirectory are incremental
> snapshot subvolumes for that filesystem. The scheme is something like
> this:
>
> <top>/backup/<machine>/<filesystem>/<many snapshot subvolumes>
>
> I'd like to try to back up (duplicate) the file server filesystem
> containing these snapshot subvolumes for each remote machine. The
> problem is that I don't think I can use send/receive to do this. "Btrfs
> send" requires "read-only" snapshots, and snapshots are not recursive as
> yet. I think there are too many subvolumes which change too often to
> make doing this without recursion practical.
You could have done time-based snapshots on the top level (for /backup/), say,
every 6 hours, and keep those for e.g. a month. Then don't bother with any
other kind of subvolumes/snapshots on the backup machine, and do backups from
remote machines into their respective subdirectories using simple 'rsync'.
That's what a sensible scheme looks like IMO, as opposed to a Btrfs-induced
exercise in futility that you have (there are subvolumes? must use them for
everything, even the frigging /boot/; there is send/receive? absolutely must
use it for backing up; etc.)
--
With respect,
Roman
next prev parent reply other threads:[~2017-03-26 9:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-26 3:00 backing up a file server with many subvolumes J. Hart
2017-03-26 9:14 ` Roman Mamedov [this message]
2017-03-26 19:51 ` Adam Borowski
2017-03-26 20:24 ` Peter Grandi
2017-03-27 5:57 ` Marat Khalili
2017-03-27 12:00 ` J. Hart
2017-03-27 13:05 ` Graham Cobb
2017-04-01 8:24 ` Kai Krakow
2017-03-27 11:53 ` Austin S. Hemmelgarn
2017-04-01 8:21 ` Kai Krakow
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=20170326141436.4ffffca9@natsu \
--to=rm@romanrm.net \
--cc=jfhart085@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.