Product Version: 6.0
Last Modified: 05 Jan 2016
One or more recovery points in my backup repository is/are corrupted.
- How could the corruption happen?
- What can I do to prevent corruption in the future?
A recovery point can become corrupted if one or more data blocks related to this recovery point is/are invalid or missing.
This can happen due to the following reasons:
- Powering down or rebooting the Transporter during space reclaim task
Storage issues (bad blocks, physical storage corruption)
OS issues - e.g. the OS may report that data was written while it is physically not written (delayed write, cache, etc.)
- If there are corrupted recovery points in a backup repository and you continue using it, the number of corruptions may increase.
If the backup verification finds that a recovery point is corrupted, a red icon will be displayed over the affected backup in the backup repository details.
To view which recovery points are affected, please expand such backup. Corrupted recovery points are marked with a yellow icon.
If a recovery point is marked as corrupted, you still can try to recover files from it or run Flash VM Boot.
NAKIVO Backup & Replication does not prohibit recovery from such recovery points, although successful recovery cannot be guaranteed.
We recommend to delete corrupted recovery points as they may affect new data or data from other backups/recovery points.
- If the last recovery point is corrupted:
- Run the job for the backup with the corrupted recovery point. The product will automatically rebuild the last recovery point using the data from the source VM.
- Delete the last recovery point.
- If the corrupted recovery point is not the last one:
After removing the corrupted recovery points, you have to re-run backup verification to ensure other recovery points are good.
We also recommend to schedule backup verification so that it will run periodically.
In order to prevent corruptions in the future, we recommend the following:
- Make sure the Transporter assigned to the backup repository cannot be powered off or rebooted unexpectedly.
- If possible, use a couple of smaller repositories rather than a single large backup repository.
This way you can keep them more manageable: space reclaim and repository verification will happen faster.