Dear all, The problem I'm having is simple, although I didn't find much eplanations for it, once I try to backup the database with : slapcat -v -l ldap-backup5.ldif It works nicely, except that _all_ entries have : dn: structuralObjectClass: organizationalUnit dn: objectClass: organizationalRole cn: Manager dn: structuralObjectClass: inetOrgPerson entryUUID: e8ef2300-f04c-10fb-9b02-a54a91b9c30b (empty DNs) Although the information is still there, if I ldapsearch one of the entities it comes easily : ldapsearch -x -LLL '(uid=samir)' dn: cn=Samir Cury,ou=abc,ou=def,dc=org,dc=edu cn: Samir Cury Siqueira objectClass: inetOrgPerson is this problem obvious to any of you? The only similar case I found in the history was :http://www.openldap.org/lists/openldap-technical/201201/msg00160.html Which doesn't have a clear outcome. Any hint on where to look at? Thanks, Samir ==== Aditional information - just in case ==== My setup is a 1 Master 1 Slave of slapd 2.3.43. Relevant information is that after the master's hardware died, few days later the slave started to misbehave and probably got the DB corrupted. slapd_db_recover seems to have fixed it as now it is working just fine, log messages from before the error / recovery : #slapcat -v -l ldap-backup.ldif bdb_db_open: unclean shutdown detected; attempting recovery. bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered. #slapd_db_recover -v -h /var/lib/ldap Finding last valid log LSN: file: 2 offset 6078834 Recovery starting from [2][6065934] Recovery complete at Wed Oct 9 16:42:55 2013 Maximum transaction ID 8000c207 Recovery checkpoint [2][6091589] -- slapcat now has no warnings/errors -- I suspect slightly of this as I've read that corrupted databases can cause such effects, but the ldapsearch with full DNs makes me think that it didn't happen. ==== / Aditional information ====