[Box Backup] Suggested change in behaviour

[Ben Summers]

On 20 Sep 2004, at 16:13, Adrian wrote:

>
>> I agree about the e-mail though. And I think that the tag feature 
>> could
>> help this problem. Suppose that you setup the client so that it tags 
>> the
>> store with the date (200X-XX-XX) at the end of each day. Right after 
>> you
>> notice the death of your drive, you flag today's tag as read-only.
> Herehousekeeping
>> the e-mail could remind you that something weird is happening.
>>
>
> I think that Pascal may be on to something here.  Perhaps an added 
> feature
> of bbackupquery could be to set the "restore date".  For example:  
> Today
> is Monday.  I discover that something bad happened to my data on 
> Saturday
> (file modified, accidentally deleted, drive crash, etc).  I set the
> restore date in bbackupquery to Friday, and restore the affected file,
> directory, or mount point.  Bbackupquery ignores changes to the data 
> that
> occured after Friday, and restores things to the way they were on 
> Friday.
> Problem solved.

This is exactly what I'm planning to do.

>
> I think that as it stands, all of the data is there to do this.  
> Between
> old versions and deleted versions, I should be able to go back to any
> date, until the houskeeping function starts really deleting files on 
> the
> server.

You're right, all the data is there. But it's the housekeeping which 
complicates this. Firstly, it could delete objects, which means you 
don't know whether or not what you're restoring is correct. Secondly, 
if you have bbackupd working in lazy mode, it could sub-optimally 
delete things. Also some of the flags (like "this item is deleted") 
need to be modified to be time based, rather than absolute.

So there needs to be some tracking code to tag files, and to record 
when a tagged set becomes incomplete through housekeeping. This is not 
trivial to do well.

>
> The server would have to keep track of how far back it could go (to 
> report
> to bbackupquery).  As it does the housekeeping, it would need to 
> determine
> the earliest date for which it has a complete backup set (And perhaps
> adjust its deletion logic a little to optimize?).  More server space 
> would
> allow the client to go further back in time.
>
> Does this make sense?

Absolutely. I just need the time to implement it.

This is, of course, the correct solution to my problem this morning. 
But I'm just wondering if there's a simple tweek which would catch 
things most of the time. If a small bit of code would help people when 
something has failed, when they might be thinking more about getting 
the server back up than the backup system, then it would be worth it?

The bit about the quota file does complicate matters, although if 
nothing was mounted there it wouldn't have been created. Some more 
thought required. But it does suggest that I should think through 
exactly how things will behave when things go wrong, and make sure 
nothing bad happens even if the sysadmin isn't paying full attention.

Thanks for all the thoughts.

Ben