Full restore zlib decompression error -3

[mirick@insouth.com]

Well, I had a situation where I needed to perform a full restore of my Windows 10 Pro 21H1 pc. Veeam is version 5.0.0.4301. disk is good, chkdsk was clean.
Recovery media is current, booted to the DVD. No matter which restore point that I attempt to perform for a full bare metal restore, I get about 10-12 minutes into the restore on the C: drive, and we get a failure with the message "Restoring (C:). Zlib decpmpression error [-3]. Failed to download disk, Agen...."( cannot see the rest of the message ). Doesn't matter which restore point, it always fails, even went back to the last "Full" backup, and still get the same error. The backup repository was on a SAN disk hanging off of a Netgear Nighthawk router, and I've been able to restore in the past from this environment without issue. Emails always say that the backup were successful. Also copied the backup repository to a local usb drive, tried the restore again from a local source, and still get the same error. Now Windows is screwed to the point I cannot reboot it, repair procedures for Windows now fail, and I cannot boot into Windows, so the disk got 10 minutes of restore pushed into it, and the archetecture for Windows is screwed around now by the broken restore to the point it won't boot. Really brings to question the 4 other computers' backups that go to the same repository. Is there a way to "vet" the backup to see if it actually does have a zlib error? A utility to run against it to see if it is really screwed up, or a way to fix a repository? Kind of in a fix to the point of throwing Veeam out if I cannot trust it or get a simple restore out of it.... Any ideas will be appreciated.......

[Gostev]

It is really screwed up because this error indicates a storage-level corruption aka bit rot. In other words, your backup storage returns different data from what was written to it during backup. It's not uncommon for low-end storage. Backup applications like Veeam detect storage issues because along with each block we also store the associated checksum, which we validated retrieved data against during restores. Most regular apps don't do that and just consume corrupted content as is.

Normally in such situations you should perform the restore from a copy of your backups, which you are supposed to have according to 3-2-1 backup rule exactly for these types of circumstances. As even if you magically discovered a storage device rated to zero URE (Unrecoverable Read Error), in which case you should let us all know as everyone will want one, there are plenty of other risks too - as you backup storage can be physically damaged, stolen, consumed by fire or flood etc.

Alternatively, if this is the only backup you have, then in case of low number of corrupted blocks you should be able to salvage most of your data with volume-level or file-level restores (as long as the restore process does not require those corrupted blocks).

And I would definitely recommend replacing your backup storage. "SAN disk hanging off of a Netgear Nighthawk router" does not strike as the place I personally would trust my data, as you just added so many moving parts into your data path which can all contain bugs and introduce corruptions as data passes through them. Not to mention SMB stack quirks alone (I assume you use an SMB share to access the disk).

While throwing out the driver from a bus with a faulty engine does not exactly solve anything even if it may be the first reaction when you can't get somewhere on time as a result.