From: Cerem Cem ASLAN <ceremcem@ceremcem.net>
To: Gaurav Sanghavi <gaurav.ms5@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Expected Received UUID
Date: Tue, 31 Jul 2018 21:40:03 +0300 [thread overview]
Message-ID: <CAN4oSBdnvnfJRJHz5XzN-d+PY3Ap+cR22Ptu1RbPyJMggUPjog@mail.gmail.com> (raw)
In-Reply-To: <CANfewpG7XK5FD5Q_i27=0L9P6P-W-Zwwcu8CC2mCmO1s4AbTBQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]
Not an answer, but exactly same case:
https://unix.stackexchange.com/questions/377914/how-to-test-if-two-btrfs-snapshots-are-identical
2018-07-31 20:42 GMT+03:00 Gaurav Sanghavi <gaurav.ms5@gmail.com>:
> Hello everyone,
>
> While researching BTRFS for a project that involves backing up snapshots
> from device A to device B
> before consolidating backups from device B to device C, I noticed that
> received UUID on snapshot on
> device C is not the same as received UUID for the same snapshot on device
> B. Here are my steps:
>
> 1. Device A
> BTRFS version: v3.17
>
> btrfs su sn -r /home/test/snapshot1 /home/test/snaps/snapshot1
> btrfs su show /home/test/snaps/snapshot1
> Name: snapshot1
> uuid: b00e8ba1-5aaa-3641-9c4c-e168eee5c296
> Parent uuid: cb570dec-e9fd-1f40-99d2-2070c8ee2466
> Received UUID: ---
> Creation time: 2018-07-30 18:32:37
> Flags: readonly
>
> 2. Send to Device B
> btrfs send /home/test/snaps/snapshot1 | ssh <device b> 'btrfs receive
> /home/backups/'
>
> After send completes, on Device B
> BTRFS version: v4.7.3
> btrfs su show /home/backups/snapshot1
> Name: snapshot1
> UUID: 7c13d189-7fee-584e-ac90-e68cb0012f5c
> Parent UUID: a2314f7c-4b11-ed40-901f-f1acb5ebf802
> Received UUID: b00e8ba1-5aaa-3641-9c4c-e168eee5c296
> Creation time: 2018-07-30 18:42:37 -0700
> Flags: readonly
>
>
> 3. Send to Device C
> btrfs send /home/backups/snapshot1 | ssh <device c> 'btrfs receive
> /home/backups2/'
>
> After send completes, on Device C
> BTRFS version: v4.7.3
> btrfs su show /home/backups2/snapshot1
> Name: snapshot1
> UUID: 8a13aab5-8e44-2541-9082-bc583933b964
> Parent UUID: 54e9b4ff-46dc-534e-b70f-69eb7bb21028
> Received UUID: 7c13d189-7fee-584e-ac90-e68cb0012f5c
> Creation time: 2018-07-30 18:58:32 -0700
> Flags: readonly
>
> 1. I have gone through some of the archived emails and have noticed people
> mentioning that
> if received UUID is set, btrfs send propogates this 'received UUID'. But
> in above case,
> it's different for the same snapshot on all three devices. Is this the
> expected behavior ?
>
> 2. We want to be able to start backing up from Device A to C, in case B
> goes down or needs
> to be replaced. If received UUID is expected to differ for the snapshot on
> device B and C, incremental
> backups will not work from A to C without setting received UUID. I have
> seen python-btrfs
> mentioned in a couple of emails; but have anyone of you used it in a
> production environment ?
>
> This is my first post to this email. Please let me know if I am missing
> any details.
>
> Thanks,
> Gaurav
>
>
[-- Attachment #2: Type: text/html, Size: 5431 bytes --]
next prev parent reply other threads:[~2018-07-31 20:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-31 17:42 Expected Received UUID Gaurav Sanghavi
2018-07-31 18:40 ` Cerem Cem ASLAN [this message]
2018-07-31 23:37 ` Hans van Kranenburg
2018-08-01 18:12 ` Gaurav Sanghavi
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=CAN4oSBdnvnfJRJHz5XzN-d+PY3Ap+cR22Ptu1RbPyJMggUPjog@mail.gmail.com \
--to=ceremcem@ceremcem.net \
--cc=gaurav.ms5@gmail.com \
--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).