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.

Easiest method: setup replication. Then you've got an active backup or perhaps a node you can stop (if unused or part of a pair of slaves) and then slapcat that without user impact.

It's also a good idea to backup openldap's config (typically /etc/openldap or /usr/local/openldap/etc/openldap - your /etc/ldap dir /may/ be that dir.

As for /var/lib/[open]ldap: that would be where the db lives - backing that up would probably be a good idea too - even though slapcat should capture the data there.

- chris

________________________________ From: openldap-technical-bounces@OpenLDAP.org openldap-technical-bounces@OpenLDAP.org To: openldap-technical@openldap.org openldap-technical@openldap.org Sent: Sat Feb 11 05:10:24 2012 Subject: howto prepare automatic backups

Hi

Im looking how to prepare automatic backups to openldap database. In last mail I comment problem with a crash report, and Im testing how can I do backups and restore it. Only I view slapcat command, but you need to stop the database, and is a critical server and I can't do this stop without create problems to users. There is not any other form?

And for other part I would like to understand the content of every folder, because Im with a ubuntu 9.04 server and Im checking what folder I need to control for future restores. Can someone explain the funcition of /var/lib/ldap and /etc/ldap/???

Where is the users data?

Thanks

________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

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: openldap-technical-bounces@OpenLDAP.org openldap-technical-bounces@OpenLDAP.org To: 'openldap-technical@openldap.org' openldap-technical@openldap.org 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.