SkipBadBlocks behavior in Agent for Windows 2.0

[Stefan74]

Hi,

since upgrading from Endpoint Backup 1.5 to Agent for Windows 2.0, backups on a Windows10 client finish with a warning about skipped bad blocks:
'One or more bad blocks were detected and skipped.'

I'm aware that 'SkipBadBlocks' is now enabled by default. When disabling skipping of bad blocks in the registry (REG_DWORD SkipBadBlocks=0) the job finshes with status 'success'
This behavior is also mentioned here:
veeam-agent-for-windows-f33/crc-error-t36588-30.html

History also seems to be similar to the post above: the system having the issue was recovered from a defective SSD (indeed having bad blocks) to a brand new one using another backup/restore tool. Manual scans on the new disk (chkdsk, hddscan, ...) do not indicate any error condition on the replacement SSD. Also no mention of bad blocks in windows event log.
Is there some state beeing preserved by Veeam Agent for 'historic' occurences of bad blocks?

thanks,
Stefan

[Dima P.]

Hi Stefan,

VAW does not track the history bad block scans, so this behavior does look strange. May I ask you to submit a support case and share the case ID? Thank you in advance.

[majones]

I had this problem too and raised a case (ID 02148365). The solution was to run "chkdsk /b c:" on the new disk after the restoration.

[majones]

Dima - can the restoration process be modified to prevent bad blocks markers being carried-over with the restoration? – I spent a lot of time trying to work out what was wrong with the new disk or restoration because of the error message originating from the old disk, and I think others will have this experience too.

[Stefan74]

@Dima: sorry didn't have the time to open a support case up to now.
@majones: thanks for the tip! Will try if "chkdsk /b c:" fixes the problem

thanks,
Stefan

[Dima P.]

Martin,

Good idea. Let me check with the team.

[Stefan74]

clearing the bad cluster list using "chkdsk /b c:" also did the trick for me.
Thanks a lot Martin for your hint!
Also think that clearing bad cluster markers for NTFS file systems upon restore would be a good idea ...
cheers,
Stefan

[majones]

I'm no expert, but I think the problem arises as a consequence of running "chkdsk /r" (as would be normal) on the bad disk, because this creates a hidden file ($BadClus) that Windows uses to specify where bad blocks are located, and presumably this gets carried forward in the restoration and read by VEB and VAW so they then mis-diagnose that there are bad blocks on a new disk. "chkdsk /b" forces a re-evaluation of the bad blocks in $BadClus, so running it after a restoration to a new disk will make the bad blocks warning stop. But it is very time consuming to run "chkdsk /b", and besides it is actually quite alarming to see a bad block warning after restoring to a new disk, so a better solution would be for VEB/VAW to omit the $BadClus from the restoration if to a new disk.