DB_ARCHIVE(1)

πŸ“¦ version 5.3.28, in centos-stream 9, epel 10, fedora 43, fedora 44

πŸ’– db_archive(1) β€” the BerkeleyDB Utilities era πŸ’–

okay bestie, sit down, we're doing log file archival and honestly? it's giving housekeeping queen πŸ‘‘


✨ NAME ✨

db_archive β€” find unused log files for archival 🌸


✨ SYNOPSIS ✨

db_archive [-adlsVv] [-h home] [-P password]

✨ DESCRIPTION ✨

so like, db_archive writes the pathnames of log files that are no longer in use (think: not involved in any active transactions anymore, they're done, they've retired πŸ’…) to the standard output, one pathname per line. super simple.

and why do we care?? because these log files should be written to backup media so you can actually recover if something catastrophic happens β€” and heads up, catastrophic recovery also requires a snapshot of the database files, so don't get cute and skip that part πŸ™ˆ β€” but after that? you may delete them from the system to reclaim disk space. spring cleaning, but for your filesystem. iconic 🧹✨


✨ OPTIONS ✨

  • -a β€” write all pathnames as absolute pathnames instead of relative to the database home directories. no more "relative to what tho" energy πŸ’…
  • -d β€” remove log files that are no longer needed; no filenames are written. > ⚠️ bestie, listen: automatic log file removal is likely to make catastrophic recovery impossible. like, genuinely impossible. this is the "delete your browser history and also your backup" button. use with intent 🫢
  • -h home β€” specify a home directory for the database environment. if you don't say anything, the current working directory is used. defaults, we love her 🌈
  • -l β€” write out the pathnames of all the database log files, whether or not they're involved in active transactions. no filter, no judgement, everyone gets listed ✨
  • -P password β€” specify an environment password. okay so, Berkeley DB utilities do overwrite password strings as soon as possible, but be aware there may be a window of vulnerability on systems where unprivileged users can see command-line arguments, or where utilities aren't able to overwrite the memory containing the command-line arguments. not me being paranoid, it's literally in the docs 😭
  • -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 output. soz, they didn't make the cut πŸ’€

it's 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. gone means gone, periodt πŸ¦‹

  • -V β€” write the library version number to the standard output, and exit. quick lil vibe check, then bye πŸ‘‹
  • -v β€” run in verbose mode, listing the checkpoints in the log files as they are reviewed. she's chatty and we respect it πŸ’œ

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 otherwise 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.) like, fr fr, who's out here renaming a log file mid-transaction?? πŸ™ˆ


the db_archive utility uses a Berkeley DB environment (as described for the -h option, the environment variable DB_HOME, or because the utility was run in a directory containing a Berkeley DB environment). in order to avoid environment corruption when using a Berkeley DB environment, 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). it's called ✨graceful exit✨ and it's the bare minimum 🫢

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. iykyk πŸ’…


✨ EXIT STATUS ✨

the db_archive utility exits 0 on success, and >0 if an error occurs. zero is the slay number, anything above it is a whole situation 🌈


✨ 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. fallback queen πŸ‘‘

✨ NOTES ✨

if the application(s) that use the environment make use of any of the following methods:

  • DB_ENV->add_data_dir
  • DB_ENV->set_data_dir
  • DB_ENV->set_lg_dir

then in order for this utility to run correctly, you need a DB_CONFIG file which sets the proper paths using the add_data_dir, or set_lg_dir configuration parameters. no DB_CONFIG, no correct run. it's giving "read the assignment before you submit" πŸ“βœ¨


✨ SEE ALSO ✨

db_checkpoint(1) db_deadlock(1) db_dump(1) db_hotbackup(1) db_log_verify(1) db_load(1) db_printlog(1) db_recover(1) db_replicate(1) db_stat(1) db_tuner(1) db_upgrade(1) db_verify(1)

the whole friend group, honestly 🫢 go say hi to all of them.


πŸ’– and that's the whole page, bestie πŸ’–

this was brought to you by BerkeleyDB 5.3.28, dated 06 December 2016 β€” yes, she's vintage, and vintage is always in style πŸŽ€πŸ‘‘ thanks for reading, mwah πŸ’…βœ¨

πŸ“¦ where this page comes from