----- Original Message ----- > 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… 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. > either i’d have to mockup a new config dir to reference the bak db as the > real db so db2ldif will work That also might 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@xxxxxxxxxxx> wrote: > > > > > On 5/14/2014 3:11 PM, Michael Gettes wrote: > >> 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. > > This is a useful approach if your servers are subject to heavy load, > > specifically heavy load that generates disk I/O. > > Backing up from a replica that is not serving client load can allow you to > > decouple the I/O load related to the backup from I/O activity related to > > client requests. With the use of SSDs (which have very high concurrent > > throughput vs disks) these days, this is less of an issue however. > > > > -- > > 389 users mailing list > > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
