[Date Prev][Date Next]
Re: Textual LDIF backup strategies for busy LDAP clusters
--On Friday, June 25, 2010 9:58 AM +1000 Nick Urbanik
On 23/06/10 21:46 -0700, Quanah Gibson-Mount wrote:
--On Thursday, June 24, 2010 12:19 PM +1000 Nick Urbanik
our old backup system for our LDAP clusters using slurpd is as
Just use slapcat.
# du -sh /var/lib/ldap
Slapcatting this lot every 15 minutes is likely to make a machine less
capable of doing other work.
Slapcat doesn't take a lot of resources, in my experience, and the
generated LDIF is often significantly smaller than the actual database
size. In fact I don't think I've ever seen an LDIF that's larger than the
DB. Note that the database has files for any number of things (DB
environment, indices, etc). Which is part of why there is no exact
correlation between slapcat'd LDIF and the size of the DB directory.
auditlog is not appropriate.
Please can you explain why this is so?
Auditlog is a poorly written overlay that hopefully will be deleted in the
future. It kills perf, and in general is not recommended for use. If you
want a record of changes, I suggest you look at the accesslog overlay.
Do you think we are wrong now to be using the replogfile to achieve
what is in effect an incremental textual backup every fifteen minutes?
I would suggest you have multiple replicas, thus being able to restore any
given server from any of the other existing replicas. If you have a
disaster that wipes out every replica, you're in a world of hurt as it is.
Although I've used slapcat's for DR purposes, I've never needed it, as I
simply used one of my other servers to restore a lost database.
One of the advantages of syncrepl (Although I use and prefer
delta-syncrepl, since syncrepl has not proven reliable in my experience) is
that it can "catch up" from any given point with the data from an LDIF file
or a copy of another replica's DB, if it is behind the master.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration