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

[Martin Ebourne]

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.

>> 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.

>> 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.

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.

> 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.

> 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?
All I can think of is to store the backed up data at a different place in
the filesystem. 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, 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.

Cheers,

Martin.