Using archecker to Verify Backups

When the user issues an onbar -v command, the following sequence of actions occurs:

1. ON–Bar uses the emergency boot file if the database server is offline or in microkernel mode or the sysutils database if the database server is online or quiescent to determine which backup to verify.
2. ON–Bar requests and retrieves the backup data from the storage manager.
3. ON–Bar forwards the backup data to archecker.
4. The archecker utility scans the backup data and creates a bitmap of the pages. During the scan phase, archecker verifies the following types of problems:
   • Backups with corrupt pages
   • Backups with corrupt control information
   • Backups with missing pages that have been added since the last level-0 backup
   • Retrieval of the wrong backup objects

     An example of retrieving the wrong backup object is if ON–Bar requests the rootdbs backup from last Wednesday but the storage manager retrieves the rootdbs backup from last Tuesday.

5. After it completes the scan, archecker uses this bitmap to verify the backup and records the status in the archecker message log. ON–Bar also records this status in the ON–Bar activity log.
6. When a backup is verified, ON–Bar inserts a row into the emergency boot file with the backup copy ID and the verification date, and updates the ins_verify and ins_verify_date rows of the bar_instance table in the sysutils database. For more information, see The bar_instance Table.

During the verification phase, archecker verifies that all the pages for each table are present and checks the partition pages, the reserved pages, the chunk-free list, blobspaces, sbspaces, and extents. The archecker utility also checks the free and used counts, verifies that the page stamps match and that no overlap exists in the extents.

Archecker writes temporary files in the directory that the AC_STORAGE parameter specifies. For information, see AC_STORAGE.