Re: Cycle of send/receive for backup/restore is incomplete...

[Robert White <rwhite@pobox.com>]

I am, then, quite confused...

On 04/23/2014 09:28 PM, Brendan Hide wrote:
> Replied inline:
> btrfs doesn't differentiate snapshots and subvolumes. They're the same
> first-class citizen. A snapshot is a subvolume that just happens to have
> some data (automagically/naturally) deduplicated with another subvolume.

What then is the -s for in

btrfs subvolume list -s <mount point>

Clearly some information of bias and status exists or the option and its 
functional behavior wouldn't exist.

I understand the use of -p for doing diffs, but here's the thing...

mount /dev/sda /drivea
mount /dev/sdb /driveb

btrfs subvolume create /drivea/Base
btrfs subvolume snapshot -r /drivea/Base /drivea/Base_BACKUP

btrfs subvolume list -a /drivea
[blah blah blah] Base
[blah blah blah] Base_BACKUP

* skipping the network and delta-T nonsense as irrelevant
btrfs send /drivea/Base_BACKUP | btrfs receive /driveb/

*No way to make /driveb/Base_BACKUP _not_ end up read only
*So make a writeable snapshot

btrfs subvolume snapshot /driveb/Base_BACKUP /driveb/Base

btrfs subvolume list -a /driveb
[blah blah blah] Base_BACKUP
[blah blah blah] Base

**** Confusing and/or problematic bit:
btrfs subvolume list -s /drivea
[blah blah blah] Base_BACKUP

btrfs subvolume list -s /driveb
[blah blah blah] Base

So if I want to, say, write a backup script that rotates through the 
subvolumes to rotor backups, the restored drive (driveb in this example) 
automatically fails. There is no apparent way to coerce the relationship 
such that both drives end up with "Base" being the writable base and 
"Base_BACKUP" be the read-only snapshot returned when doing list -s.

So the systems are "the same" but they aren't really the same according 
to this clearly visible symptom.

As such various automations that one might right for an original system 
could then choke and die after restoration from this backup. Either that 
or you have to use /bin/cp (or similar) and lose the backup history when 
you restore.

Its a surprise waiting to happen. It surprised me.

It's _impossible_ to strip Base of it's subvolume status on /driveb. If 
you delete the Base_BACKUP element so that Base is the only thing on the 
drive, it's still a shapshot according to -s. What does this status even 
mean if it's as meaningless as it seems.

That seems like a second surprise.

---

Is this a common case? It could easily be if you use NAS or movable USB 
to do your backups and restore-or-media-migration operations.

Are we sure it doesn't matter? I find it problematic but fixable in 
concept. I've got no information whether the internal parentage 
relationship could be reversed so that the before and after of the 
subvolume list -s result are the same.

No I'm not looking for byte-level identical status, I know that's 
ridiculous.

I want semantically identical status.

My experience with list -s says I'm not getting semantically identical 
status after the fact and I have no clear way to coerce it.

====

Why it matters...

If I am doing monthly and weekly archiving I don't want to interrupt the 
rolling archive(s) if I end up having to do a restore. I don't want to 
create a catastrophe point or an interrupting epoch in the archive history.

It sounds like it doesn't matter once you know not to use the -s status 
for anything...