Filter
Top Products
Managing the Data Protector Internal Database
Recovering the IDB
Chapter 9 423
label and media pool.
2. Run the omnidbutil -fixmpos command to establish consistency
between media positions (mpos) and binary files.
3. Import the catalog from the media to recreate the binary files. Refer
to “Importing the Catalog from Media” on page 114.
Recovering if DC
Binary Files Are
Corrupted
If some DC binary files are corrupted, you can remove the DC binary
files and recreate them. The only effect of removing the files is that some
media positions point to the non-existent binary files, and thus an error
message is displayed when browsing the relevant filesystems. Proceed as
follows:
1. From the omnidbcheck -dc output, identify the Medium ID of the
corrupted DC binary file. Run the omnimm -media_info <Medium>
command to get other attributes of the medium, such as medium
label and media pool.
2. Identify the DC binary file for the affected medium. DC binary files
are named: <Medium>_<TimeStamp>.dat (in the <Medium>, and
colons ":" are replaced with underscores "_").
3. Remove the corrupted DC binary files.
4. Run the omnidbutil -fixmpos command to establish consistency
between media positions (mpos) and binary files.
5. Import the catalog from the media to recreate the binary files. Refer
to “Importing the Catalog from Media” on page 114.
Handling Major Database Corruption in the
Filenames Part
If you detect that the corruption is of major severity, which means that a
filename tablespace is corrupted, you can remove the detail catalogs
(filenames and DC binary files) instead of recovering the whole IDB.
The procedure is fast and results in an IDB without detail catalogs (as
though all backups were done with the No log option). The IDB is still
fully operational in terms of all backups, restores, and media
management operations, except that browsing is not possible
(information about backed up data should be read from media).
Since all detail catalogs are lost, this method of recovery is only
applicable if: