Minimizing data loss with checkvob -force -fix

An understanding of the algorithm that checkvob uses the to recover missing data can help you optimize the data recovery process.

During –fix processing, checkvob uses the following algorithm to recover missing data by examining the contents of unreferenced containers. No changes are made to the database unless both the –force and –fix options are specified or you accept a fix? prompt.

Scan pools for alternate containers. In a previous pass over the pools, checkvob found all referenced containers. It now scans for unreferenced containers for that element, looking for alternate containers that might be used to reconstruct a replacement for the missing container by rebinding the alternate container to take the place of the missing one. There are two types of rebind operations:
Optimized rebind: Find alternate containers maintained by the right type manager.
1. Find best match: identical, superset, or subset.
  - Identical. Container has correct contents (user ran chpool during interval between pool and database reference times).
  - Superset. Container has superset of versions expected by database. This is common when the pool is newer than the database.
  - Subset. Container has subset of versions expected by database. This is common when the database is newer than the pool.
2. Clone and prune best match. Create a new container and copy the best alternate’s contents. Delete extra version data from the new container.
Nonoptimized rebind: If no alternate containers with the right type manager are found, checkvob constructs the container one version at a time from whatever sources are available, including containers maintained by other type managers and versions in cleartext pools.
If container reconstruction is incomplete, collect and report a list of missing versions.
If –force is specified or the fix? prompt is accepted, update VOB database:
1. Adjust the database to reference reconstructed containers.
2. Adjust the database (with the equivalent of rmver –data) to remove references to lost version data.
Move all of the element’s alternate containers to pool’s lost+found directory.
Note: Because (unreferenced) alternate containers are moved to lost+found now, rather than during checkvob’s subsequent debris processing pass, you can reclaim disk space from lost+found if the disk fills up during reconstruction. (Reconstruction can consume substantial disk space.) For example:
- A chtype binary_delta *.eps operation (from element type file) is not recorded in the older database. checkvob uses the newer pool’s unreferenced delta containers to reconstruct the missing whole copy containers expected by the older database.
- A chpool operation is not reflected by older storage pools. The checkvob command may have to find and clone hundreds, or thousands, of unreferenced data containers.

If you use the –force –fix options, checkvob prevents you from unintentionally accepting data loss:

Do not allow removal of all version numbers greater than 0 on a branch. In force-fix mode, checkvob does not update the VOB database to reflect an element’s missing data containers unless at least one version with a version number greater than 0 and its data remain. That is, you must run checkvob in –fix mode, without –force, and agree when prompted to accept a reconstructed element whose only remaining versions have version IDs such as \main\br1\0 and \main\br1\br2\0.
Prompts to allow data loss. In force-fix mode, checkvob prints the following prompt:
Do you want to override the default and allow fixing of elements involving missing version data? [no]

If you answer yes, checkvob prompts you to specify a time interval for which data loss is allowable (or expected). For example, if you restored source pools from a backup 24-hour-old backup, you can reasonably expect to lose version data created in the past 24 hours. In this case, run this command:

checkvob –force –fix –data –pool –source VOB-stg-pname

Respond to the Allow missing data created since: prompt to direct checkvob to allow the loss of data created and recorded in the VOB database after the specified date and time. See the description of the date-time argument in the lshistory reference page for a list of acceptable values when specifying dates and times.

If checkvob cannot find an expected container with data that was created before the specified time, it records this fact in the output log but does not accept the data loss until you run checkvob again without the –force option to process such elements individually, or adjust the allowed data loss time.

To silently accept (fix) all missing data containers without regard for creation time, use a very old date-time. The default time interval for allowed data loss is “since yesterday at 00:00:00.” If you supply a date older than one week, checkvob asks you to confirm it. The checkvob log files do not capture the time-interval dialogue from –force –fix operations.

Note: checkvob does not find or fix corrupted data containers. A container with the correct identity information at the correct location is considered healthy.