[Box Backup] Backup the backup

[E.W. Peter Jalajas]

This is an interesting idea, changing bbackupd.conf periodically to
make bbackupd do different things at, say, different times of the day. 
Is that what you guys are talking about?  Are you maybe talking about
an OS script that copies different versions of bbackupd.conf (say,
bbackupd1.conf and bbackupd2.conf) to bbackupd.conf on some sort of
appropriate schedule for one's use?  Diffs between bbackupd1.conf and
bbackuopd2.conf could be store server name/ip, key filenames,
BackupLocations list, for example.  Does that make any sense?  Is this
a solution in search of a problem? Or is this fatally flawed in some
way?


--- Ben Summers <ben@fluffy.co.uk> wrote:

> 
> 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?
> 
> No.
> 
> >
> > 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  
> bbstoreaccounts?
> 
> Ben
> 
> 
> 
> 
> 
> _______________________________________________
> boxbackup mailing list
> boxbackup@fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup
> 
> 
> 
>