<div dir="ltr">Hi Hans-Joachim,<div><br></div><div>If the file cannot be restored correctly on any client, then it seems that the file data is corrupt. Since individual blocks are encrypted separately, it seems that one block was probably corrupted before being encrypted, perhaps due to bad memory or a cosmic ray bit flip on the client being backed up. (It should not be possible that it was damaged after encryption, including on the server, as a different error would occur on decryption).</div><div><br></div><div>Do you have any old versions of this file on the store, and can they be restored successfully?</div><div><br></div><div>This should be detected by verifying (comparing) the backup on the original client, which is something that you should really be doing regularly to check the integrity of your backups. It would probably be useful to add a command to bbackupquery that decrypts the blocks and checks that they can be decompressed, without comparing to the current file data, as this would be easier on the box (less file I/O) and could be done on a different box (with the same key).</div><div><br></div><div>The Zlib manual says that it's possible to resync the compression and partially restore the file in such cases, or at least we could drop the encrypted block. The file would have errors, but in some cases some content could be recovered from it. In this case, if this is really a MySQL ISAM database file as it appears, it could probably be repaired by myisamchk with a few lost records.</div><div><br></div><div>You can delete the file from the server with the bbackupquery delete command, and try the restore again, and it should succeed this time (hopefully!).</div><div><br></div><div>Thanks, Chris.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, 30 Dec 2018 at 23:09, Hans-Joachim Baader <<a href="mailto:hjb@pro-linux.de">hjb@pro-linux.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Chris,<br>
<br>
> Very sorry to hear that you're having problems. I'm not aware of any<br>
> difference or incompatibility between 32-bit and 64-bit clients and<br>
> servers. I want to fix this bug, but will need your help to reproduce it.<br>
<br>
thank you.<br>
<br>
> This particular error can happen when the client encounters an error in a<br>
> previous operation, and tries to move onto the next file, but the protocol<br>
> is out of sync (the server is still sending file data, but the client tries<br>
> to interpret it as a reply to its next request, and aborts). Therefore it<br>
> would be useful to see the last few lines of the output, including any<br>
> error that occurred immediately before, or while restoring the previous<br>
> file. The server logs may also have some useful information, such as<br>
> warnings.<br>
> <br>
> How large is the file that failed on the server, in blocks? Can you restore<br>
> it on its own (without the other files)? Can you restore the file<br>
> immediately before, and then perform another protocol operation such as<br>
> listing files in a directory?<br>
<br>
After some tests, I must correct some of my statements. I can reproduce<br>
the problem with a single file, 26 MB long (maybe the size doesn't have<br>
anything to do with the problem). Contrary to what I said the behavior<br>
is the same on all 32 and 64 bit clients.<br>
<br>
A simple get command is sufficient to reproduce the error. It also happens<br>
when the restore command is used. On the server side I see the following<br>
in the log, and nothing else of interest:<br>
<br>
Dec 30 23:38:54 server bbstored client=0x00000016[28613]: WARNING: Exception thrown: ConnectionException(TLSWriteFailed) at lib/server/SocketStreamTLS.cpp(372)<br>
Dec 30 23:38:54 server bbstored client=0x00000016[28613]: NOTICE: Connection statistics for 0x00000016 (name=): IN=189 OUT=628976 NET_IN=-628787 TOTAL=629165<br>
Dec 30 23:38:54 server bbstored[28613]: ERROR: Error in child process, terminating connection: TLSWriteFailed (7/33)<br>
<br>
These entries only appear in the log after the client disconnects,<br>
this may be long after the error happens on the client.<br>
<br>
I straced the server and didn't see any error there. So the error<br>
seems to be produced on the client.<br>
<br>
The client says:<br>
<br>
query > get item.MYI<br>
WARNING: zlib error code = -3<br>
WARNING: Exception thrown: CompressException(TransformFailed) at ../../lib/compress/Compress.h(154)<br>
ERROR:   Failed to fetch file: Compress TransformFailed<br>
<br>
And after additional commands:<br>
<br>
query > ls<br>
WARNING: Exception thrown: ConnectionException(Conn_Protocol_ObjTooBig) at Protocol.cpp(219)<br>
ERROR:   Failed to list directory: Connection Protocol_ObjTooBig<br>
query > exit<br>
WARNING: Exception thrown: ConnectionException(Conn_Protocol_ObjTooBig) at Protocol.cpp(219)<br>
Exception: Connection Protocol_ObjTooBig (7/42)<br>
<br>
The same messages are in the syslog. I did a ltrace on the client and got:<br>
19104 SSL_read(0x55a6a0643d40, 0x55a6a067079f, 2129, 0xdbba0)                = 2129<br>
19104 SSL_get_error(0x55a6a0643d40, 2129, 0x55a6a0644410, 0)                 = 0<br>
19104 EVP_CIPHER_CTX_iv_length(0x55a69f0dcba0, 2129, 0x55a69f0dcd60, 8608)   = 16<br>
19104 EVP_CipherInit(0x55a69f0dcba0, 0, 0, 0x55a6a06707a0)                   = 1<br>
19104 EVP_CipherInit(0x55a69f0dcba0, 0, 0, 0)                                = 1<br>
19104 EVP_CIPHER_CTX_block_size(0x55a69f0dcba0, 2048, 16, 0)                 = 16<br>
19104 inflateInit_(0x7fffa6d0ba60, 0x55a69eeb90be, 112, 0)                   = 0<br>
19104 EVP_CIPHER_CTX_block_size(0x55a69f0dcba0, 0x7fffa6d0bf60, 2048, 0x55a6a06707b0) = 16<br>
19104 EVP_CipherUpdate(0x55a69f0dcba0, 0x7fffa6d0bf60, 0x7fffa6d0b55c, 0x55a6a06707b0) = 1<br>
19104 inflate(0x7fffa6d0ba60, 0, 0, 0)                                       = 0xfffffffd<br>
<br>
So, zlib has indeed a problem. What next? The data store on the server<br>
seems Ok, I checked that. I could test again with more verbose output.<br>
Or delete the file in the store to have it backed up again.<br>
<br>
Zlib is version 1.2.8 or 1.2.6.<br>
<br>
Regards,<br>
Hans-Joachim<br>
<br>
Hans-Joachim Baader - Pro-Linux.de<br>
Poppelfeld 9, D-76646 Bruchsal<br>
Geschäftsführer/Herausgeber * CEO/Editor<br>
Fon +49 07257-930142 * Mobil 0170-6500228<br>
-- <br>
Pro-Linux - Germany's largest volunteer Linux support site<br>
Support Pro-Linux: <a href="https://www.pro-linux.de/user/index50.html" rel="noreferrer" target="_blank">https://www.pro-linux.de/user/index50.html</a><br>
<a href="https://www.pro-linux.de/" rel="noreferrer" target="_blank">https://www.pro-linux.de/</a>    Public Key ID 2DBC923E3DDBDDEA<br>
</blockquote></div>