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

[Per Thomsen]

On 9/22/04 3:36 AM, 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.

In that regard, I think that when upgrading clients to use symbolic 
names, the number should stay, and be usable just as before. There 
doesn't seem to be any reason to remove it. If you've built up a system 
for managing your clients with the account numbers, I think you should 
still be able to use that.

However, if you're new to BB and install a new server, you won't even 
know that the numbers are there, and will simply just use the symbolic 
names.

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

I completely agree. I was trying to convey that, but I guess it wasn't 
clear. To me, the aggregate group usage is the most important aspect of 
the group feature. It enables the administrator to get good trending 
information on a group basis, to predict disk usage, etc.

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

Good idea...

>
> 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, the data must be on disk. Preferably in a database.

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

Or pgSQL or mySQL. I like the idea of an external database, so I can 
create my own reports, etc. from the data there.

>
>> 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.
>
Yes, I agree. No reason to create another way of connecting. Just simply 
always connect, if the client is configured to send heart beat messages.

Thanks,
Per

-- 
Per Reedtz Thomsen | The Reedtz Corporation | F: 209 883 4119
V: 209 883 4102    |   pthomsen@reedtz.com  | C: 415 425 4025
GPG ID: 1209784F   |  Yahoo! Chat: pthomsen | AIM: pthomsen