From: Kai Krakow <hurikhan77@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: backing up a file server with many subvolumes
Date: Sat, 1 Apr 2017 10:24:31 +0200 [thread overview]
Message-ID: <20170401102431.5c6b5643@jupiter.sol.kaishome.de> (raw)
In-Reply-To: 59dccd7e-6cb6-ea66-3150-0ce85472e73a@rqc.ru
Am Mon, 27 Mar 2017 08:57:17 +0300
schrieb Marat Khalili <mkh@rqc.ru>:
> Just some consideration, since I've faced similar but no exactly same
> problem: use rsync, but create snapshots on target machine. Blind
> rsync will destroy deduplication of your snapshots and take huge
> amount of storage, so it's not a solution. But you can rsync --inline
> your snapshots in chronological order to some folder and re-take
> snapshots of that folder, thus recreating your snapshots structure on
> target. Obviously, it can/should be automated.
I think it's --inplace and --no-whole-file...
Apparently, rsync cannot detect moved files which was a big deal for me
regarding deduplication, so I found another solution which is even
faster. See my other reply.
> On 26/03/17 06:00, J. Hart 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.
> >
> > Any thoughts would be most appreciated.
> >
> > J. Hart
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-btrfs" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-btrfs" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Kai
Replies to list-only preferred.
next prev parent reply other threads:[~2017-04-01 8:25 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
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 [this message]
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=20170401102431.5c6b5643@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox