NetBackup™ for Enterprise Vault™ Agent Administrator's Guide
- Introduction to NetBackup Enterprise Vault
- Installing NetBackup for Enterprise Vault
- Configuration
- About features provided by Enterprise Vault for a backup provider
- Performing backups of Enterprise Vault
- Performing restores of Enterprise Vault
- About restoring Enterprise Vault SQL databases
- Disaster recovery
- Enterprise Vault Agent support for Enterprise Vault
- Policy configuration for Enterprise Vault
- Notes about Enterprise Vault 10.0 backups
- About Enterprise Vault agent backups
- About Enterprise Vault agent restores
- Enterprise Vault agent functionality and support for Enterprise Vault
- Troubleshooting
- Appendix A. NetBackup Enterprise Vault Migrator
- Restoring Enterprise Vault migrated data from NetBackup
- Troubleshooting the Enterprise Vault migrator
About restoring Enterprise Vault SQL databases
Note:
Restoring multiple Enterprise Vault images in one restore operation is not supported in this release. Veritas recommends that you restore one backup image at a time. Selecting multiple backup images in a single restore job may give unpredictable results.
Review the following notes before you attempt to restore an Enterprise Vault SQL database:
Restore full and incremental backups one at a time.
When you do a redirected restore, you must select the Redirected restore option and specify the alternate SQL instance name and database name. (This requirement applies to each restore in the restore set.) The SQL instance name always contains the system name. (For default instances, the system name is the instance name.)
The Enterprise Vault agent cannot restore data and log files (.MDF and .LDF files) of an Enterprise Vault SQL database to a physical path that is different from the original physical path. As a result, the Enterprise Vault SQL restore is affected as follows:
The drive (C:/ or D:/) used by these files at backup time is available at the restore time (in the destination client).
In the redirected restore, if a new path (SQL instance or database name) already exists and it is associated with some other physical files. The database becomes associated with the new physical files after the restore completes. The physical files of the old database become dangling files and are no longer associated with a database.
In the redirected restore, if the physical files to be restored are present and associated with some other database, manually take the database offline. If you do not take the database offline, the restore cannot overwrite those files.