Peter Mogensen wrote:
Hi,
I've been going all documentation I can find (FAQ/bdb-docs..) and I still have some doubt whether I understand this correctly.
All of your questions are answered in the official BDB docs.
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/a...
These docs are for the current version, 4.6.21, but not much has changed in the description since 4.2.52.
I run frequent dumps with slapcat to backup the database, but I still need to cleanup the BDB logfiles and it would also be nice get faster back online after a crash than you can from LDIF.
So I understand how to create a hot backup by copying the database files (db_archive -s) and then the log files (db_archive -l) and runing db_recover -c.
No, "db_recover -c" is for recovering from a catastrophic failure. It's not for creating a backup.
I can see that I can delete unused log files (db_archive [no options]) from the backup. But when is it safe to remove log files from the active environment? db_archive on the active environment lists fewer files than on the backup (predictable enough).
From the BDB doc page above:
To minimize the archival space needed for log files when doing a hot backup, run db_archive to identify those log files which are not in use. Log files which are not in use do not need to be included when creating a hot backup, and you can discard them or move them aside for use with previous backups (whichever is appropriate), before beginning the hot backup. <<
The docs say that running db_archive -d can make recovery impossible. OK... so I don't do that. But what is required of my hot backup snapshot to know that I can delete log files from the active environment? (and which?) and still not influence the posibility for recovery.
Could anyone list a step-by-step procedure to create a snapshot for backup and prune the log files from the active environment?
The docs/ref/transapp/archival.html file that SleepyCat bundles in the BerkeleyDB installation provides all the steps.
btw: openldap 2.3.30/ bdb 4.2.52 (debian) ... but I guess that's not so important here.