SureBackup backup integrity check versus Backup Health check

[romulanvox]

I'm working on a Veeam v12.1 (latest patch) with AHV Proxy 5.1.0.7.

There's requirement by the end user to enable backup integrity check and from what I have researched, SureBackup's backup integrity check for AHV VM backups and the standard Backup Healthcheck are quite similar, except that Backup Healthcheck will recreate new Full backups or Incremental backups, if corruption is detected.

I've a few questions related to backup integrity checking, anti-virus scanning and inline entropy analysis, which I hope to get better clarity.

1. For Backup Healthcheck, I think the CRC hash values of the backup files are stored in the VBM file all with the all the backup files like VIB/VBK in the repo. During the Backup Healthcheck, it's the repo's CPU resource that is being used to check the backup files' CRC values. Is this correct?

2. For SureBackup's backup integrity check of AHV VM backups, are the CRC hash values values of the backup files are stored in the VBM file, and is the repo's CPU resources being used to perform the integrity check? My AHV VM backups are stored in a SOBR, so I'd assume if this is indeed the case, CPU resources in all repos that make up the SOBR will be leverage to perform the integrity check.

3. During the SureBackup's backup integrity check of AHV VM backups, is the entire restore point from the last successful incremental or full backup being checked, or is the entire chain (full + all the incrementals) of the newest backup chain being checked?

4. After I created a scheduled SureBackup job for backup integrity check linked to a specific AHV VM backup, when I right click on this SureBackup job, there's a "Start to.." menu option. When I click on this "Start to.." menu option, I'm presented a box named "Restore Point" with the text string "Most recent restore point prior to this time", then a Date and Time selection UI. What exactly does this option do?

5. After a scheduled SureBackup job for backup integrity check is completed, is there a report which I can pull from VeeamONE to show the results?

6. For AHV VM backups, if I select a Windows VM and right click, there's an active "Scan" menu item which results in a selection box named "Scan Backup". I believe this is a new feature for AHV VM backups in Veeam v12.1, which can use either YARA or the Windows Mount server's antivirus scan engine. It would appear that this type of "Scan" is a manually triggered action in the VBR console. Is there a way to script it so that specific VMs, or all the VMs in a AHV Backup, can be scanned for virus as a scheduled job?

7. For inline entropy analysis, is it applicable to AHV VM backups? If it is, during the analysis, is the CPU/memory resources of the VBR server being used to execute this scan? Is this inline entropy analysis a continuously running process that checks the completed backups for malware, or is it a process that runs on a user-defined schedule?

[david.domask]

Hi KNL,

1 - 2 - The process will be CPU bound primarily, yes, and also the storage performance is a factor as well as it's lots of random read IO.
3. The most recent point is checked (and blocks required from previous points for the current restore point)
4. By default, Surebackup jobs will test the most recent restore point available, however, this option lets you check specific points and perform the same verfication checks.
5. There is the Verified VMs report, but currently it works with just Vmware and HyperV jobs/infrastructure. With Powershell and the Veeam Backup and Replication server REST API, you can get the session information however.
6. This can be included as part of a SureBackup job that does the content verification and scan, and additionally can be triggered by Powershell with the cmdlet Start-VBRScanBackup
7. Please see our Supported Configurations and Requirements and limitations here for the inline entropy analysis scan. Right now there are some limits to consider. You can see how it works here and the processing is handled by the proxy during backup -- it's not a constantly running operation, it's done as part of backup.