[Box Backup] windows binaries

[Ben Summers]

On 17 Jun 2004, at 22:44, Mikael Syska wrote:
> Mikael Syska wrote:
>> Chris Anderson wrote:
>>> On Jun 16, 2004, at 10:07 PM, Adrian wrote:
>>>
>>>> The first experimental Windows version is ready to go.  Please read 
>>>> the
>>>> included README.txt file for setup instructions.  All of the files 
>>>> are
>>>> simply placed in the same folder, so there is no "install" to speak 
>>>> of.
>>>> Also to remove it, simply delete the folder.
>>>
>>> Thanks much Adrian!
>>>
>>> I just got the software installed and running on a Windows 2000 
>>> server and everything appears to be going okay. (I have 10GB to push 
>>> so I won't know for a while if everything is perfect).
>>>
>>> I'll try Windows 2003 server later this weekend.
>>
>> Installed on Windows XP and works like a charm except for one thing
>>
>> It transfers data very slow, like 200 kbyte/sec, and there are 100 
>> Mbit  between the BB Server and the BB Client. The BB process only 
>> uses a few procent of the cpu, on both ends, any ideas?
>>
>
> now that it have run for some time, I get some messeges on the server, 
> dont know if they mean anything speciel, cause it backup data and I 
> can restore....
>
> ------------------------------
> lightning# Jun 17 23:38:13 lightning bbackupd[9524]: SSL err during 
> Connect: error:0407006A:rsa 
> routines:RSA_padding_check_PKCS1_type_1:block type is not 01
> Jun 17 23:38:13 lightning bbackupd[9524]: SSL err during Connect: 
> error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type 
> is not 01
> Jun 17 23:38:13 lightning bbstored[4938]: SSL err during Accept: 
> error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error
> Jun 17 23:38:13 lightning bbstored[4938]: SSL err during Accept: 
> error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error

[snip]

This looks like data is being corrupted between the client and server. 
I'm not entirely sure what to make of that -- I haven't actually tested 
it on Cygwin.

>
> it still transfers data very slow.

Are you backing up lots of small files? The transfer rate may be 
reasonable for that, possibly. The protocol is not designed to be an 
efficient protocol for transferring large amounts of small files really 
quickly -- after each file there is a bit of processing that needs to 
be done on the server. While this is happening, the client waits for a 
reply, and then only sends the next one.

However, for large files you should see it saturating the network.

I will be doing work on making initial backups easier in the future 
where the client creates a massive initial archive, so really the 
efficiency of the protocol won't matter. And indeed, it's desirable for 
it not to be completely efficient, as you want to use your internet 
connection for other things while the backup is happening.

But it does seem a little on the slow side, especially on a local 
network. How did you measure this speed?

Ben