linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Harvey <csirac2@gmail.com>
To: sri <toyours_sridhar@yahoo.co.in>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs send using with copied snapshot
Date: Thu, 7 May 2015 14:49:53 +1000	[thread overview]
Message-ID: <CAB3_QuJ3xkt+5bchszU7rOYMHsym151Lc49L=7Hwt08zqoYmsg@mail.gmail.com> (raw)
In-Reply-To: <loom.20150506T155438-123@post.gmane.org>

Disclaimer: I am just a btrfs user, not an expert.

AFAIU btrfs send currently does the incremental diff by comparing the
snapshot to send with the parent specified with "btrfs send -p", but
both of these must exist on a the same, single source filesystem.
AFAIK you cannot make it examine some other btrfs filesystem as part
of this process, that would require some knowledge of, and thus
bi-directional communication with the receiving filesystem (i.e.
reinventing rsync). This would break the "btrfs send | btrfs receive"
idiom which is a one-way, "zero-knowledge" flow of data (and trivially
allows sending/receiving over ssh and other network protocols to
remote hosts, which is a use-case that your desired example cannot
easily work with).

So in summary, for efficient transport and to make use of incremental
snapshots, you should not immediately delete all snapshots on the
source filesystem. You should instead keep at least whichever was the
last snapshot sent to the destination backup filesystem. And so in
this scenario your source filesystem will always have at least one old
snapshot, and during a btrfs send -p it will also have the new
(current) snapshot (which will then become the "old" snapshots after
it's sent).

I hope my explanation makes sense.

On 7 May 2015 at 00:01, sri <toyours_sridhar@yahoo.co.in> wrote:
> btrfs send has option -p to compare 2 snapshots and genereate output of
> diff and if btrfs receive is there it will get the diff.
>
> lets say i have done my first backup
> /b1/s1 is my subvolume and snap1_s1 is first snapshot
>
> ran command:
>
> btrfse send /b1/snap1_s1 | btrfs receive /backup
>
>
> then I will get my backup /backup/snap1_s1
>
> next I have created 2nd snapshot /b1/snap2_s1
>
> why cannot i do below
>
> btrfs send -p /backup/snap1_s1 /b1/snap2_s1 |btrfs receive /backup
>
> both sanp1_s1 and snap2_s2 are readonly
>
> why there is a restriction of all snapshots should be under same root?
> can't I get the diff of copied snapshot i.e /backup/snap1_s1 (never
> changed) to new snapshot /b1/snap2_s1 ??
>
> My case, i may not always keep previous snapshot but i have copied to
> backup using the snapshot.
>
> In this case is there a way to backup only incrementals using backedup
> snapshot subvolume ?
>
> --
> 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

  reply	other threads:[~2015-05-07  4:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-06 14:01 btrfs send using with copied snapshot sri
2015-05-07  4:49 ` Paul Harvey [this message]
2015-05-07  4:59 ` Duncan

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='CAB3_QuJ3xkt+5bchszU7rOYMHsym151Lc49L=7Hwt08zqoYmsg@mail.gmail.com' \
    --to=csirac2@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=toyours_sridhar@yahoo.co.in \
    /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).