[Box Backup] Backup the backup

Ben Summers boxbackup@fluffy.co.uk
Tue, 31 Oct 2006 21:15:55 +0000

On 31 Oct 2006, at 21:06, Chris Wilson wrote:

> Hi Ben,
> On Tue, 31 Oct 2006, Ben Summers wrote:
>>>  The last part is a little insecure. Any of your customers could  
>>> set up an  impostor for another company's server, but they'd  
>>> still have to persuade  clients at the other company to connect  
>>> to their server instead of yours.
>> Are you sure? Clients and servers use different CAs, so you can't  
>> use a client cert to pretend to be a server.
> OK, I didn't know that, sorry. But I think my point is still valid.  
> With all the servers having certificates signed by the same CA, the  
> client will trust any of them equally, right?

Yes. But you can have different account numbers on different servers  
to constrain what can connect to what.

>> I don't see how two servers makes any difference anyway.
> Sorry, I don't understand what you meant by that.

Nothing magically changes when there are two servers.

>>>  Unless client A (which normally backs up to server B) backs up  
>>> to the  secondary server S one day, and then rsync from B  
>>> overwrites the newly  backed-up data on S.
>> Cached data on the client could be a problem. It's not necessarily  
>> going to detect it's using a different server.
> If it's reconfigured to change the StoreHostname, then it would  
> discard cached data, right?


> Also, if the secondary server S is not in sync with the primary  
> server B, then the client store markers will differ, so next time  
> the client tries to connect to the server, it will notice that and  
> discard the cached data, right?

Given the way the marker is updated, probably not. Perhaps it should  
be updated at the end of every connection?

> The only vulnerability that I can see is when NAT was used to  
> redirect from the old server (B) to the new one (S), rather than  
> reconfiguring the client to change its StoreHostname.
> In that case, the client might not detect that the store host had  
> changed, until it detects a local change and decides that it needed  
> to contact the server.
> So if B dies without syncing its latest changes to S, it will be a  
> while before A contacts S, discovers that the client store marker  
> is wrong, and resyncs everything.

Maybe we need to have a 'reset client store markers' option on