[Box Backup] Backup the backup

[Chris Wilson]

Hi Ben,

On Tue, 31 Oct 2006, Ben Summers wrote:

>>  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.

In this case I was proposing that the secondary server (S) should have 
all the accounts of all the primary servers that sync to it. So the client 
could continue to have the same configuration apart from perhaps changing 
the StoreHostname. Can you think of a reason why that wouldn't work?

>>  If it's reconfigured to change the StoreHostname, then it would 
>>  discard cached data, right?
>
> No.

What cached data is not discarded in that case? I thought that everything 
which is archived by the serialisation code (such as directory structures 
and the client store marker) would be discarded if the config is changed, 
or if serialisation is disabled, when the client process (bbackupd) is 
restarted? Is there anything else? Inode mapping databases don't need o be 
discarded, do they?

>>  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?

When is it updated now? It seems to be when 
BackupClientContext::CloseAnyOpenConnection is called, which happens at 
the end of a successful backup run and also if an exception is thrown 
during the connection which doesn't break the protocol.

>>  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 
> bbstoreaccounts?

How would that help when the client doesn't decide to contact the store?

Cheers, Chris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |