0INBerkeley DB Reference Guide: Transaction Protected Applications[PH

Berkeley DB Reference Guide: Transaction Protected Applications



)

Archival procedures



FThe third component of the infrastructure, archival procedures,Gconcerns the recoverability of the database and the disk consumption ofthe database log files.

GThere are two separate aspects to these issues. First, you may want to-periodically create snapshots (i.e., backups)(of your databases to make it possible to?recover them from catastrophic failure. Second, you'll want toGperiodically remove log files in order to conserve disk space. The twoJprocedures are distinct from each other, and you cannot remove the current>log files simply because you have created a database snapshot.

FTo create a snapshot of your database that can be used to recover from:catastrophic failure, the following steps should be taken:

    p

  1. Run db_archive -s to identify all of the database dataIfiles that must be saved, and copy them to a backup device, (e.g., tape).GIf the database files are stored in a separate directory from the otherLBerkeley DB files, it may be simpler to archive the directory itself insteadof the individual files.

    ?More importantly, if any of the database files have not beenmaccessed during the lifetime of the current log files, db_archiveJwill not list them in its output! For this reason, it may be importantFto use a separate database file directory, archiving it instead of theGfiles listed by db_archive.N

  2. If your database is currently active, i.e., you are reading and writing<to the database files while the snapshot is being taken, runhdb_archive -l to identify the database log files thatyou must save, andFcopy them to a backup device, (e.g., tape). If the database log filesHare stored in a separate directory from the other database files, it mayDbe simpler to archive the directory itself instead of the individualfiles.


BNote that the order of these operations is important, and that the<database files must be archived before the log files.

LThe Berkeley DB library supports on-line backups, and it is not necessary toFstop reading or writing your databases during the time when you createJthis snapshot. Note however, that the snapshot of an active database willBbe consistent as of some unspecified time between the start of the(archival and when archival is completed.

ETo create a snapshot as of a specific time, you must stop reading andCwriting your databases for the entire time of the archival, force apcheckpoint (see db_checkpoint), and then archive the files listedhby the db_archive utility's -s and -l options.

COnce these steps are completed, your database can be recovered fromGcatastrophic failure to its state as of the time the archival was done.ETo update your snapshot so that recovery from catastrophic failure isHpossible up to a new point in time, repeat step #2, copying all existinglog files to a backup device.

EEach time that a complete snapshot is made, i.e. all database and logHfiles are copied to backup media, you may discard all previous snapshotsand saved log files.

IThe time to restore from catastrophic failure is a function of the numberGof log records that have been written since the snapshot was originallyFcreated. Perhaps more importantly, the more separate pieces of backupHmedia you use, the more likely that you will have a problem reading fromHone of them. For these reasons, it is often best to make snapshots on aregular basis.

JFor archival safety remember to ensure that you have multiple copies ofByour database backups, that you verify that your archival media isDerror-free, and that copies of your backups are stored off-site!

4To restore your database after catastrophic failure,$the following steps should be taken:

    F

  1. Restore the copies of the database files from the backup media.G

  2. Restore the copies of the log files from the backup media, inKthe order in which they were written. (It's possible that the same logCfile appears on multiple backups, and you only want the most recentversion of that log file!)d

  3. Run db_recover -c to recover the database.


HIt is possible to recreate the database in a location different than theEoriginal, by specifying appropriate pathnames to the -h optionFof the db_recover utility.

9To remove log files, the following steps should be taken:

    P

  1. If you are concerned with catastrophic failure, first copy them to backupFmedia (e.g., tape), as described above. This is because log files are1necessary for recovery from catastrophic failure.s

  2. Run db_archive without options, to identify all of the log files@that are no longer in use (e.g., no longer involved in an active transaction)..

  3. Remove those log files from the system.


MAPÿÿ