[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Textual LDIF backup strategies for busy LDAP clusters

--On Friday, June 25, 2010 9:58 AM +1000 Nick Urbanik <nick.urbanik@optusnet.com.au> wrote:

Dear Quanah,

On 23/06/10 21:46 -0700, Quanah Gibson-Mount wrote:
--On Thursday, June 24, 2010 12:19 PM +1000 Nick Urbanik
<nick.urbanik@optusnet.com.au> wrote:

Dear Folks,

our old backup system for our LDAP clusters using slurpd is as

Just use slapcat.
# du -sh /var/lib/ldap
7.4G	/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.



Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
Zimbra ::  the leader in open source messaging and collaboration