On Fri, Aug 22, 2014 at 3:35 AM, Duncan [off-list ref] wrote:

No claim to be a dev, btrfs or otherwise, here, but I believe in this
case you /are/ "being too paranoid."

Both btrfs send and receive only deal with data/metadata they know how to
deal with.  If it's corrupt in some way or if they don't understand it,
they don't send/write it, they fail.

IOW, if it works without error it's as guaranteed to be golden as these
things get.  The problem is that it doesn't always work without error in
the first place, sometimes it /does/ fail.  In that instance you can
always try again as the existing data/metadata shouldn't be damaged, but
if it keeps failing you may have to try something else, rsync, etc.

Well, my main use-case for rsync right now is btrfs bug hoses my
filesystem, so it would be nice to have a daily full backup on
something other than btrfs so that it is unlikely to suffer the same
problem at the same time.

Using btrfs send with that backup would certainly be more efficient,
but it would defeat the purpose of the backup, which is to not be
btrfs.  I am already using mirroring in the event of drive failure,
and offsite cloud backups of critical data in the event of a larger
catastrophe.  Btrfs eating my data is a somewhat likely failure mode
in the grand scheme of things, so I protect against it so that I can
still have fun playing with btrfs without losing sleep.

I've actually restored from it once.  I suspect that I could have
fixed my ENOSPC problem without resorting to that, but the usual FAQ
solutions didn't work and I was running short on time, and that
particular filesystem was only 64GB anyway so it was a fast restore
(and that is why this filesystem is prone to ENOSPC in the first
place).

Oh, and I'm using rsnapshot, so I also get the benefit of a few days
worth of backups - almost as good as snapper, though in reality
obviously not the same thing.

--
Rich