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

[Ben Summers]

On 22 Sep 2004, at 11:36, Martin Ebourne wrote:

> Ben Summers <ben@fluffy.co.uk> wrote:
>> Will these names replace the account numbers on the client side too? 
>> So
>> instead of getting an account number from your administrator before
>> configuring and generating the certificate, you would just use the
>> symbolic name of your host?
>
> I think the complete removal of account numbers in favour of names 
> would be a
> definite usability enhancement. The default of using client hostname 
> as the
> backup name makes sense and is what I'd do.
>
> Regarding upgradability/backwards compatability, rather than operating 
> with
> names and numbers I'd simply relax restrictions on the number to make 
> it a
> name. Thus upgraded systems would carry on functioning with their 
> 'number'
> and admins would be free to change the number to a more suitable name 
> at
> their leisure.

Account numbers are rather essential in the design, so will have to 
stay there. There needs to be a translation layer at some point.

>
>>> 2. Client groups.
>
> One of the features of a group I think would be most useful, but I 
> didn't see
> from the original post, would be the ability to set disk usage 
> groupwide.
> ie. You could still set on an individual client basis, but you could 
> also
> set a (presumably more restrictive) groupwide usage too, which would 
> apply
> to all of those clients in aggregate.

That's a good point. How housekeeping will know which account to trim 
when the group goes over usage is an interesting question though.

>
>>> When a bbackup client daemon dies unexpectedly, the bbstored server 
>>> will
>>> notice that there is no heart beat message from the client after
>>> approximately 2 x the heart beat interval. It will then notify backup
>>> administrators using the NotifySysAdmin.sh mechanism, or one very 
>>> much
>>> like it.
>
> Whatever the mechanism is, it would be useful to have some way to send 
> the
> email to a different address depending on the group.
>
> Also, I don't see here what happens when bbstored dies. If all the 
> state for
> the clients is held in memory, that will be lost. I guess it would 
> need to
> be persisted to disk. If a database was in use that would seem to be 
> the
> right place.

Yes.

>
> As to 'database', I always seem to end up running a SQL database on my
> machines, but I don't think that should be a requirement. If a 'real'
> database is decided upon, the way to go could be SQLite - or even 
> better if
> you use libdbi that abstracts the SQL databases quite nicely and lets 
> you
> use any of them, including SQLite (which can be built in). 
> Alternatively
> there's always db4 at a push.

Absolutely, a generic interface would be the way to go. SQLite for 
small installations, a database, perhaps on another machine, for larger 
ones.

>
>> The current implementation will connect to the server every so many
>> seconds (the UpdateStoreInterval) in lazy mode, or whenever the sync 
>> is
>> started in snapshot mode. If there was an option to always connect to
>> the server, instead of just when there was data to update, and sent in
>> the additional information above, would this be a suitable mechanism?
>
> That would sound reasonable, and reduced complexity is always a good 
> aim.

I'm glad you agree.

>
>> And of course, make the database so you can store information for many
>> bbstored daemons in it.
>
> Are there situations where it is beneficial to run multiple bbstored 
> daemons?

If you have multiple independent backup servers, then running one 
daemon on each could be considered beneficial.

> All I can think of is to store the backed up data at a different place 
> in
> the filesystem.

You can set multiple raidfile sets for that.

>  In which case this sounds like the sort of thing that should
> be settable on a groupwide basis, and then one daemon could suffice.
>
> One final point, I would like to be able to control this 'watchdog'
> functionality from the client end if possible,

Whether or not it connects on every scan will be set in the client 
configuration file.

>  and the same for individual
> client diskspace usage within a group. You quite possibly don't have 
> shell
> access to the server, but might need to change this stuff. On the other
> hand, the box owner is likely to want to set the limits on the group 
> for
> obvious reasons.

You could always have a little web interface to change the settings on 
the server. I suspect that splitting functionality between the client 
and server too much would just complicate things.

Ben