The backup validation feature of OceanBase Database is primarily used to address the integrity and correctness of backup and archive data. Users can proactively validate whether a backup set or archived log has issues such as missing files, physical data corruption, or logical inconsistencies without performing an actual restore operation.
Note
For OceanBase Database V4.4.2, backup validation is supported starting from V4.4.2 BP2.
Backup validation can be categorized into Basic validation and Physical validation based on the validation level:
Basic validation: Checks only the integrity of the file list.
Physical validation: Checks the correctness of physical data and logical consistency.
Features
The backup validation feature of OceanBase Database has the following characteristics:
Improves restore success rate: By validating in advance, it ensures "preparedness for any eventuality" and eliminates the risk of "inability to restore due to corrupted backups."
Multi-level validation capability: Provides two validation levels, Basic validation and Physical validation, to meet different timeliness and depth validation requirements.
Flexible validation granularity: Supports validating entire backup and archive paths, specified backup sets, and specified log archive pieces, and supports validating backup data under specified paths across clusters.
Application scenarios
The backup validation feature is typically used in the following scenarios:
Data migration integrity check: After copying backup data between different directories or storage media, check if any files were missed during the copy.
Backup set availability check: Without performing a restore operation, check whether a backup set can be used for restore.
Based on OceanBase Database's validation levels and granularity, the recommended validation methods for common business scenarios are shown below.
Business scenarios |
Recommended validation plan |
References |
|---|---|---|
| Routine inspection: Regularly check whether the backup sets generated by the current tenant are available. | Use Physical-level validation to validate the entire backup and archive path. | Validate the entire backup and archive path |
| Post-migration check: After copying backup data, quickly confirm whether all files are present. | Use Basic-level validation for backup sets under the specified path. | Validate backup sets or log archive pieces in a specified path |
| Pre-restore check for remote recovery: On cluster B, validate the availability of backup data copied from cluster A before restore. | Validate backup data under the specified path. | Validate backup sets or log archive pieces in a specified path |
| Spot-check or quick validation of specific backup data: Validate only the most recent full backup. | Validate the specified backup set by specifying backup_set_id. |
Validate a specified backup set or log archive piece |