slapcat daily cron job?

Nils Philippsen nphilipp at redhat.com
Fri Mar 4 19:55:23 UTC 2005


On Fri, 2005-03-04 at 11:44 -0600, Steven Pritchard wrote:
> On Fri, Mar 04, 2005 at 06:17:19PM +0100, Nils Philippsen wrote:
> > In the same vein you could argue that we should have nightly pg_dumpalls
> > etc. I'd say that backups should be left to the administrator instead.
> > Provide the scripts as examples of how to do a backup, but leave it as
> > that.
> 
> Except that, generally speaking, if any other database server blows
> up, the system still functions.  When openldap blows up, if you are
> using it for authentication, bad things happen.

Point taken, but: usually there is more important data in a database
than in an LDAP directory. If there is data loss in the former it tends
to cost serious money, in the latter it may be a mere nuisance. Not that
I want to downplay the effects of a damaged LDAP directory, but to be
consistent we would have to introduce automatic backups for everything:
databases, LDAP, file systems, mail spools, ... all the while everything
concerning backups is largely policy-ridden, i.e. some will want to
backup onto disk, some onto tape, some want this and some want that
backup program. In my eyes, backups are not a serious contender for the
"default works for 90%" award ;-).

> > If openldap tends to eat the directory, this needs to be fixed
> > rather than installing such a backup script by default (which is not
> > a real fix).
> 
> I don't think the two are mutually exclusive.
> 
> Again, I'm just using the example of rpm, which has a cron job that
> dumps to /var/log/rpmpkgs.  That's *really* helped me a couple of
> times now...

Yes, it does. But a real backup would help in this case as well, if not
better.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011




More information about the fedora-devel-list mailing list