Richard Megginson wrote:
----- 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.
We may want to implement a utility to get full DN from entryid... (or
rdn + parentid)
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
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
