>> On Wed, 4 Apr 2007 10:28:25 -0500, Bill Kelly <KELLYWH AT AUBURN DOT EDU>
> We have a bunch of people who don't like/don't want to run scheduled
> backups (don't ask me...we're a university), and who just do
> occasional backups of C: drives and such via the GUI. These
> people's filespaces *always* show null backup_start and backup_end
> dates. Richard, I suspect this is what's happening occasionally at
> your site.
> These null date fields are a real pain for me; there's no good way
> to determine whether such filespaces have been 'abandoned' (e.g.,
> old PC goes away, new PC comes in and filespace name changes) or
Amen! preach it, brother.
At UF we have the same situation. (I try not to think of it as a
"problem", it's just a style of work. Which seems nuts. To me. )
My response to this has been two-fold: customized tolerances for
backup ages, and daily reporting.
1) I have a big XML config file, which includes on the server level,
stuff like: [ massively excerpted ]
<default reportTo="open-systems-l AT lists.ufl DOT edu"/>
<domain name="flr" reportTo="yadda AT yadda DOT org"/>
<node name="jerryw1" reportTo="foo AT bar DOT baz"/>
<node name="libsrvr" tolerance="7"/>
<node name="old-wallaby.nerdc.ufl.edu" tolerance="12800"/>
<node name="nslabun1.nslabs.ufl.edu" tolerance="30000"/>
<filespace name="major.cns.ufl.edu:/boot" tolerance="30"/>
This permits me to establish tolerances on a granularity as tight as
per-filespace. Things that haven't had a normal incremental complete
in that amount of time are deemed "Exceptions".
2) I can send complaints about e.g. libsrvr to the admin of its'
(node, domain, whatever). That way -they- see the complaint, and I
don't have to. Though, being neurotic, I often skim my cc of
everyone else's complaint mail.
I find that this makes keeping up with it -their- problem, and the
daily mail simplifies eventual unhappy conversations about stuff not
being there when they reach for it.
- Allen S. Rout