From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Copying related snapshots to another server with btrfs send/receive?
Date: Mon, 5 May 2014 03:24:45 +0000 (UTC) [thread overview]
Message-ID: <pan$10f8$1751c450$6f6d3a98$57d04ce1@cox.net> (raw)
In-Reply-To: 5365F23E.8070009@swiftspirit.co.za
Brendan Hide posted on Sun, 04 May 2014 09:54:38 +0200 as excerpted:
> From the man page section on -c:
> "You must not specify clone sources unless you guarantee that these
> snapshots are exactly in the same state on both sides, the sender and
> the receiver. It is allowed to omit the '-p <parent>' option when '-c
> <clone-src>' options are given, in which case 'btrfs send' will
> determine a suitable parent among the clone sources itself."
>
> -p does require that the sources be read-only. I suspect -c does as
> well. This means that it won't be so simple as you want your sources to
> be read-write. Probably the only way then would be to make read-only
> snapshots whenever you want to sync these over while also ensuring that
> you keep at least one read-only snapshot intact - again, much like
> incremental backups.
I don't claim in any way to be a send/receive expert as I don't use it
for my use-case at all. However...
It's worth noting in the context of that manpage quote, that really the
only practical way to guarantee that the snapshots are exactly the same
on both sides is to have them read-only the entire time. Because the
moment you make them writable on either side all bets are off as to
whether something has been written, thereby killing the exact-same-state
guarantee. =:^(
*However*: snapshotting a read-only snapshot and making the new one
writable is easy enough[1]. Just keep the originals read-only so they
can be used as parents/clones, and make a second, writable snapshot of
the first, to do your writable stuff in.
---
[1] Snapshotting a snapshot: I'm getting a metaphorical flashing light
saying I need to go check the wiki FAQ that deals with this again before
I post, but unfortunately I can't check out why ATM as I just upgraded
firefox and cairo and am currently getting a blank window where the
firefox content should be, that will hopefully be gone and the content
displayed after I reboot and get rid of the still loaded old libs, so
unfortunately I can't check that flashing light ATM and am writing
blind. Hopefully that flashing light warning isn't for something /too/
major that I'm overlooking! =:^(
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2014-05-06 19:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-04 3:12 Copying related snapshots to another server with btrfs send/receive? Marc MERLIN
2014-05-04 7:16 ` Brendan Hide
2014-05-04 7:28 ` Marc MERLIN
2014-05-04 7:54 ` Brendan Hide
2014-05-05 1:04 ` Marc MERLIN
2014-05-05 3:24 ` Duncan [this message]
2014-05-07 7:51 ` Marc MERLIN
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='pan$10f8$1751c450$6f6d3a98$57d04ce1@cox.net' \
--to=1i5t5.duncan@cox.net \
--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;
as well as URLs for NNTP newsgroup(s).