Shutting down any applications that use it is sometimes unrealistic (like in the case for the infrastructure I manage/support). You have to make a choice - downtime or getting nearly all the data - if some data is perchance out of sync with other bits, well, that's disaster recovery.
Ideally, between replicated slaves, and mirrored master servers, the chance of catastrophic data loss is nearly nill. When it's time for disaster recovery (incredibly rare), I think a few items out of sync or date and getting 99.99% of the data backed up would be preferred to an outage every time a backup is scheduled. Let's be honest here, most data in an most LDAP trees is pretty static. Users are added, deleted, passwords changed. Ditto for hosts. Correcting recent missed/out-of-sync changes is a pretty minor task. Delete the half configured user account (if it's created through multiple transactions) and redo, readd/delete the hosts, asking a user to reset their password again, etc, while perhaps embarrassing to a small degree (this is where communication skills and a well designed infrastructure are important) is pretty small fry. If LDAP is being used as a general purpose DB where transactional data is stored then I suspect it's being misused - i.e.: the wrong tool for the job or under designed. Perhaps the applications in that scenario should work directly on a DB and then the DB pushes final changes through (whatever the mech is used) to LDAP for quick retrieval by the read parts/systems. - chris ----- Original Message ----- From: [email protected] <[email protected]> To: '[email protected]' <[email protected]> Sent: Sat Feb 11 11:50:35 2012 Subject: Re: howto prepare automatic backups Chris Jacobs wrote: > You don't need to stop openldap to slapcat. You simply can't guarantee it's > 100% up to date - which is more important when there's a lot of activity. I think we had this discussion on this list before: My conclusion from a customer project was if applications write several interdependent entries you also have to shutdown those applications to be 100% sure that you're not cutting something in the middle. Ciao, Michael. This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
