user13384449 wrote:Some remarks here, though you are probably doing things this way. You should be copying the log files from the smallest numbered log file to the largest numbered log file, in other words, in ascending order (based on the log file's number).
I had a system crashes this week.
Two weeks ago I took a snapshot of all the files of the environment directory and also every day a cron job makes the copies of all the logs from environment directory to backup directory.
First attempt to recover with "db_recover -c" and db_recover fails, the new logs could be added to the Database. after removing some log files, db_recover recovered ok, but there are no Logs added, information is related to two weeks ago.Even if recovery completed you probably lost the modifications from the log files that were removed from the live environment. Also, removing log files just to make recovery complete is not safe. Log files should be removed by following the guidelines here. Note that enabling automatic log file removal using the DB_LOG_AUTO_REMOVE flag will make catastrophic recovery impossible as you'll not have a chance to copy the log files to a backup location before they are removed; same applies to a log_archive(DB_ARCH_REMOVE) call -- before removing the logs, copy them to the backup directory.
I also have a full backup (slapcat) from and two weeks ago and now is restored (slapadd) and now is in production.You can try to copy the backup to an empty directory (we'll call it a recover directory), than copy all the log files from the live environment in that empty directory too and perform a catastrophic recovery. If the catastrophic recovery succeeds (db_recover -c), then you can use that recover directory as the live env directory, or move the files to the designated live env directory (overwriting any existing files in there).
Now there are 2 weak missing work, but :
- I have all the Logs related to this two weeks until the crash.
- All the logs have only new data to ADD, no modifications no deletes.
- What I need is only to ADD the data in the LOGs to the DataDase, if possible ....
For me, the information is not clear about hat happens in db_recover or "db_recover -c", if there are:There is no problem if during catastrophic recovery (since catastrophic recovery is the one replaying all the existing log files -- a normal recovery only replays the logs since the last checkpoint) some old log files are present, log files containing changes that are already applied in the databases.
a) Some of the logs are Old Logs that are not necessary but by mistake, are there ;
b) Partial or total missing Logs situation.Catastrophic recovery requires a continuous series of log files and will likely fail if there are gaps, that is, missing log files. By partially missing logs, I assume you are referring to partially missing log records -- this rather indicates log files corruption; in this case too, recovery will likely fail.
Can you give me some help one this suggestion?See the suggestion I mentioned a few paragraphs above. Let me know if you manage to successfully recover the database(s).
Using db_recover (normal or Catastrophic), db_verify, db_printlog
1 - Using the today database and logs, there are any way to select the proper logs from the last 2 weak and
then put them in the working directory with today Logs (openldap-data) in order to do a db_recover (-catastrophic ?) and ADDING has much as possible data ?
2- Using the backup from 2 weeks ago there are any way to select the proper logs from the last 2 weeks and
then put them in the backup system in order to do a db_recover (-catastrophic ?) and ADDING has much as possible data in the backup database and then create a LDIF file with 2 weeks work using a ldap_search withe CreateTime/ModificationTime filter and then "ldap_add" this data ?
user13384449 wrote:Okay, so an offline/cold backup taken first, which is than followed by incremental backups, by copying the new logs files daily to the backup directory.
I don't have the live environment due to disk problem, the only one is done in this way
First a snapshot, ready to work, to the backup computer:
with slapd stoped:
- db_remove unnecessary logs
- scp /usr/local/var/openldap-data/__* firstname.lastname@example.org:/usr/local/var/openldap-data/
- scp /usr/local/var/openldap-data/objct* email@example.com:/usr/local/var/openldap-data/
- scp /usr/local/var/openldap-data/log.* firstname.lastname@example.org:/usr/local/var/openldap-data/
- scp /usr/local/var/openldap-data/dn2id.bdb email@example.com:/usr/local/var/openldap-data/
- scp /usr/local/var/openldap-data/id2entry.bdb firstname.lastname@example.org:/usr/local/var/openldap-data/
On every day basis copy the Logs no LOG_NEW directory
with slapd running:
- scp /usr/local/var/openldap-data/log.* email@example.com:/usr/local/var/openldap-data/NEW/
theoretical all the log has there. First attempt to recover has:I do not understand why you copied the logs from the backup directory into the live environment directory. You basically overwrote/replaced up-to-date logs with their older versions.
a) copy all the NEW/log.* to /usr/local/var/openldap-data (2 logs replaced)
b) db_recover -c I got a PANNIC message LSN...
Question is:As explained above, you wrongly replaced those two log files, thus ending up with pieces of info (log records) missing from the log files, log records that (catastrophic) recovery needs in order to consistently reconstruct the databases.
- In this particular situation should the system recover properly and insert all the data in the DataBase or not due to two Logs file replacement ?
- In other situation where one log is damaged, there are some way to overcame the problem with continue option for instance in order to have has much as possible inserts in the database?A damaged log file would be a log file that is corrupted -- but in this case you would have seen a checksum error not an LSN error.