----- Original Message -----
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
dbscan -f /path/to/backup/id2entry.db4 > db.ldif-ish
I say "ldif-ish" because it mostly looks like ldif, except the formatting is
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
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
On May 14, 2014, at 5:49 PM, David Boreham <david_list(a)boreham.org> 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 mailing list