Exactly. Imagine that you have a chain of 7 daily incrementals with Full in the very end. In order to restore to the 5th day you need to have your Full + 4 subequent incrementals healthy. If any increment in forever-forward chain gets corrupted then you'll not be able no restore anything that is beyond it: F - i - i - i - X - i - i - i. The longer your chain exists without intermediate Fulls the more probability of loosing a big chunk of your chain. So it's better to perform periodic Fulls.So you're saying it's unwise to rely on a chain of incrementals that's too long?
If your backing up with CBT disabled will it find the bad X during a subsequent incremental?
This basically means that if any block in the backup file gets corrupted the next job run will not detect that the blocks are different since checksum is compared to checksum from meta.During backup, Veeam Backup & Replication <...>scans through the VM image and calculates a checksum for every data block.
When incremental backup is run, [b]Veeam Backup & Replication opens all backup files in the chain of previous full and incremental backups, reads [b]metadata from these files and compares it with checksums calculated for a VM in its current state.[/b] If a match is found (which means the block already exists in the backup), the corresponding block is filtered out.
Please check this thread.It would be nice to run once a week when I now run the full.<...>I need to verify nothing has happened to the data while it is in storage.
No. Integrity check validates only metadata.Is this what happens when I check "Enable automatic backup integrity checks"?
Users browsing this forum: Yahoo [Bot] and 18 guests