From: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
To: "Jakob Schürz" <wertstoffe@nurfuerspam.de>, linux-btrfs@vger.kernel.org
Subject: Re: send snapshot from snapshot incremental
Date: Sun, 26 Mar 2017 00:31:27 +0100 [thread overview]
Message-ID: <b45f37ec-b8a4-64a0-9bdf-90f68376f0ce@mendix.com> (raw)
In-Reply-To: <p18jqd-a0m.ln1@aldebaran.xundeenergie.at>
Hi Jakob,
On 03/25/2017 11:37 PM, Jakob Schürz wrote:
> Hi there!
>
> I asked one or two years ago for the ability of btrfs to use btrfs
> send|receive with a parent-subvolume from a snapshot from a snapshot.
>
> The thing is, if i take a snapshot from my system, transfer it with
> btrfs send|receive to an external HD on USB-Port, make some changes to
> my system, which destroy my whole system, i can boot in the former taken
> snapshot and work from there, as if nothing happened.
>
> This part works.
>
> BUT if i take a snapshot from the system, and want to transfer it to the
> external HD, i can not set a parent subvolume, because there isn't any.
>
> The problem was on my last question, there are missing
> tansactional-numbers or something similar... I'm not a programmer, but i
> use btrfs very extensive and wrote a fancy python-script and a
> gnome-shell-extension and a fuse-filesystem to do enhanced and
> userfriendly snapshots an backups with btrfs - also for non-programmer
> users... something similar userfriendly as time-machine for apple does.
>
> And one missing feature is the described problem above... booting into
> an older snapshot and transfer a snapshot from this one lead to a full
> transfer - even if there is a transferred snapshot on the external HD.
>
> I hope, i described my problem understandable...
Yes, if you make a writable snapshot, and then start creating a readonly
snapshot for send/receive from that, you actually start another
"timeline" in which the parent relationship for the snapshots is
replaced by the ID of the new writable one.
Send/receive also has a clone option, which lets you specify any other
subvolume that is present on the local and the remote system as well,
using the -c option. I'd recommend playing around and testing that
option, to see if, for the first send, you can refer to the latest
available snapshot of the previous "timeline". When getting this right,
it should prevent sending all data that was already present in the old
snapshot.
HTH,
--
Hans van Kranenburg
next prev parent reply other threads:[~2017-03-25 23:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-25 22:37 send snapshot from snapshot incremental Jakob Schürz
2017-03-25 23:31 ` Hans van Kranenburg [this message]
2017-03-26 20:07 ` Peter Grandi
2017-03-28 22:01 ` Jakob Schürz
2017-03-28 22:40 ` J. Hart
2017-03-28 22:51 ` Hugo Mills
2017-03-29 9:41 ` Henk Slager
2017-03-29 12:11 ` Andrei Borzenkov
2017-03-29 12:24 ` Giuseppe Della Bianca
2017-04-13 1:14 ` Jakob Schürz
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=b45f37ec-b8a4-64a0-9bdf-90f68376f0ce@mendix.com \
--to=hans.van.kranenburg@mendix.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wertstoffe@nurfuerspam.de \
/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).