Repair operations in EVSVR

Article:HOWTO57250  |  Created: 2011-08-01  |  Updated: 2013-07-12  |  Article URL http://www.symantec.com/docs/HOWTO57250
Article Type
How To


Subject


Repair operations in EVSVR

Note the following important points before you perform any Repair operation with EVSVR:

  • Only consider running a Repair operation if you encounter errors when you run a Verify operation.

  • Warning:

    Many of the Repair operations that are described below can cause data loss in some circumstances. Only the ArchivesVaultStore, BlacklistBadSISParts, and UndatedCollections operations cannot cause data loss.

    See Risk of data loss when you run certain EVSVR Repair operations.

    We strongly recommend that you contact Symantec Technical Support before you run any operation that can cause data loss.

  • Before you run a Repair operation, make a backup copy of your databases and place the vault stores that you want to repair in backup mode. This is the case even if you have stopped the associated Storage service.

    Caution:

    Starting the Storage service on a damaged system can damage it further. Do not start the Storage service before you have put the problematic vault stores in backup mode. Even then, only start the Storage service if it needs to be running.

If EVSVR reports any errors when you perform a Verify operation, you can correct them by performing a Repair operation. The function of the Repair operations is to recreate missing records in the vault store and fingerprint databases. In rare instances, a Repair operation creates new SIS parts on disk for items that have been shared many times.

A Repair operation has several Option settings from which you can select. Table: Option settings for Repair operations describes the available settings.

Table: Option settings for Repair operations

Option setting

Action

Archives

Combines the functions of two Repair operations: ArchivesDirectory and DatabaseReferences. In outline, the Archives operation does the following:

  • Removes any invalid collection records from the vault store databases, and recreates any missing collection records.

  • Recreates any missing SIS part records in the fingerprint databases.

  • Recreates any missing saveset records and associated records in the vault store databases.

  • Recreates any missing Archive and ArchiveFolder records in the Directory database.

This operation may be unable to recreate records if it cannot obtain the required information from the Directory database, vault store databases, savesets, target Exchange system (for Exchange Mailbox archives), or target file system volumes (for File System archives).

Before you can run this operation, you must select the type of archive that you want to repair: Exchange Mailbox or File System. If the operation finds any items in the archive that do not match the selected type, it reports an error and stops processing.

ArchivesDirectory

Recreates any missing Archive and ArchiveFolder records in the Directory database to make it consistent with the vault store databases. To do this, the ArchivesDirectory operation does the following:

  • Verifies that each ArchivePoint record in the vault store databases has a corresponding Archive record in the Directory database. If an Archive record is missing, the operation recreates it.

  • Verifies that each Vault record in the vault store databases has a corresponding ArchiveFolder record in the Directory database. If a Vault record is missing, the operation recreates it.

Before you can run this operation, you must select the type of archive that you want to repair: Exchange Mailbox or File System. If the operation finds any items in the archive that do not match the selected type, it reports an error and stops processing.

ArchivesVaultStore

Recreates any missing ArchivePoint and Vault records in the vault store databases to make them consistent with the Directory database. To do this, the ArchivesVaultStore operation does the following:

  • Verifies that each Archive record in the Directory database has a corresponding ArchivePoint record in the vault store databases. If an ArchivePoint record is missing, the operation recreates it.

  • Verifies that each ArchiveFolder record in the Directory database has a corresponding Vault record in the vault store databases. If a Vault record is missing, the operation recreates it.

You can also recreate missing ArchivePoint and Vault records in the vault store databases by running a DatabaseReferences Repair operation. However, after you run the DatabaseReferences operation, there can still be missing ArchivePoint and Vault records for archives and archive folders that do not contain savesets. In these circumstances, you must perform an ArchivesVaultStore Repair operation to recreate any missing records. Alternatively, you can do the following:

  1. Run an ArchivesVaultStore Repair operation to recreate the missing ArchivePoint and Vault records.

  2. Run a DatabaseReferences Repair operation to recreate the missing saveset records and update the recreated ArchivePoint and Vault records.

BlacklistBadSISParts

Blacklists any SIS part that does not verify correctly because it does not exist, has the wrong size, or does not match the value in the fingerprint database. After you blacklist a SIS part, archiving a new item with the same SIS part causes Enterprise Vault to create a new SIS part file on disk.

DatabaseLinkages

Does the following:

  • Verifies and corrects the reference counts of savesets and SIS parts in the collection records in the vault store databases.

  • Recreates any missing information on the SIS parts used by savesets in the vault store databases.

  • Verifies the number of references to SIS parts in the fingerprint databases against the number of references in all vault store databases in the vault store group, and corrects any that are wrong.

  • Reports on the number of unreferenced, unshared, and shared SIS parts, after the repair operation has completed.

