You may find that recovery operations from online backup fail when the target of a restore is a Recovery Storage Group that exists on an External USB storage device. Most commonly External USB storage is implemented as a temporary measure due to lack of physical disk space on the server. Thus, the storage is added, an RSG is configured and linked, and a restore is attempted. However, there are a number of "gotchas" you need to be made aware of to allow these operations to complete successfully. The "general inspiration" for this post was taken from a real case I worked within Customer Support Services. Primary Issue & Symptoms: As mentioned above, I recently worked with a customer who was attempting to restore an Exchange 2003 Mailbox Database to a Recovery Storage Group that had been configured on an External USB Hard-Drive. This was done because the available disk space on the production server was not sufficient for restoring the complete mailbox database from backup. Once restored, the customer was going to perform any number of additional recovery operations (single item recovery, complete mailbox, complete database, etc.). What we found was that the restore job would initialize successfully but the byte count never increased above 238 bytes. The restore operation would eventually timeout and fail. A review of the restore log contained the following information:
Job Completion Status Job Ended: <time stamp> Completed Status: Failed Final Error: 0xa0008488 -- Access is DeniedTroubleshooting: At first glance the "Access is Denied" error would suggest a permissions related problem. I initially began the call with a review of the Recovery Storage Group's configuration. The configuration clearly showed that the linked mailbox store was being written to the USB drive, which was being provided to the system as the f:\ volume. I performed a compare and contrast of the permissions that had been written to the volume with the other drives and did not notice any specific NTFS permissions anomalies. I then proceeded to perform the following physical tests:
Event Type: Error Event Source: ESE Backup Event ID: 950 Description: Unexpected file system error 53 encountered while opening the restore environment file.This event clearly shows that the nature of the failure was during the creation of the Exchange Restore Environment file (restore.env). The System Error Code of 53 equates to "ERROR_BAD_NETPATH" or more commonly referred to as "the network path was not found". I decided to try testing whether or not my "Test Mailbox Store" could be restored to a physical (non-USB device). I did this by removing the RSG from the USB device, recreating it, and testing the restore. The result was that the restore was successful. Troubleshooting Conclusions: 1. The fact that the "Test Mailbox Store" could be restored to an RSG that did not exist on USB storage, immediately made the USB drive suspect. 2. The fact that the restore could complete successfully suggested no problems with the backup/restore agent or with the files actually being restored. So outside of the f:\ simply being a USB device, what made it unique? Backup and Restore Agents: When any valid Backup/Restore agent (e.g. one that abides to the rules and methods of the APIs responsible for Exchange aware backup/restore), actually restores an Exchange Database (regardless of whether or not it resides within a Recovery Storage Group or a production directory), the Extensible Storage Engine needs to be able to physical map the path specified as the Temporary Location for the restore. It does this via a UNC path that includes within the path the Admin Share for the target drive. \\Server Name\<AdminShare of Drive>\Temp Directory Specified For Log Files Example: \\MyServer\f$\MyRestore So to verify that the shares were configured properly, I had the customer open a command line and enter: NET SHARE NET SHARE will list all configured shares on a system. In my case, a review of the output clearly showed that the default Admin Share had not been created for the f:\ yet was present for all other drives. This explained why a restore to a separate physical disk worked in my previous troubleshooting step. The fact that share was not present also provided a logically sound reason for why System Error 53 was being documented in the 950 Event. Once, I had made this observation, I initially tried to create the share "manually". To do so, I shared the f:\ volume as f$ and manually applied all the permissions via a compare and contrast of a properly initialized Admin Share. Once done, I re-ran NET SHARE. Although the share now showed as present, the share itself did have a few noticeable differences (e.g. was not a Default Admin share), etc. (which in this instance would be expected as the share itself had not been actually created by the SERVER service). I proceeded to retry a restore, which failed with the identical errors. Troubleshooting Conclusions 2: The fact that the Default Admin share for the f:\ was missing suggested the following:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.