[Box Backup] Win32 native client service bbackupd.conf

Ben Summers boxbackup@fluffy.co.uk
Thu, 29 Jun 2006 09:24:39 +0100

On 29 Jun 2006, at 02:37, Gary wrote:

> Chris,
>> This is a very good idea. Please add it to the Feature Requests page?
> Ok, I added the following at the bottom of the list:
> "Allow for end-to-end server data verification with bbackupquery  
> compare -aq (quick compare),
> without having to re-download all data (as is the case with  
> bbackupquery compare -a). The feature
> would require bbstored (server) to read factual data blocks off its  
> storage media and compare
> those data blocks against checksums both stored locally and sent up  
> from bbackupquery (client).
> The only undetected failure condition in such a scenario would  
> require both a server data block
> and a server checksum getting corrupted in such a way as to match a  
> client checksum - the chances
> of this are beyond astronomical."
> I started working on this a bit, but I will have to go through a  
> lot of code to figure out what
> happens where. I guess the crucial question is whether server  
> checksums can be related to server
> data blocks without access to the original file - the paradigm  
> would not require storage of any
> additional information in the repository. However, if current  
> checksum scheme requires access to
> raw, unencrypted data, the client would have to send checksums up  
> during backup or during compare.
> The first option would be better, since an administrator would then  
> be able to completely verify
> store integrity without needing any client input.

To achieve this, you will need to keep a checksums for the uploaded  
data on the client.

The stored files are split into blocks, and each block is encrypted  
using a strong random initialisation vector (IV). This is to maintain  
an important cryptographic property, that if you encode the same data  
twice it will have different ciphertext.

So, to determine whether a checksum from the server is correct, you  
need to either record the checksums or IVs on the client, or send the  
key to the server for it to decrypt the data. The latter is  
unacceptable, and the former annoying.

Another thing to remember is that the server will reassemble blocks  
if the client sends "changes only" for a file. So you can't just  
record the checksum of the last file you sent.

I didn't really consider it worth the effort.

Have fun, and be careful.