From: Matthew Lai <m@matthewlai.ca>
To: linux-btrfs@vger.kernel.org
Subject: Re: Receive on same subvolume
Date: Mon, 03 Feb 2014 10:19:18 -0800 [thread overview]
Message-ID: <52EFDDA6.2060907@matthewlai.ca> (raw)
In-Reply-To: <4D0416BE-42D6-4458-9519-9836CC979005@colorremedies.com>
Thanks. I should clarify what I'm trying to do.
I'm trying to use btrfs send for backup, without having another btrfs
volume.
So the initial backup is a complete send, piped to Amazon Glacier (so my
machine never has the whole file, and doesn't have space for one).
At the same time I'm keeping a snapshot of the current volume.
On the next incremental backup, I would use the first snapshot as the
parent, and send the differences to Glacier again (without having the
entire file on the system at any time).
It looks like the problem now is the sent file can't be applied to the
original volume (for restore).
Thanks
Matthew
On 03/02/2014 9:30 AM, Chris Murphy wrote:
> On Jan 29, 2014, at 2:26 PM, Matthew Lai <m@matthewlai.ca> wrote:
>
>> Hello,
>>
>> Is this supposed to work? (/data is the root volume, /data/a is a subvolume)
>>
>> btrfs subvolume snapshot /data/a /data/b
>> # make some changes in b
>> btrfs send -p /data/a /data/b > delta
>> btrfs receive /data/a < delta
>>
>> I'm getting "ERROR: could not find parent subvolume" on receive.
>> What I'm trying to do is to back up using send/receive, but I don't have 50% free space, and (please correct me if I'm wrong) since receive doesn't do deduplication, I want to use snapshot to do the initial bootstrapping, instead of send/receive without a parent.
> I think you've oversimplified your commands, because it looks like you're using send/receive on the same file system. But if it's a backup, necessarily you'd have to be sending the subvolume(s) to another file system on another disk (either on the same system or remotely). So that needs some clarification.
>
> Also, btrfs send requires subvolumes to be read only. Are they?
>
> And btrfs incremental receive expects the identical parent already on the destination. Is it?
>
> Also, while I'm not certain it matters, man page says to use -f to specify files. I haven't tested < and >. But then also the step where you create this intermediate snapshot file isn't necessary, just combine the send receive commands through pipe.
>
>
> https://btrfs.wiki.kernel.org/index.php/Incremental_Backup
>
>
> Chris Murphy
>
> --
> 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
next prev parent reply other threads:[~2014-02-03 18:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 21:26 Receive on same subvolume Matthew Lai
2014-02-03 13:18 ` Felix Blanke
2014-02-03 17:30 ` Chris Murphy
2014-02-03 18:19 ` Matthew Lai [this message]
2014-02-03 19:26 ` Chris Murphy
2014-02-03 22:53 ` Matthew Lai
2014-02-04 0:34 ` Chris Murphy
2014-02-04 1:06 ` Matthew Lai
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=52EFDDA6.2060907@matthewlai.ca \
--to=m@matthewlai.ca \
--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).