Troubleshooting Restore - Sybase iDataAgent

Restore

The following section provides information on troubleshooting restores.

Browse Failures

Point in time Table Browse Failures

When you have encryption enabled for the client, point in time table browse operation fails with the following error message:

Pass-phrase protection is on for client [80], but pass-phrase was not specified.

Make sure that the pass phrase is exported to the MediaAgent when encryption is enabled for the client.

From the CommCell Browser, right-click the <Client> and then click Properties.
Click the Encryption tab.
Click Via Pass-Phrase.
Click Export.
In the Destination Computer box, select the MediaAgent.
In the Pass-Phrase box, type the pass-phrase used for encryption.
In the Re-enter Pass-Phrase box, re-type the pass-phrase to confirm.
Click Export.
Click OK.

Restore Failures

Failure of Backups and Restores performed from a remote desktop on windows

Currently, backups and restores cannot be performed from a remote desktop on Windows.

Use any one of the following solutions that suits your setup:

mstsc /v:winclient /console

Use netmeeting
Use telnet
Use the clients console

Restoring multiple databases in one job may fail

Sometimes, restoring multiple databases in one job may fail if different streams are used for data and log backups. If you need to restore multiple databases in one job, use the same streams for data and log backups.

Recovering Data Associated with Deleted Clients and Storage Policies

The following procedure describes the steps involved in recovering data associated with the following entities:

Deleted Storage Policy
Deleted Client, Agent, Backup Set or Instance

Before you Begin

This procedure can be performed when the following are available:

You have a Disaster Recovery Backup which contains information on the entity that you are trying to restore. For example, if you wish to recover a storage policy (and the data associated with the storage policy) that was accidentally deleted, you must have a copy of the disaster recovery backup which was performed before deleting the storage policy.
Media containing the data you wish to recover is available and not overwritten.
If a CommCell Migration license was available in the CommServe when the disaster recovery backup was performed, no additional licenses are required. If not, obtain the following licenses:
- IP Address Change license
- CommCell Migration license
See License Administration for more details.
A standby computer, which will be used temporarily to build a CommServe.

Recovering Deleted Data

Locate the latest Disaster Recovery Backup which contains the information on the entity (Storage Policy, Client, Agent, Backup Set or Instance) that you are trying to restore.
- You can check the Phase 1 destination for the DR Set or use Restore by Jobs for CommServe DR Data to restore the data.
- If the job was pruned and you know the media containing the Disaster Recovery Backup, you can move the media in the Overwrite Protect Media Pool. See Accessing Aged Data for more information. You can then restore the appropriate DR Set associated with the job as described in Restore by Jobs for CommServe DR Data.
- If the job is pruned and you do not know the media containing the Disaster Recovery Backup, you can do one of the following:
  If you regularly run and have copies of the Data on Media and Aging Forecast report you can check them to see if the appropriate media is available.
On a standby computer, install the CommServe software. For more information on installing the CommServe, see CommServe Deployment.
Restore the CommServe database using the CommServe Disaster Recovery Tool from the Disaster Recovery Backup described in Step 1. (See Restore a Disaster Recovery Backup for step-by-step instructions.)
Verify and ensure that the Bull Calypso Client Event Manager Bull Calypso Communications Service (EvMgrS) is running.
If you did not have a CommCell Migration license available in the CommServe when the disaster recovery backup was performed, apply the IP Address Change license and the CommCell Migration license on the standby CommServe. See Activate Licenses for step-by-step instructions.
Export the data associated with the affected clients from the standby CommServe as described in Export Data from the Source CommCell.

When you start the Command Line Interface to capture data, use the name of the standby CommServe in the -commcell argument.
Import the exported data to the main CommServe as described in Import Data on the Destination CommCell.
This will bring back the entity in the CommServe database and the entity will now be visible in the CommCell Browser. (Press F5 to refresh the CommCell Browser if the entity is not displayed after a successful merge.)
If you have additional data that was backed up after the disaster recovery backup and before the deletion of the entity, use the procedure described in Import Metadata from a Tape or Optical Media to obtain the necessary information.
You can now browse and restore the data from the appropriate entity.

As a precaution, mark media (tape and optical media) associated with the source CommCell as READ ONLY before performing a data recovery operation in the destination CommCell.

Resolve and Restore Defective Devices and Suspected Databases

A full Sybase restore may fail if one or more database devices are defective or have been physically deleted and the corresponding databases have therefore been marked as suspected. In such a case, all the databases marked as suspected and the corresponding devices whose files have been lost must be dropped and re-created.

Use the following steps to resolve and restore defective devices and suspected databases:

1.	Issue the following command to determine whether the database is "suspected": sp_marksuspect (<database name>)	Example: sp_marksuspect (<sybdb1>)
2.	Drop the suspected database using the following command: *dbcc dbrepair (<database name>, dropdb)*	Example: dbcc dbrepair (<sybdb1>, dropdb)
3.	If the database to be recovered is "sybsystemprocs", use the following command to drop the corresponding device (since stored procedures are not available at this point): *disk release name = <device name>*	Example disk release name = <tempdbdev>
4.	If any of the data device files do not exist but the device entry exists in sysdevices, drop those devices using the following command: *sp_dropdevice <device name>*	Example: sp_dropdevice <tempdbdev>
5.	Repeat the above procedure for each suspected database.
6.	Resume the restore starting with the first database that was deemed suspected.