We are trying to restore a Mailbox to a Recovery Database.
It failed initially due to socket read/write errors which we think is caused by resource contention.
On retrying later, it completed successfully. However, on the destination folder, the SYMC_RESTORE_IN_PROGRESS file remained from the previous failed attempt and the exchange team says the Database is still locked.
We could have tried to remove all the files and restore again but that would take at least one more day. Is there a better approach to resolving this?
NetBackup uses this touch file to prevent itself from inappropriately deleting transaction log files on a multiple-step point-in-time restore. Suppose you are restoring from a FULL backup image plus one or more incremental images, with the point-in-time option. Before restoring the first image, NetBackup deletes the existing transaction logs and creates the SYMC_RESTORE_IN_PROGRESS file. On subsequent images, NetBackup sees the touch file and refrains from deleting the just-restored files.
When all the backup images have been restored, NetBackup deletes the SYMC_RESTORE_IN_PROGRESS file before mounting the database.
The persistence of the touch file from the first restore attempt should have done no harm to the second attempt. It just would mean that whatever files were created by the first attempt would be overwritten by the second restore.
The persistence of the touch file after the second restore indicates that NetBackup was not directed to mount the database. (That, or a restore failure, are the only reasons the deletion of the file can be skipped.) Can the Exchange admin mount the RDB? If not, what errors do they get, and what errors does Exchange post to the Event log?