On Mon, May 05, 2014 at 03:24:45AM +, Duncan wrote:
*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
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
On 2014/05/04 05:12 AM, Marc MERLIN wrote:
Another question I just came up with.
If I have historical snapshots like so:
backup
backup.sav1
backup.sav2
backup.sav3
If I want to copy them up to another server, can btrfs send/receive
let me copy all of the to another btrfs pool while keeping the
On Sun, May 04, 2014 at 09:16:02AM +0200, Brendan Hide wrote:
Sending one-at-a-time, the shared-data relationship will be kept by
using the -p (parent) parameter. Send will only send the differences
and receive will create a new snapshot, adjusting for those
differences, even when the receive
On 2014/05/04 09:28 AM, Marc MERLIN wrote:
On Sun, May 04, 2014 at 09:16:02AM +0200, Brendan Hide wrote:
Sending one-at-a-time, the shared-data relationship will be kept by
using the -p (parent) parameter. Send will only send the differences
and receive will create a new snapshot, adjusting for
On Sun, May 04, 2014 at 09:54:38AM +0200, Brendan Hide wrote:
Yes, -p (parent) and -c (clone source) are the only ways I'm aware
of to push subvolumes across while ensuring data-sharing
relationship remains intact. This will end up being much the same as
doing incremental backups:
From the
