[Box Backup-dev] Re: Box Backup 0.20 redesign

[Ben Summers]

On Sat, 13 Jan 2007 14:10:38 +0000 Martin Ebourne wrote:
> On Sat, 2007-01-13 at 13:31 +0000, Ben Summers wrote:
> > This also simplifies the code and makes the crypto easier to audit;
> > as there is one central place a block is encrypted and 'signed'. So
> > we get much of strong crypto I want for free.
>
> First quick read, looks good. One thing I would like to be able to to
> eventually is have different files having different backup frequencies
> over time (using a heuristic probably). ie. A frequently changing file
> has lots of recent backups and progressively more infrequent backups
> over a longer period.
>
> You can't just apply this policy at the snapshot level because a
> snapshot might have a crucial backup of a file that changes only  
> once a
> year.

I don't think I was clear in my description.

When you start a new snapshot, you start with the file system as it  
stands from the previous snapshot. So this will contain your  
infrequent file. You might not have uploaded it this time even if it  
had changed, but you will get something. Because essentially these  
snapshots are stored as diffs, this copy costs nothing.

When you delete a file, you tell the server to delete the blocks it  
used. To make things simplier, we could not bother keeping track of  
free blocks and just add them at the end.


> I think we can still achieve this with your plan by editing past
> snapshots. This could conceivably leak a bit of info, although I'm not
> sure it would be of any use. Maybe we could merge the old snapshots
> which might help.

Just as we do with diffs on the server right now, reverse the  
direction of the change (as a snapshot is essentially a diff) and  
store a chain backwards.

>
> The other thing I'd like is for everything to be managed from the
> client, except for the hard limit which is all the server should do or
> enforce. All other policy should be client based. This plan fits well
> with that which I like.

Indeed.

>
> > I wonder if we could make a server which never needs to be upgraded?
> > That would solve the upgrade cycle hassles.
>
> No, but we could probably end up with a much simpler protocol which
> reduced the frequency of said upgrades somewhat.

That would be nice. The 0.09 -> 0.10 incompatibility was the right  
decision, but it didn't half annoy people.

Ben