> 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@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@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
No comments:
Post a Comment