Hello,

Thank you for your response - it was very helpful.

Bug is registered with a solution proposal:

https://bugs.openldap.org/show_bug.cgi?id=10077

I also saw that entryCSN can be negative as well but the proposed solution should fix the problem.

createTimestamp: 20230110130503
entryCSN: 20230110130503.-060060Z#000000#000#000000
modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int

I was wondering how to handle this issue in case there is already this negative context CSN in the database?

So scenario would be as follow:

1) do a backup create ldif (contains contextCSN: 20230410125515.-401856Z#000000#000#000000 or entryCSN with minus)

2) do an update of openldap,

3) restore backup from ldif.

In this case restoring backup ends up with an error so there is no possibility to restore the backup database.

Could you please provide some guidance on how to clean up this corruption in a proper way?

Should I remove the line with negative contextCSN/entryCSN or remove the minus in the ldif file to restore the backup?

Or is there any other way?

Configuration uses provider and consumer with replication.

Thank you in advance for your response,

BR,

Peter

Am Mi., 14. Juni 2023 um 17:09 Uhr schrieb Quanah Gibson-Mount <quanah@fast-mail.org>:

--On Tuesday, June 13, 2023 12:11 PM +0200 awsome jang
<jangawsome@gmail.com> wrote:

>
> Hello,
>
> I am running openldap 2.6.3 configured as provider-consumer and I would
> like to do backup/restore of the database on the provider.
>
> I create a backup on working sladp using command(ends with success, file
> created):
> slapd.exe –T cat –f slapd.conf –l backup.ldif
>
> And then trying to load it using slapd command into a new
> database(restore):
> slapd.exe -T add -f slapd.conf -l backup.ldif -d -1
>
> Command ends with:
> .
> creatorsName: uid=root,ou=invalid,dc=vmbox,dc=int
> createTimestamp: 20230410111050Z
> entryCSN: 20230410111051.368528Z#000000#000#000000
> modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int
> modifyTimestamp: 20230410111050Z
> contextCSN: 20230410125515.-401856Z#000000#000#000000

This appears to be a bug with generating the CSN on windows, likely due to
some type of overflow. Can you please file a bug report at
https://bugs.openldap.org

Thanks!

Regards,
Quanah