[Box Backup] Feature request - for lousy connections

[Florian Eyben]

Hi Chris,

Chris Wilson schrieb:
> Hi Florian,
>
> On Tue, 30 Mar 2010, Florian Eyben wrote:
>>>> I have been using the StoreObjectInfoFile setting in the past [...] 
>>>> and was wondering how that fits in here.
>>>
>>> I think it only makes a difference if bbackupd is shut down and 
>>> restarted, as it saves a copy on disk of state that is normally only 
>>> kept in memory. If the connection goes down but bbackupd is not 
>>> stopped, it should make no difference.
>>>
>> Ah, ok. Now, this would be really nice to have to save the state, 
>> when the connection goes down or any other error occurs. What do you 
>> think? Is this hard to implement?
>
> I think there is a misunderstanding here. If you are not shutting down 
> Box Backup (and I think you are not) then this feature makes no 
> difference. In any case, it is implemented, so you can try it if you 
> like.
No, I am not shutting down box backup. My question was, if you think it 
is possible to save the state when the connection drops (i.e. save the 
last state before the transfer of the file or the action where the 
connection dropped). I mean, more or less, call the function that saves 
the state (currently when stopping the daemon), when an error occurs. If 
this is not possible, because maybe the state is corrupt in case of an 
error, it may help to be able to periodically save the state, lets say 
every 10 or 15 minutes. So in case of a lost connection you only loose 
the last 10 minutes, and you would ensure that eventually you back up 
all of your data and not skip the last directories in case of repeated 
dropped connections.

>
>> I would assume that resuming a 1,5GB transfer would also require a 
>> lot of matching, since the server data is encrypted and you cannot 
>> directly diff.
>
> Box Backup has a clever way of doing it that does work.
>
>> Either you encode, upload and compare, or you upload only hashes and 
>> compare them. Either way, it always involves encrypting 1,5GB... or 
>> am I wrong?
>
> Yes, you would have to encrypt 1.5 GB, and normally that's not a 
> problem compared to the time taken to upload it if you didn't. Perhaps 
> if you have a really slow CPU, that's not the case, but I'm not 
> particularly interested in supporting such devices.
>
Yes, I understand. As I said, large files are also not my top priority. 
If it were, I'd have a faster CPU and more disc space anyway.

Cheers,
Florian