unsichtbarre wrote:We have also ruled out disk corruption (on the backup repository) in this case.
Hmm... how has it been ruled out, if I may ask?
unsichtbarre wrote:Unfortunately, when the initial backup chain is corrupted, the Backup Copy job becomes useless!
It's not a correct statement because Backup Copy is technically a forward incremental job, so all previously created restored points cannot be affected by newly appearing corruption in source backups.
Mapleuser wrote:I've been predicting that this could happen.
Which is why I insist on doing an active full backup regularly rather than going on forever incremental.
At least if there are any corruption, the last active full should be a good copy?
No, not when your backup storage is experiencing issues - as then even the last active full will be bad. This is why you want to use SureBackup, or at least have storage-level corruption guard enabled in the backup job settings (while not a replacement for SureBackup, it will catch storage-level corruptions or any backup file chain inconsistencies).
As far as Active Full, it is largely useless unless you want some extra protection from possible yet unknown hypervisor-based changed block tracking bugs - although there have been bugs in VMware CBT before that resulted in corrupted active full backups. Really, only SureBackup can guarantee your VM backups (and most importantly applications running in those VMs) are recoverable.