[Box Backup] BoxBackup Server Side Management Specs (Draft 0.01)

Ben Summers boxbackup@fluffy.co.uk
Fri, 24 Sep 2004 11:53:28 +0100


On 24 Sep 2004, at 00:16, Chris Wilson wrote:

> Hi all,
>
>> Account numbers are rather essential in the design, so will have to
>> stay there. There needs to be a translation layer at some point.
>
> That's a shame. I think that symbolic names would be much more client- 
> and
> admin-friendly than account numbers. But what do I know? Might I 
> enquire
> about the rationale for using account numbers in the first place?

My intention was for this to be used within a larger system which would 
automatically provision backup accounts as part of a larger account. As 
such, numbers are much easier to allocate and use.

The current code references accounts internally and in the protocol 
using 32 bit integers. Changing this would be rather annoying.

>
>> That's a good point. How housekeeping will know which account to trim
>> when the group goes over usage is an interesting question though.
>
> Another reason for the client to handle deletion of files, rather than 
> the
> server :-) I would say that the client knows best regarding its own 
> data.

Yes, but the server knows more about how space is to be managed on the 
server. My approach to this will be to implement the backup set 
feature, which will allow the client to tell the server about it's 
policy. For the client itself to delete files seems a bit inefficient, 
as it would all have to be done over a network connection.

>
>> If you have multiple independent backup servers, then running one
>> daemon on each could be considered beneficial.
>
> I would definitely agree with this. I would even go so far as to
> suggest it for a "backup farm" configuration, as opposed to one big
> central server with lots of NFS mounts or NAS.

This was my intention, for there to be lots of servers with each 
effectively independent. This gives more fault tolerance, and 
distributes the processor load over many machines.

>
> Having a central database would also aid fault tolerance across the 
> farm,
> by allowing the use of replication mechanisms to ensure that each 
> backup
> server has its own copy of all the critical client details, making the
> system more scalable and robust.

Yes, there would be local copies of the database.

>
> Would raidfile/RAID1 be a good way to distribute the backed-up data 
> itself
> between backup servers? Say every server was part of a pair, and 
> backed up
> its client data both to a local disk and to an NFS volume mounted from 
> its
> pair. Then if one server goes down, you can instruct (or DNAT) clients
> into logging into the other server, at which point their files are 
> still
> accessible through the local copy on that server?

See other email on this subject.

Ben