Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

db_recover(8) [osf1 man page]

db_recover(8)						      System Manager's Manual						     db_recover(8)

NAME
db_recover - Restores the database to a consistent state (Enhanced Security) SYNOPSIS
/usr/tcb/bin/db_recover [-cv] [-h home] FLAGS
Failure was catastrophic. Specify a home directory for the database. The correct directory for enhanced security is /var/tcb/files. Write out the pathnames of all of the database log files, whether or not they are involved in active transactions. Run in verbose mode. DESCRIPTION
A customized version of the Berkeley Database (Berkeley DB) is embedded in the operating system to provide high-performance database sup- port for critical security files. The DB includes full transactional support and database recovery, using write-ahead logging and check- pointing to record changes. The db_recover utility runs after an unexpected system failure to restore the security database to a consistent state. All committed transactions are guaranteed to appear after db_recover has run, and all uncommitted transactions are completely undone. DB recovery is normally performed automatically for the security files as part of system startup. In the case of catastrophic failure, an archival copy, or snapshot of all database files must be restored along with all of the log files written since the database file snapshot was made. (If disk space is a problem, log files may be referenced by symbolic links). If the failure was not catastrophic, the files present on the system at the time of failure are sufficient to perform recovery. If log files are missing, db_recover identifies the missing log files and fails, in which case the missing log files need to be restored and recovery performed again. The db_recover utility attaches to one or more of the Berkeley DB shared memory regions. In order to avoid region corruption, it should always be given the chance to detach and exit gracefully. To cause db_recover to clean up after itself and exit, send it an interrupt sig- nal (SIGINT). RETURN VALUES
The db_recover utility exits 0 on success, and >0 if an error occurs. ENVIRONMENT VARIABLES
If the -h option is not specified and the environment variable DB_HOME is set, it is used as the path of the database home. The home directory for security is /var/tcb/files. FILES
/var/tcb/files/auth.db /var/tcb/files/dblogs/* RELATED INFORMATION
Commands: db_archive(8), db_checkpoint(8), db_printlog(8), db_dump(8), db_load(8), db_stat(8), secconfig(8) delim off db_recover(8)

Check Out this Related Man Page

db_archive(1)						    BSD General Commands Manual 					     db_archive(1)

NAME
db_archive SYNOPSIS
db_archive [-adlsVv] [-h home] [-P password] DESCRIPTION
The db_archive utility writes the pathnames of log files that are no longer in use (for example, no longer involved in active transactions), to the standard output, one pathname per line. These log files should be written to backup media to provide for recovery in the case of cata- strophic failure (which also requires a snapshot of the database files), but they may then be deleted from the system to reclaim disk space. The options are as follows: -a Write all pathnames as absolute pathnames, instead of relative to the database home directories. -d Remove log files that are no longer needed; no filenames are written. Automatic log file removal is likely to make catastrophic recovery impossible. -h Specify a home directory for the database environment; by default, the current working directory is used. -l Write out the pathnames of all the database log files, whether or not they are involved in active transactions. -P Specify an environment password. Although Berkeley DB utilities overwrite password strings as soon as possible, be aware there may be a window of vulnerability on systems where unprivileged users can see command-line arguments or where utilities are not able to overwrite the memory containing the command-line arguments. -s Write the pathnames of all the database files that need to be archived in order to recover the database from catastrophic failure. If any of the database files have not been accessed during the lifetime of the current log files, db_archive will not include them in this out- put. It is possible that some of the files to which the log refers have since been deleted from the system. In this case, db_archive will ignore them. When db_recover is run, any files to which the log refers that are not present during recovery are assumed to have been deleted and will not be recovered. -V Write the library version number to the standard output, and exit. -v Run in verbose mode, listing the checkpoints in the log files as they are reviewed. Log cursor handles (returned by the DB_ENV->log_cursor method) may have open file descriptors for log files in the database environment. Also, the Berkeley DB interfaces to the database environment logging subsystem (for example, DB_ENV->log_put and DB_TXN->abort) may allocate log cursors and have open file descriptors for log files as well. On operating systems where filesystem related system calls (for example, rename and unlink on Windows/NT) can fail if a process has an open file descriptor for the affected file, attempting to move or remove the log files listed by db_archive may fail. All Berkeley DB internal use of log cursors operates on active log files only and furthermore, is short-lived in nature. So, an application seeing such a failure should be restructured to close any open log cursors it may have, and other- wise to retry the operation until it succeeds. (Although the latter is not likely to be necessary; it is hard to imagine a reason to move or rename a log file in which transactions are being logged or aborted.) The db_archive utility uses a Berkeley DB environment (as described for the -h option, the environment variable DB_HOME, or because the util- ity was run in a directory containing a Berkeley DB environment). In order to avoid environment corruption when using a Berkeley DB environ- ment, db_archive should always be given the chance to detach from the environment and exit gracefully. To cause db_archive to release all environment resources and exit cleanly, send it an interrupt signal (SIGINT). The DB_ENV->log_archive method is the underlying method used by the db_archive utility. See the db_archive utility source code for an example of using DB_ENV->log_archive in a IEEE/ANSI Std 1003.1 (POSIX) environment. The db_archive utility exits 0 on success, and >0 if an error occurs. ENVIRONMENT
DB_HOME If the -h option is not specified and the environment variable DB_HOME is set, it is used as the path of the database home, as described in DB_ENV->open. SEE ALSO
db_checkpoint(1), db_deadlock(1), db_dump(1), db_load(1), db_printlog(1), db_recover(1), db_stat(1), db_upgrade(1), db_verify(1) Darwin December 3, 2003 Darwin
Man Page