[Review]: Veeam BR – Storage-level Corruption Guard

by Davoud Teimouri · Published 20/09/2017 · Updated 04/04/2019

On This Post:

Storage-level Corruption Guard

Taking backup from virtual or physical machine is a good solution to protect data and services in an organization also some administrators taking backup form backup files on another storage space, it’s absolutely prefect but not enough!

If backup is corrupted during backup session or after that, the source backup and copied files will be corrupted and this is actually big risk because you can’t trust to your backup files.

Veeam has a utility to check and validate backups but it should be run manually or as a script after each job, you can read more iformation about this solution on the below post:

[Review]: Veeam BR Validator Command-Line Tool

Also Veeam BR offers “Sure Backup” feature for checking backup files totally on a isolated environment.

In addition to Sure Backup and Validator, Veeam BR has another feature to check backup files automatically at scheduled time. The feature is called “Storage-Level Corruption Guard”

How It Works?

When a job has finished, storage-level corruption guard will perform a CRC verification for the most recent restore point. It will validate whether the content of the backup chain blocks match the content described within the backup file metadata. If a mismatch is discovered, it will attempt to repair the data block from production storage, assuming the block still exists and has not been overwritten. If it exists, the backup file will be repaired. If not, storage-level corruption guard will fail and make the user aware that a new full backup is required, and that the backup chain must be recovered from a secondary copy of the backup.

When To Use?

It is recommended to use storage-level corruption guard for any backup job with no active full backups scheduled. Synthetic full backups are still “incremental forever” and may suffer from corruption over time.

It is highly discouraged to use storage-level corruption guard on any storage that performs native “scrubbing” to detect silent data corruptions. Such storage will automatically heal silent data corruptions from parity disks or using erasure coding. This is the case for most deduplication appliances.

“Storage-Level Corruption Guard” will work with all backup types:

Forever forward incremental
Forward incremental
Reverse incremental backup chains

Note: Health checking will be performed on the latest restore point in the backup chain. If the last backup restore point is incomplete, then health check will be performed on the restore point preceding the latest one. Also health check will verify the last chain of the backup and not the backup file, so if there is any scheduled for full backup, the health check will be ignored.

Storage-level Corruption Guard – Limitations

The feature is prefect but has some limitation that you need to aware about those limitations:

The health check is not performed during an active full backup job session started manually or automatically by schedule.
[For per-VM backup chains] If you add a new VM to an existing backup job that has been run for some time, Veeam Backup & Replication will perform the health check for it during the next incremental backup job session for the added VM.
The health check itself is started during the backup job session or the job retry session if the backup job session has failed. If the attempts are not successful, Veeam Backup & Replication will perform the health check during the last job retry in any case. The number of health check retries is equal to the number of job retries specified in the job settings.

How To Enable?

“Storage-level Corruption Guard” should be enabled for each job separately. For this configuration, open the “Edit Backup Job” dialog and select “Storage”: