13.5 Sample Check and Fix Scenarios

The following sample scenarios (see Figure 22) illustrate some general guidelines for using checkvob.

Figure 22 Common Scenarios in VOB Database or Storage Pool Synchronization

Scenario 1: VOB Database Newer Than Storage Pools

A disk crash destroyed remote storage pools, which have been retrieved from backup. The VOB database is current, and the VOB is locked against any further write operations.

• The VOB database records development activity that is not substantiated in the storage pools.Under these circumstances, checkvob ought to discover missing and unreferenced data containers. Checkins have been recorded in the VOB database, but they do not appear in the storage pools. This represents real data loss. checkvob synchronizes the VOB database with the storage pool by executing rmver -data on missing versions.

Running checkvob

To accept as lost any pool data added in the interval between the pool and database reference times, run checkvob -force -fix and supply an appropriate time interval (see Force-Fix Mode).

To accept the default, one-day data loss interval, run checkvob -force -fix; then, run checkvob without -force and fix any remaining elements with missing containers manually (as you are prompted by checkvob).

Scenario 2: Storage Pools Newer Than VOB Database

The VOB database is corrupted. The storage pools are current, and you have a recent VOB database snapshot on disk. You have run vob_restore to recover the VOB database and storage pools. checkvob runs to complete the restoration process.

The VOB storage pools reflect development activity that has not been recorded in the VOB database. This scenario, like the previous one, is consistent with using a semi-live VOB backup scheme, as described in Backing Up a VOB. Under these circumstances, checkvob ought to find missing and unreferenced data containers. New checked-in versions have been written to VOB storage after the reference time on the available VOB database. Note that if any rmver, rmbranch, or rmelem events occurred during the time interval, recovering all versions is not possible (and, presumably, not desirable).

Running checkvob

Run checkvob -force -fix and supply an appropriate time interval (see Force-Fix Mode). Most new work (versions found in the newer pools, but unknown to the older database) will be captured in containers identified as debris and moved to the pool's lost+found subdirectory (from where you can, under some circumstances, retrieve it successfully). Note that under no circumstances does checkvob update a VOB database with "new" version data found in more recent pools. You may be able to construct versions from containers in lost+found and check them in as new versions, but checkvob cannot do so. The safety net features (see Force-Fix Mode) prevent large scale data loss. The only expected data loss reports should be the result of rmver or rmbranch operations no longer reflected by the (older) database.