Running system validation
The validation process is a feature that allows you to check the restorability of data stored on the DS-System online storage. The process is performed at the backup set level and can be used to validate the latest generation or all generations of the backup set files. Validation can be triggered by the DS-Client or the DS-System.
Prerequisites
• If validation is triggered from the DS-Client, the customer must enter their account and DS-Client encryption keys.
• If validation is triggered from the DS-System, DS-Client encryption key forwarding must be enabled, and the keys must already be forwarded to DS-System. For more information, see
“Configuring the encryption keys settings”.
When validation is triggered, the following occurs:
• For each file generation, DS‑System will check the file header, delta and library linking.
• If everything is fine, it will try to validate the data by performing a procedure that is like a ‘virtual’ restore. The data will be decrypted and decompressed to generate the original signature.
• If it fails due to a decryption or decompression problem, the validation fails.
• Finally, it will compare the generated signature with the original one. If it does not match, the validation fails; otherwise the validation is successful.
• For any validation failure, the error will be reported on both DS‑Client and DS‑System. If the validation fails due to reading or network problems, it is unknown whether or not the file is valid. Validation will skip the file and report the corresponding errors on both DS‑System and DS‑Client event logs.
NOTE: This applies for validation initiated by DS-Client. Validation initiated by DS-System will only report errors on DS-System.
• For other failures where DS‑System can confirm the file is corrupted, the file is moved to the trash directory. All files that depend on a corrupted file are also moved to the trash.
• If a file corruption is detected (including “Digital Signature does not match” errors), that file and all files that actually depend on it (occasionally, a delta may formally depend on a file, but does not actually depend on it) will be moved to the trash directory. The corresponding error will be reported on both DS‑System and DS‑Client sides.
• If the DS-System is part of a replication group, the Validation Process will try to retrieve the file from one of the other Replication DS-Systems. If the file is successfully recovered, then no action is required from the DS-Client.
• If the file cannot be successfully retrieved from a Replication DS-System, then the backup set is marked “out-of-sync” and DS-Client will have to synchronize it and resend the file (if it still exists on the source computer being backed up).
• If a file’s restorability status cannot be determined temporarily (networking problems, etc.), DS‑System will skip the validation of the file. The corresponding error will be reported on both DS‑System and DS‑Client sides.
• If a file originally did not have a signature that is needed for Validation, a warning will be reported.
• If any bad files are removed, DS‑System will mark the backup set as “out of sync” at the end of the Validation process.
NOTE: When scheduling validation, you should take into consideration that it is disk I/O intensive for the DS-System. It is almost the same as a regular restore, except instead of writing to a target location, the decrypted and decompressed data is discarded after generating the file signature.
Validation process vs. autonomic healing
Table 1 Validation vs. autonomic healing
Functionality | Description | Validation Process | Autonomic Healing |
Triggering | Triggered from DS-Client or DS-System | DS-Client or DS-System | DS-System |
Who makes decision when and how to run | Customer | Service provider |
Automatic triggering method | Schedule | Configure |
Can continuously run | No | Yes |
Running options | On-demand start/stop | Yes | Yes |
Speed adjustable based on DS-System Load | No | Yes |
Can automatically resume on file level | Yes | Yes |
Customized selection (on dir/file/generation level) | Yes | No |
Checking Capabilities | Check File Headers for damage/inconsistencies | Yes | Yes |
Check Directory Stream Headers for damage/inconsistencies | No | Yes |
Check library link for damage/inconsistencies | Yes | Yes |
Check Delta file for damage/inconsistencies | Yes | Yes |
Check file name for damage/inconsistencies across generations | No | Yes |
Check Directory ID/name for damage/inconsistencies | No | Yes |
Check File ID/name for damage/inconsistencies | No | Yes |
Check for orphaned recycled generations caused by data damage/corruption | No | Yes |
Check for session damage/inconsistencies across generations | No | Yes |
Check for corruptions causing decryption problems | Yes | No |
Check for corruptions causing decompression problems | Yes | No |
Check for corruptions causing digital signature does not match | Yes | No |
Fixing Capabilities | Delete corrupted files (move to trash folder) | Yes | Yes |
If DS-System is part of a replication group, attempt to retrieve the deleted files from a Replication DS-System. If all deleted files are successfully retrieved in this manner, skip step 3 (below). | Yes | Yes |
Mark backup set as out-of-sync after deletion or corrupted files are fixed | Yes | Yes |
Fix files/directories ID damage/inconsistencies | No | Yes |
Fix directory location damage/inconsistencies | No | Yes |
Fix file name damage/inconsistencies within directories | No | Yes |
Fix file name damage/inconsistencies across generations | No | Yes |
Fix delta linking/reconstruction damage/inconsistencies | Partially | Yes |
Fix library link damage/inconsistencies | No | Yes |
Remove orphaned recycled generations caused by data damage/inconsistencies | No | Yes |
Clean recycled generations to optimize storage space. | No | Yes |
Fix session damage/inconsistencies across generations | No | Yes |
Reporting | Report damage/inconsistencies in event log | Yes | Yes |
Report damage/inconsistencies in DS-Client event log | Yes | No |
Autonomic Healing is a tool that is recommended to run on DS-System all the time to find out and fix corruptions or inconsistencies as soon as possible. Some corruptions or inconsistencies may result in files not being restorable, and the backup set cannot be synchronized if the corruptions or inconsistencies are not fixed. Autonomic healing is the most powerful tool available to automatically fix such corruptions or inconsistencies.
The validation process is meant to verify there are no corruptions or inconsistencies that result in files not being restorable. It has some fixing capability, but it is not primarily designed to do fixing (which is what autonomic healing does). Whenever a customer wants to confirm the online storage is restorable, they can run the validation process. If it does not find a problem, there is certainty that the online storage is restorable. Running autonomic healing constantly can also maximize confidence in the online storage restorability.
To initiate a validation via DS-Operator:
1. In the Customers tab, browse and select the backup set you want.
2. Right-click and select Run System Validation. The System Validation dialog box appears.
• Select the options for the validation.
3. Click OK.
• You can verify the validation results in the activity log.