exact nature of send/receive problems?

exact nature of send/receive problems?

[Shriramana Sharma]

Hello. This is wrt this thread:
http://www.spinics.net/lists/linux-btrfs/msg36639.html

The OP of that thread had not clarified (IMO) what exactly he means by
"unreliability of btrfs send/receive". Is it only via ssh/network, or
even in the case of backup to local alternate (external) drive? What
exactly happens? Does it:

a) muck up existing data on the source,
b) or on the target,
c) or doesn't muck up any data but fails *silently* halfway,
d) or fails halfway and tells me it failed?

One of the important reasons I'm looking to use BTRFS is the backup
economy that send/receive promises. If this reason is going to be
affected seriously, then I'll return to BTRFS a year hence as was
suggested elsewhere...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: exact nature of send/receive problems?

[Duncan]

Shriramana Sharma posted on Sun, 17 Aug 2014 18:17:48 +0530 as excerpted:

> Hello. This is wrt this thread:
> http://www.spinics.net/lists/linux-btrfs/msg36639.html
> 
> The OP of that thread had not clarified (IMO) what exactly he means by
> "unreliability of btrfs send/receive". Is it only via ssh/network, or
> even in the case of backup to local alternate (external) drive? What
> exactly happens? Does it:
> 
> a) muck up existing data on the source,
> b) or on the target,
> c) or doesn't muck up any data but fails *silently* halfway,
> d) or fails halfway and tells me it failed?
> 
> One of the important reasons I'm looking to use BTRFS is the backup
> economy that send/receive promises. If this reason is going to be
> affected seriously, then I'll return to BTRFS a year hence as was
> suggested elsewhere...

AFAIK, if a send/receive completes successfully it should be entirely 
safe to rely on the received copy.

The problem is various corner-cases are still being found, that can 
suddenly start triggering errors even on systems where it has previously 
been reliably working for months.

As just one example of such a corner case that was fixed I think a kernel 
cycle or two ago now, if subdir B was originally nested within subdir A, 
but then the admin reversed things and subdir A ends up nested inside 
subdir B, the send/receive system couldn't cope with it.

Tho as I said that case was fixed, it's various generally more complex 
cases of that general sort of thing that they're still working on.

So basically what it comes down to is this.  While if a session completes 
successfully it should be reliable, just because you tested it and it 
worked, and it has been working fine for several months, the next time 
you try it it might fail, and you may or may not be able to fix that 
failure and get it working again.  So basically you have to be prepared 
to revert to rsync or something else for backups at any point, because 
you can never be sure that the last send/receive you successfully 
completed won't be the last one that works.

But as long as it works, it should be reliable.  If that's what you need 
for your usage and you can and are prepared to fall back to rsync or 
whatever should it be necessary, and you test it and find it does work 
for you at least right now, you should be good to go.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman