From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs send/receive for backup of subvolumes
Date: Thu, 7 May 2015 03:43:38 +0000 (UTC) [thread overview]
Message-ID: <pan$bd072$7354a39e$575b04ce$653d5c8a@cox.net> (raw)
In-Reply-To: loom.20150505T131847-769@post.gmane.org
sri posted on Tue, 05 May 2015 11:30:27 +0000 as excerpted:
> Hi
>
> My query speicific to incremental backup/recovery with btrfs
> send/receive option available for btrfs subvolume backups.
>
> say i have /b1/s1 subvolume and snapshot of s1 is /b1/snap1_s1
>
> I run btrfs send /b1/snap_s1 | btrfs receive /backup where /backup is my
> backup btrfs file system.
>
>
> Now I will take snapshot of s1 again ( after modifiying data in s1)
> which is /b1/snap2_s1
>
> Using btrfs send -p snap1_s1 snap2_s2 and destination as /backup I can
> send incremental to backup store.
>
> My question is is there a way I can have option recover files from
> /backup from incremental backup or full backup (i.e. from copy of
> snap2_s1 or snap1_s1)
>
> And I do not want to make 2 copies of 1 full and 1 incremetal backup
> since if full backup is 1Gb and if there is 0.6Gb change for
> incremental, I would like to backup only difference for incremental
> backup but still would able to get option to recover files from full or
> incremental from backedup subvolume.
>
> is there a way I can achieve this using current btrfs send/receive and
> other snapshot and tracking options?
>From a later post it looks like you probably figured this out on your
own. But in case you didn't and for others who may google this thread...
Disclaimer: While I'm a btrfs user and list regular, I'm not a btrfs dev,
and my own use-case doesn't involve send/receive, so while the following
is as I understand the functionality based on the wiki documentation and
previous list discussion, I've never used send/receive myself, so if
actual functionality appears to conflict with the below, consider me
wrong and go with actual functionality...
AFAIK, when you btrfs receive a send, btrfs creates a subvolume
duplicating the one being sent from the send side.
So in the scenario above, you should end up with two different snapshots
under /backup, one for s1 and one for s2. Due to the parent relationship
and the fact that btrfs is copy-on-write, where extents in s1 and s2
differ, the difference is sent (as a copy of the new extent along with
metadata describing its place in reference to the parent) and the
snapshots occupy the space used by both. Where they do NOT differ, there
is no difference to send, and the snapshots share the space, so while
either one can be accessed, they're actually referencing the same shared
extent and only that shared copy of that extent exists.
So as long as you keep both snapshots, you can access both, but given 1
GiB in snap_s1 and 0.6 GiB worth of changes between it and snap_s2, the
total space used by the two should still be only 1.6 GiB, even tho you
can access the full 1 GiB of either snapshot.
--
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:[~2015-05-07 3:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-05 11:30 btrfs send/receive for backup of subvolumes sri
2015-05-07 3:43 ` Duncan [this message]
2015-05-07 4:04 ` Paul Harvey
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$bd072$7354a39e$575b04ce$653d5c8a@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 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.