Re: btrfs send reproducibly fails for a specific subvolume after sending 15 GiB, scrub reports no errors

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

On 2015-11-24 15:50, Christoph Anton Mitterer wrote:
> On Tue, 2015-11-24 at 15:44 -0500, Austin S Hemmelgarn wrote:
>> I would say it's currently usable for one-shot stuff, but probably
>> not
>> reliably useable for automated things without some kind of
>> administrative oversight.  In theory, it wouldn't be hard to write a
>> script to automate fixing this particular issue when send encounters
>> it,
>> but that has it's own issues (you have to either toggle the snapshot
>> writable temporarily, or modify the source and re-snapshot).
>
> Well AFAIU, *this* very issue is at least something that bails out
> loudly with an error... I rather worry about cases where send/receive
> just exits without any error (status or message) and still didn't
> manage to correctly copy everything.
>
> The case that I had was that I incrementally send/received (with -p)
> backups to another disk.
> At some point in time I removed one of the older snapshots on that
> backup disk... and then had fs errors... as if the data would have been
> gone.. :(
>
I had tried using send/receive once with -p, but had numerous issues. 
The incrementals I've been doing have used -c instead, and I hadn't had 
any issues with data loss with that.  The issue outlined here was only a 
small part of why I stopped using it for backups.  The main reason was 
to provide better consistency between my local copies and what I upload 
to S3/Dropbox, meaning I only have to test one back up image per 
filesystem backed-up, instead of two.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]