One of the tabs you may come across when setting up a Veeam backup job is the maintenance tab. Now a lot of the time settings within this tab just go untouched and left at their defaults, as it is in the Advanced settings of the job and most people tend not to fiddle with settings labeled as advanced. With that said I’m not most people, and with the defaults of the features on the maintenance tab being disabled I thought I’d do a little write-up about just what features are available here and how they all work – in the event that you may want to turn them on – because they are quite useful in keeping your backups healthy! This first part will deal with Veeam’s Storage-level Corruption Guard.
Storage-level corruption guard
The maintenance tab is really broke out into two separate functions with the first being Storage-level corruption guard (SLCG). SLGC has been around for a little while in Veeam Backup & Replication however it was only applicable to our Backup Copy jobs – with v9 that all changed as we have the ability to configure SLCG on our primary backup jobs as well. So what does SLCG do? Well, reading the checkbox description we can see that it “Perform backup files health check (detects and auto-heals corruption)”, but what does that really mean? To help explain this let’s first take a look at what Veeam does in terms of metadata and data blocks within their jobs….
When Veeam has completed a backup job and has saved a new restore point it processes and calculates a CRC value for the metadata blocks it writes and a hash value for the data blocks it writes. These checksums are then saved within the backup file itself. When it comes time for a health check these values are used to perform a comparison – If Veeam finds abnormalities or corruption then it will throw an error on the backup job. From there a retry process occurs just on the health check itself as a separate session. From here Veeam takes different action depending on what type of corruption has occurred.
Corruption of the metadata
As we can see above Veeam will actually perform a brand new active full backup if any corruption is detected within the metadata of a full backup file. Veeam essentially marks the complete chain, starting with the corrupt full backup and all its subsequent incrementals as corrupt and then continues to complete an active full backup from our production source, thus refreshing the data in both our data blocks and our metadata blocks. If the corruption were to occur within our incremental metadata Veeam would take a different approach. Instead of marking restore points as corrupt, Veeam will remove all information about the incremental (and subsequent incrementals if applicable) within the database. From there Veeam would simply create a new incremental file in the chain to replace the previously corrupted restore point.
Corruption of our backup data
If it is our actual backup data or our data blocks which contain the corruption Veeam takes a somewhat different approach. Basically, marking our chain as corrupt within the database and then grabs the data blocks from our source datastore once more. Also, if any blocks have been changed or overwritten since the health check has completed Veeam will also grab those and store all of these newly processed blocks in an incremental file within the chain.
Now depending on what backup method you use (Forever Incremental, Reverse Incremental, etc) the above two scenarios can certainly change a little – however, the process is essentially the same. Storage-level corruption guard will scan for corruption within our backup environment and repair it using data directly from our source datastores. It should be noted as well that SLCG only processes the latest restore point for VMs – meaning not every restore point is checked. Now that said since our restore points sometimes need multiple incrementals and a full in order to be processed the health check will touch multiple backup files. Also, if you are running a job which completes Active Full backups then SLCG will not run during those periods as the active full is already a direct copy of the source data. Synthetic Fulls however, since they are derived from other backup files will be scanned by the health check.
Needless to say, Storage-level corruption guard is an excellent safeguard to protecting your backup storage and giving you the best chance for a successful restore. I would most certainly recommend turning on this feature and letting it run at the very least on a monthly basis. For more information on SLCG or any other Veeam feature the Veeam Best Practices guide is a good place to look, along with the health check section in the Veeam User Guide. Watch for the next part of this series where we will talk about the second feature-set on the Veeam maintenance page; Full backup file maintenance. Thanks for reading!
