Re: [389-users] db2bak.pl error with changelogdb

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@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

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users