- Product Version:
- Problem Description:
- Cause:
- Please verify if the user had selected the Default encryption setting of "Use Login Password as Encrypting Key", or Custom (see Step 5 if Custom is selected)
- If the Default encryption setting is selected, please verify if there was any password change(s) to the backup account in concern. In most cases, a change in the password would not lead to a change of encrypting key. However, there could be exceptional cases where:
- The client has changed his/her password, and then login to ServosityPro / ServosityStandard (with the same backup account) on another machine
- The client has changed his/her password, and the User Profile directory (e.g. C:\Documents and Settings\Administrator\.obm\config) had been removed, he/she then login to ServosityPro / ServosityStandard (with the same backup account)
In the cases above, ServosityPro will prompt for the encrypting key setting for the backup sets that existed with the account. At this time, if the user had changed his password, he should enter the original password as the encrypting key. If the user select "Use Login Password as Encrypting Key", data of this particular backup set will then contain two encrypting key:- In the cases where the encrypting key was changed, please perform the restore using the user's previous password(s)
- In the cases where the previous encrypting key(s) is lost, there will be no way to restore data from the corresponding backup set
- Please also verify if the user had triggered the "Forgotten Password" email via the web console, and then login to their ServosityPro console using the hashed version of their password
- Please perform the restore using the hashed version of the corresponding user's password (or hashed version of the user's previous password). To do so, please contact our Support Engineer with details of the situation
- If Custom encryption setting is selected, the user must use the correct encrypting key to restore the data
- Please verify if the restore destination has enough storage space for the restore operation
- In the cases where the ServosityOBS server is installed on a Windows 2000 / XP machine, with User Home(s) configured to a network storage device. If the particular file from the restore source exceeded 4GB, the file may not be restorable due to Windows 2000/XP limitation. Please refer to the following URL for more information: http://support.microsoft.com/kb/898068/en-us
- As a last resort, please verify on the data integrity of the affected backup set
You can do so by logging into ServosityOBS management console, and then select [Manage User] -> [User Profile], you shall see an option just under the user summary called [File Validation Option], clicking on this will display the options and a [Check] button. Please enable the [Verify Checksum] option, and click on the [Check] button to start the single user rebuild.
When the Single User Storage Rebuild is started for the affected user, please verify if the following error message is received in the system log:
ServosityStandard: All
ServosityPro: All
OS: All platforms
ServosityPro: All
OS: All platforms
When performing a web restore, the following error message is received in the Online Backup Fle Restoring Manager:
Example: [ERROR] Cannot decrypt backup file. Decrypting key is incorrect

or
When attempting to perform a restore using the backup client user interface, ServosityPro / ServosityStandard repeatedly prompted for a correct encrypting key.
Example: [ERROR] Cannot decrypt backup file. Decrypting key is incorrect

or
When attempting to perform a restore using the backup client user interface, ServosityPro / ServosityStandard repeatedly prompted for a correct encrypting key.
Outlined below are some guidelines on how to troubleshoot the issue:
No. | Timestamp | Message |
* | hh:mm:ss | [info][system]Thread-10 Starting single user rebuild |
* | hh:mm:ss | ... |
* | hh:mm:ss | [info][system][BackupSet.rebuildIndexDir] File 'User_Home\username\files\Backup_ID\YYYY-MM-DD-hh-mm-ss \File has incorrect checksum. It will be uploaded again in next backup. |
* | hh:mm:ss | ... |
If there is, the problem may be related to data integrity of the affected file(s). Since the file(s) is being referenced with an incorrect checksum, the integrity of these data is compromised, and they are not restorable.
Notes:
Once a file has been flagged as having incorrect checksum by the Single User Storage Rebuild job, the file will be purged when the next backup is performed.