[Box Backup] Checking that bbackupd's are backing up?

[Per Thomsen]

On 9/15/04 2:02 AM, Ben Summers wrote:

>
> On 15 Sep 2004, at 07:46, Per Thomsen wrote:
>
>> I would like to build in some centralized tracking of all my clients, 
>> to make sure that they are running, and backing things up. This would 
>> allow me to hunt down any clients that were shut down, or failed to 
>> restart after a reboot...
>>
>> Rather than distributing software to all clients, I would like to be 
>> able to do this on the bbstored server. I've been thinking along the 
>> lines of log-parsing, but then I looked at the output of 
>> 'bbstoreaccounts info'. The first 10 digits of the 'Client Store 
>> Marker' looks remarkably like a time(2) return value. Would it be 
>> safe to assume that the time stamp denotes the last time a file was 
>> uploaded from the client?
>
>
> Unfortunately, no.
>
> This is quite apart from the fact that if bbackupd doesn't see 
> anything to upload, it won't even contact the server.

Right. That's something that I'd have to deal with anyway. I am also 
considering writing a Nagios (www.nagios.org) service to check the 
'aliveness' of bbackupd on the client, and bbstored on the server. This 
would let me know if the bbackupd daemon was not running. That might be 
a better way to go, long term. Of course, that only helps if you're 
already running Nagios (not a system I'd set up to check for just one or 
two things).

>> If so, this would be a good (IMO) way to check that a client has 
>> backed *something* up in the last x seconds, and warning me if not.
>
>
> You're not the first who has asked about this feature!
>
>>
>> If people have other (and better) ways of doing this, I'd love to 
>> hear about them.
>
>
> This software grew out of a system I was building. Each client would 
> be running the backup software, as well as a generic error management 
> daemon. This would report back errors to a central system for 
> resolution. The servers were designed to just sit there and do their 
> stuff, and be fairly passive about things since most of the difficult 
> bits would be done by a generic system.
>
> This is not how it's actually being used in practice -- everyone wants 
> it to be nice and self-contained, which is a perfectly reasonable 
> thing to want.
>
> So I think that the server side management should be overhauled in the 
> next version. Issues I can think of are
>
> * Use names instead of account numbers
> * Monitoring of client activity and error status
> * Additional reporting of space used on the server
> * Perhaps an overhaul of the account database, which was always a bit 
> of a temporary measure until I got it reading the information from a 
> proper database.
> * Feeding the status into another system, perhaps piping status into a 
> script?
>
> I think the certificates are OK, unless anyone disagrees.
>
> I would like to get it right first time. Perhaps I could ask someone 
> to start a specification document, which we can all revise until we're 
> happy with it? I'd like it to be fairly detailed, specifying exactly 
> how the user will interact with the system, and then I'll get it 
> implemented in 0.09.

My time is limited, but I'd love to get the ball rolling. I should be 
able to pull something together by early next week. Any preferred formats?

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