On 05/14/2014 02:01 PM, Noriko Hosoi wrote: Sorry, should have given that: 389-ds-base-1.2.11.29-1.el6.x86_64 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

Sorry, I forgot to ask you. Could you please open a ticket at: https://fedorahosted.org/389/newticket? Thanks, --noriko Noriko Hosoi wrote:

this kinda brings up a long-standing question in my mind… what’s the “best” way to back things up? ok, let’s agree we need to know more about what’s the problem we are trying to solve. For me, i’d like to keep this somewhat generic to hopefully make this a useful discussion. Assuming multiple ldap servers the idea is to get a useful backup of the data in userRoot without much overhead and using a relatively safe mechanism. I’ll exclude definitions about time to restore and such. The db2bak strategy worries me cuz you’re backing up the db files and the time it takes to back those up on a reasonable sized ldap store is non-trivial. So, is there not a bit of worry about indices being out of sync with the entry store itself along with the log files managing the changes? one would have to filesystem snapshot the DB itself to get a sane backup of a production service, yes? db2ldif gets you the text dump of the DB. it is my understanding, at an object level, this gets you a reliable backup of each entry although data throughout the store may be inconsistent while the large file is being written. i can tell you i do this regularly and it seems to work well, but i wonder about what risks i am incurring with this strategy besides what i already noted. of course, you can have yet another ldap server lying around not being used by apps and it’s purpose is to dump the store periodically, but that may not be part of you what want to achieve with disparate locations and such. other strategies? yes, i have read the docs but i figured i would get a bit more practical by asking the question to possibly learn more about what others are actually doing. /mrg

On 5/14/2014 3:11 PM, Michael Gettes wrote: This does the equivalent of a table scan across the entries without isolation. So it is possible to end up with inconsistencies such as an entry without its parent, although the chance of this occurring is low.

David, Thank you so much for the 3 replies. They are VERY illuminating and helpful for me to now press ahead and better address my own particular needs based on our “requirements”. What I now intend to do is to perform, at regular intervals, db2bak to a specific directory. as i would like to convert the bak db to ldif, it doesn’t appear there is a relatively easy way to do this… either i’d have to mockup a new config dir to reference the bak db as the real db so db2ldif will work or i would have to create a new slapd instance and then configure it for schema and such to be identical to the real instance on the server and then db2bak with the output being the bak instance so i can run db2ldif on on the bak db. Bummer. nonetheless, i do appreciate your timely responses and the education i gained from them. /mrg On May 14, 2014, at 5:49 PM, David Boreham <david_list(a)boreham.org&gt; wrote:

----- Original Message ----- You can use the dbscan tool to convert the id2entry.db4 file in the backup to an "ldif-ish" format. dbscan -f /path/to/backup/id2entry.db4 > db.ldif-ish I say "ldif-ish" because it mostly looks like ldif, except the formatting is off. The biggest issue is that the full DN is not stored as the "dn:" attribute in the ldif. Instead, it is the RDN of the entry, and at runtime, the entryrdn.db4 index is used to construct the full DN. I think there may be operational attributes like entrydn in the dbscan output that you might be able to use for the dn. Otherwise, you'll also have to dbscan -f /path/to/entryrdn.db4 and parse the output to perform your own mapping of rdn + parentid to the full DN. That also might work.