* Re: exact nature of send/receive problems?
2014-08-17 12:47 exact nature of send/receive problems? Shriramana Sharma
@ 2014-08-19 5:48 ` Duncan
0 siblings, 0 replies; 2+ messages in thread
From: Duncan @ 2014-08-19 5:48 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 2+ messages in thread