[Box Backup-dev] Future work

[Ben Summers]

On 25 Feb 2006, at 19:02, Chris Wilson wrote:

> Hi Ben,
>
>> I'd prefer it if people choose the bits they wanted to do. I agree  
>> with Martin; this is about doing stuff we want to do.
>
> Well, I want Box to be successful and to meet people's needs,  
> because that in turn will make Boxi successful and important, and  
> make me rich and famous </dream>.

Interesting plan. :-)

>
>> The raidfile modifications are suitable, but not very "sexy" and  
>> may not be to your taste. But it is highly self-contained. I think  
>> there's still some advantage in having them. RAID hardware isn't  
>> well supported on the *BSDs (slight issues such as not reporting  
>> disc failures!), raidframe is annoying to set up. But perhaps most  
>> interestingly, with a bit of extra work it would allow us to RAID  
>> the entire machine, not just the discs, building resilient  
>> clusters of three servers.
>
> I'm not sure about raidfile. I have a feeling that hardware and OS- 
> level RAID is a better way to go in the long run, since it benefits  
> applications other than Box. I don't use it myself, and I might  
> feel that my time was better spent making OpenBSD's software raid  
> better. But if there is a geenral consensus that raidfile is useful  
> and worth doing, then I'll do it.

I personally am wondering whether it might be better to drop this  
feature. Maybe we should do a quick poll on the main list to see who  
uses it, and who would be upset if it went away?

>
>> On the other hand, we could really do with a nice GUI based front  
>> end, so why not continue making Boxi wonderful?
>
> I'd love to do that, but unless Box works well - really well -  
> there's no point. The single most important feature for me, out of  
> the proposals for 0.20, would be snapshots, but there's no way I  
> can do that myself, or that you would accept the resulting code if  
> I tried.

Yes, the snapshots is the most important thing. You sort of could do  
it with clever algorithms in the existing store, but it would be  
nasty. Also, the existing housekeeping stuff can fail. So it all  
needs changing.

>
>> It would be useful if you wrote some notes about your idea GUI  
>> integration features on the wiki before you leave. I would really  
>> like to leave the daemon doing it's stuff, and the GUI just  
>> connecting over a local socket to control it. Perhaps even making  
>> a brestored which handles the actual talking to the server.
>
> The problem I have with the separate process is the number of  
> variables. There can be so many more reasons why bbackupd.exe won't  
> start or won't talk to Boxi over the command socket, that it's very  
> difficult for users to diagnose and fix the problem. My idea was to  
> offer both options - a quick way to do a full backup and see the  
> status, and a way to manage and control the background service over  
> the command socket.

Shouldn't we improve bbackupd to give better feedback in a way that  
the GUI can pick up? That benefits command line users as well.


>
>> Have you considered having multiple users sharing the same store  
>> when a whole machine is being backed up?
>
> Sorry, I'm not sure what you mean here. Is it multiple bbackupds  
> (boxes) sharing a single account, or multiple users (of a single  
> machine) having access to their own files on the remote store?
>
> The former is something that I would like to see support for, along  
> with multiple, selectable encryption keys per account, to allow  
> users to use a Box store as a secure place to store and exchange  
> files.

I think that sounds really scary and complex. Maybe a nice feature,  
but it can be achieved in other ways (multiple accounts!) and makes  
the code and the tests far more complex. I really think everything  
should be as simple as it possible could be, engineering the whole  
thing for reliability. We can't risk people's data.


> The latter sounds like a potential security risk, but if I start  
> getting requests from users to back up shared servers, I would  
> consider it.

Let's say you backup /home on a multi-user machine, in a single  
account. It'd be nice to allow each user GUI access to their own  
files. However, you can't do that because they can access other files.

The solution, as I see it, is a brestored which arbitrates access. So  
the GUI contacts brestored to talk to the client. It looks at the  
socket to see which user is connecting, and only allows them to see  
their files. And, as a bonus, only root needs to be able to read the  
key and certs files. And the GUI can be completely independent of all  
the protocol stuff too.

It might be that this is abstracting things too much, but it is what  
I had in mind when I originally designed the system -- a single lazy  
daemon which backed up files for an office of users and allowed them  
all access to the old versions through a nice GUI.

Ben