[Box Backup] Backup the backup
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