NNAAMMEE db_archive - the DB database archiver SSYYNNOOPPSSIISS ddbb__aarrcchhiivvee [--aallssvv] [--hh hhoommee] DDEESSCCRRIIPPTTIIOONN The _d_b___a_r_c_h_i_v_e utility writes the pathnames of log files that are no longer in use (e.g., 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 catastrophic 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: --aa Write all pathnames as absolute pathnames, instead of relative to the database home directories. --hh Specify a home directory for the database. --ll Write out the pathnames of all of the database log files, whether or not they are involved in active transactions. --ss Write the pathnames of all of 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, _d_b___a_r_c_h_i_v_e will not include them in this output. It is possible that some of the files referenced in the log have since been deleted from the system. In this case, _d_b___a_r_c_h_i_v_e will ignore them. When _d_b___r_e_c_o_v_e_r(1) is run, any files referenced in the log that are not present during recovery are assumed to have been deleted and will not be recovered. --vv Run in verbose mode, listing the checkpoints in the log files as they are reviewed. The _d_b___a_r_c_h_i_v_e utility attaches to DB shared memory regions. In order to avoid region corruption, it should always be given the chance to detach and exit gracefully. To cause _d_b___a_r_c_h_i_v_e to clean up after itself and exit, send it an interrupt signal (SIGINT). The _d_b___a_r_c_h_i_v_e utility exits 0 on success, and >0 if an error occurs. DDBB AARRCCHHIIVVAALL PPRROOCCEEDDUURREESS There are two aspects to managing the recoverability and disk consumption of your DB databases. First, you may want to periodically create snapshots of your databases to make it possible to recover them from catastrophic failure. Second, you'll want to periodically remove log files in order to conserve on disk space. The two proce- dures are distinct from each other, and you cannot remove the current log files simply because you have created a database snapshot. To create a snapshot of your database that can be used to recover from catastrophic failure, the following steps should be taken: 1. Run _d_b___a_r_c_h_i_v_e -s to identify all of the database data files that must be saved, and copy them to a backup device, (e.g., tape). If the database files are stored in a separate directory from the other database files, it may be simpler to archive the directory itself instead of the individual files. MMoorree iimmppoorrttaannttllyy,, iiff aannyy ooff tthhee ddaattaabbaassee ffiilleess hhaavvee nnoott bbeeeenn aacccceesssseedd dduurriinngg tthhee lliiffeettiimmee ooff tthhee ccuurrrreenntt lloogg ffiilleess,, ddbb__aarrcchhiivvee wwiillll nnoott lliisstt tthheemm iinn iittss oouutt-- ppuutt!! For this reason, it may be important to use a separate database file directory, archiving it instead of the files listed by _d_b___a_r_c_h_i_v_e. 2. If your database is currently active, i.e., you are reading and writing to the database files while the snapshot is being taken, run _d_b___a_r_c_h_i_v_e -l to iden- tify the database log files, and copy them to a backup device, (e.g., tape). If the database log files are stored in a separate directory from the other database files, it may be simpler to archive the directory itself instead of the individual files. Note that the order of these operations is important, and that the database files mmuusstt be archived before the log files. The DB library supports on-line backups, and it is not necessary to stop reading or writing your databases during the time when you create this snapshot. Note however, that the snapshot of an active database will be consistent as of some unspecified time between the start of the archival and when archival is completed. To create a snapshot as of a specific time, you must stop reading and writing your databases for the entire time of the archival, force a checkpoint (see _d_b___c_h_e_c_k_p_o_i_n_t(1)), and then archive the files listed by the _d_b___a_r_c_h_i_v_e command's --ss and --ll options. Once these steps are completed, your database can be recovered from catastrophic failure to its state as of the time the archival was done. To update your snapshot so that recovery from catastrophic failure is possible up to a new point in time, repeat step #2, copying all existing log files to a backup device. Each time that a complete snapshot is made, i.e. all database and log files are copied to backup media, you may discard all previous snapshots and saved log files. The time to restore from catastrophic failure is a func- tion of the number of log records that have been written since the snapshot was originally created. Perhaps more importantly, the more separate pieces of backup media you use, the more likely that you will have a problem reading from one of them. For these reasons, it is often best to make snapshots on a regular basis. FFoorr aarrcchhiivvaall ssaaffeettyy rreemmeemmbbeerr ttoo eennssuurree tthhaatt yyoouu hhaavvee mmuull-- ttiippllee ccooppiieess ooff yyoouurr ddaattaabbaassee bbaacckkuuppss,, tthhaatt yyoouu vveerriiffyy tthhaatt yyoouurr aarrcchhiivvaall mmeeddiiaa iiss eerrrroorr--ffrreeee,, aanndd tthhaatt ccooppiieess ooff yyoouurr bbaacckkuuppss aarree ssttoorreedd ooffff--ssiittee!! To restore your database after catastrophic failure, the following steps should be taken: 1. Restore the copies of the database files from the backup media. 2. Restore the copies of the log files from the backup media, iinn tthhee oorrddeerr iinn wwhhiicchh tthheeyy wweerree wwrriitttteenn. (It's possible that the same log file appears on mul- tiple backups, and you only want the most recent ver- sion of that log file!) 3. Run _d_b___r_e_c_o_v_e_r -c to recover the database. It is possible to recreate the database in a location dif- ferent than the original, by specifying appropriate path- names to the -h option of the _d_b___r_e_c_o_v_e_r utility. To remove log files, the following steps should be taken: 1. If you are concerned with catastrophic failure, first copy them to backup media (e.g., tape), as described above. This is because log files are necessary for recovery from catastrophic failure. 2. Run _d_b___a_r_c_h_i_v_e, without options, to identify all of the log files that are no longer in use (e.g., involved in an active transaction). 3. Remove those log files from the system. EENNVVIIRROONNMMEENNTT VVAARRIIAABBLLEESS The following environment variables affect the execution of _d_b___a_r_c_h_i_v_e: DB_HOME If the --hh option is not specified and the environment variable _D_B___H_O_M_E is set, it is used as the path of the database home, as described in _d_b___a_p_p_i_n_i_t(3). SSEEEE AALLSSOO The DB library is a family of groups of functions that provides a modular programming interface to transactions and record-oriented file access. The library includes support for transactions, locking, logging and file page caching, as well as various indexed access methods. Many of the functional groups (e.g., the file page caching functions) are useful independent of the other DB func- tions, although some functional groups are explicitly based on other functional groups (e.g., transactions and logging). For a general description of the DB package, see _d_b___i_n_t_r_o(3). _d_b___a_r_c_h_i_v_e(1), _d_b___c_h_e_c_k_p_o_i_n_t(1), _d_b___d_e_a_d_l_o_c_k(1), _d_b___d_u_m_p(1), _d_b___l_o_a_d(1), _d_b___r_e_c_o_v_e_r(1), _d_b___s_t_a_t(1), _d_b___i_n_t_r_o(3), _d_b___a_p_p_i_n_i_t(3), _d_b___c_u_r_s_o_r(3), _d_b___d_b_m(3), _d_b___i_n_t_e_r_n_a_l(3), _d_b___l_o_c_k(3), _d_b___l_o_g(3), _d_b___m_p_o_o_l(3), _d_b___o_p_e_n(3), _d_b___t_h_r_e_a_d(3), _d_b___t_x_n(3)