[389-users] db2bak.pl error with changelogdb

[Richard Megginson]

----- 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 at 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 at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/389-users
> 
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users