Btrfs devel - Apr 2014 - Cycle of send/receive for backup/restore is incomplete...

So the backup/restore system described using snapshots is incomplete 
because the final restore is a copy operation. As such, the act of 
restoring from the backup will require restarting the entire backup 
cycle because the copy operation will scramble the metadata consanguinity.

The real choice is to restore by sending the snapshot back via send and 
receive so that all the UIDs and metadata continue to match up.

But there's no way to "promote" the final snapshot to a
non-snapshot
subvolume identical to the one made by the original btrfs subvolume 
create operation.

Consider a file system with __System as the default mount (e.g. btrfs 
subvolume create /__System). You make a snapshot (btrfs sub snap -r 
/__System /__System_BACKUP). Then you send the backup to another file 
system with send receive. Nothing new here.

The thing is, if you want to restore from that backup, you'd 
send/receive /__System_BACKUP to the new/restore drive. But that 
snapshot is _forced_ to be read only. So then your only choice is to 
make a writable snapshot called /__System. At this point you have a tiny 
problem, the three drives aren't really the same.

The __System and __System_BACKUP on the final drive are subvolumes of /, 
while on the original system / and /__System were full subvolumes.

It's dumb, it's a tiny difference, but it's annoying. There needs to
be
a way to promote /__System to a non-snapshot status.

If you look at the output of "btrfs subvolume list -s /" on the
various
drives it's not possible to end up with the exact same system as the 
original.

There needs to be either an option to btrfs subvolume create that takes 
a snapshot as an argument to base the new device on, or an option to 
receive that will make a read-write non-snapshot subvolume.

Ideally, from "HOST_A":

mkfs.btrfs /dev/sda  # main device
mount /dev/sda /drivea
cd /drivea
btrfs subvolume create __System
btrfs subvolume set-default __System
#//* use system with __System as root *//
mount -o subvol=/ /dev/sda /drivea
cd /drivea
btrfs subvolume snapshot -r __System __System_BACKUP

mkfs.btrfs /dev/sdb # some backup device (presumably shared here)
mount /dev/sdb /driveb
cd /driveb
btrfs subvolume create HOST_A # host specific region
cd HOST_A
btrfs send /drivea/__System_BACKUP | btrfs receive /driveb/HOST_A
# etc.

## Restoring drive.
mkfs.btrfs /dev/sdc
mount /dev/sdc /drivec
mount /dev/sdb /driveb
btrfs send /driveb/HOST_A/__System_BACKUP | btrfs receive /drivec

## What I've been doing is create a non read-only snapshot of
##   the backup snapshot. But this is now _not_ identical to the
##   original /drivea because __System is listed as a snapshot
##   not a subvolume.
cd /drivec
btrfs subvolume snapshot __System_BACKUP __System

## So Ideally I should instead be able to do
btrfs subvolume create -model /drivec/__System_BACKUP /drivec/__System

## Or I should have been able to do
btrfs send /driveb/HOST_A/__System_BACKUP |
   btrfs subvolume create --receive /drivec/__System

## Or a promote/populate option that takes the writable snapshot and
##   and rearranges its flags and the various connections to other
##   snapshots. e.g. properly handling __System_BACKUP et. al.
##   when doing something like:
btrfs subvolume promote __System


The real goal here is that the well designed system is going to use 
incremental backups. If there's a copy operation used then the whole 
HOST_A hierarchy would need to be recreated, which lowers the integrity 
of the whole backup cycle by interrupting the history.

Imagine if there is a (dated or numbered) history of snapshots, any copy 
based restore breaks it all.

ASIDE: A harder problem is when a snapshot is a child of the subvolume 
itself. e.g. "btrfs snapshot -r . BACKUP". Getting the contents of . 
back seems more or less impossible wihtout copying.
--
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