DatabaseReferences

Recreates any missing records in the fingerprint databases and vault store databases. This option also updates any records that are found to be incorrect from the viewpoint of the partition.

Note the following:

  • This operation is not supported on CIFS and NTFS partitions if you have enabled both the collection process and migration to secondary storage using a migrator other than Enterprise Vault migrator. This is because non-Enterprise Vault migrators do not provide a way to scan the migrated data.

  • If you want to perform this operation on an EMC Centera partition, you must ensure that the Query capability is enabled for the Centera profile with which you connect to the Centera. If the Query capability is disabled, use the Centera CLI or Centera Viewer to run the Show Profile command. This command lists the current capabilities of the Centera profile, which you can then enable or disable by running the Update Profile command.

The following additional settings are available when you choose to run a DatabaseReferences operation:

  • Check Collection Counts. When selected, EVSVR checks the counts of referenced and unreferenced items in each CAB file and EMC Centera clip. If the number of unreferenced items is equal to the total number of items minus the number of referenced items - so, "unreferenced count = total count - referenced count" - then EVSVR does not recreate the database records for the unreferenced items because it assumes that they have been deleted. However, if you do not select Check Collection Counts, EVSVR considers all the missing database records as suitable for recreation.

  • Require Index Entries. When selected, EVSVR recreates missing saveset records for which the corresponding index entries exist, but it does not recreate any records that do not have index entries.

After you have performed a DatabaseReferences Repair operation, check that it was successful by reviewing its log file and performing a DatabaseReferences Verify operation. When you are satisfied that EVSVR has made the expected repairs, perform a DatabaseLinkages Repair operation on the same dataset.

 

The DatabaseReferences operation processes all SIS parts before it processes anything else. This can lead to the situation where the operation recreates unused SIS parts that it finds in CAB files. After the operation has completed, you can resolve this issue as follows:

  1. Check the DatabaseReferences Repair log file for any errors that the operation encountered. Use the severity of any issues as a guide to what to do next. For example, you may need to restore missing or corrupt files in the partition from backup copies and then rerun the DatabaseReferences Repair operation.

  2. After you have completed step 1 and judged the repair to be successful, run the DatabaseLinkages Repair operation.

  3. After you have completed step 2 and judged the repair to be successful, run the Complete Verify operation to confirm this.

  4. After you have completed step 3, verify that your environment is consistent and EVSVR has repaired everything that can be repaired. As a last resort, run the DeleteSurplusReferences Repair operation to remove any irreparable items and unused SIS parts.

DeleteSurplusReferences

As a last resort, deletes the vault store and fingerprint database records that are associated with missing and irretrievably lost items. When a missing item consists of multiple parts, this option also deletes from disk any remaining parts that are associated with the item.

You can also use this operation to remove unused SIS parts, but you must only do so when your environment is consistent.

When you start a DeleteSurplusReferences operation, it first performs an internal DatabaseLinkages Verify operation. The DeleteSurplusReferences operation only starts to process when the DatabaseLinkages Verify operation reports that the environment is consistent and error-free.

Before you perform a DeleteSurplusReferences operation, we recommend that you use the DatabaseReferences Repair operation to recreate any missing database references and ensure that the environment is consistent

Note the following:

  • The DeleteSurplusReferences operation does not take any action unless it can conclusively determine that the items in question are missing. For example, suppose that you have migrated archived data to secondary storage by using a non-Enterprise Vault migrator, such as Symantec NetBackup. If the migrator returns generic errors such as E_FAIL or E_UNEXPECTED, EVSVR does not take any action other than to report the errors.

  • When the DeleteSurplusReferences operation finds a CAB file or EMC Centera clip, it assumes that all the items that should exist within the CAB file or clip do exist

UndatedCollections

Assigns a creation date to any collection record in a vault store database that does not have one. In Enterprise Vault 8.0 and later, all new collection records automatically have a specified creation date. However, this is not the case for any collection records that an earlier version of Enterprise Vault has created. When the creation date for a collection record is missing, EVSVR assigns the creation date of the associated CAB file or Centera clip to it.

The DatabaseReferences and DeleteSurplusReferences Repair operations do not work with savesets and SIS parts that you have migrated to secondary storage. The reason for this is that each operation needs to determine the locations of the migrated files from the vault store and fingerprint databases. As the information in these databases may be incorrect, the operation cannot proceed effectively.

If you want to perform a Repair operation on migrated files, we recommend that you first return them to their original store location.

See Choosing a suitable EVSVR Repair operation

See About the EVSVR operation settings

See About EVSVR

See About Enterprise Vault utilities


Legacy ID



v21474250_v41328148


Article URL http://www.symantec.com/docs/HOWTO57250


Terms of use for this information are found in Legal Notices