Health Check + Immediate Copy Mode

[mkretzer]

Why is the health check with immediate copy mode running at the start of the backup?

For us that means that even with immediate mode the backup copy is only created after many hours of health checking.

It would make much more sense to copy first and then check after finishing the copy.

Markus

[foggy]

It does so in both periodic and immediate modes to immediately fix the chain by transferring valid data blocks in case it detects any corrupted ones.

[mkretzer]

Ok, you are sacrificing having the latest copy off-site for the (on good hardware) rarely happening data corruption fix?

This is a bad tradeoff.
The one time we had data corruption the fix functionality was not even able to fix it.... Also, if there is a corruption it would be much more useful to alert the admin about this instead of silently trying to fix this (corruption might be part of a bigger issue).

[Gostev]

Yes, it's a terrible design for something that is called "immediate copy" and even comes with fancy RPO monitors to ensure off-site copy RPO is met. I did not realize this was the case, we need to change this @foggy

[foggy]

Also, if there is a corruption it would be much more useful to alert the admin about this instead of silently trying to fix this (corruption might be part of a bigger issue).

Health check will report it in the session log.

@Gostev, checking with R&D.

[mkretzer]

@foggy @Gostev "Health check will report it in the session log." - which is also terrible. Since V10 the session log always jumps to the bottom.

I bet 98 % of your customers never see that they had a corruption!
Basically what you say is that you have to look at every job log, scroll to the top on the days where a health check is done and check the status every day...

In our case the only corruption we ever had (to the backup files) was caused by a faulty FC storage controller - which kept on corrupting things with every X bytes written. If we would note have been absolutely paranoid we would have not found this issue.

[Gostev]

Basically what you say is that you have to look at every job log, scroll to the top on the days where a health check is done and check the status every day...

No, we never said that. In Veeam, in case any operation within the session ends with a warning/error, the session itself will get market with a warning/error too. While if the session itself shows as successful - it means every operation was successful, and so there's absolutely no point to scroll around and look at the specific lines on the specific days.

Now, data corruption detected during a backup health check will of course result in at least a warning.

[mkretzer]

Yes, but warnings are there basically every day... We have 10 job warnings in 12 jobs. None of which are of much intrest! One example: Backup copy jobs were waiting for backup infrastucture avaiablility for a short while....

[Gostev]

Well, I know for sure that's not typical for most customers... because we always get crucified whenever we accidentally add a warning that is not that important - everyone then comes here to complain and wanting us to "fix this" so that all of their email reports are perfectly green again

May be you should look at your warnings with support, and see if any timeouts that can be tweaked - there is a registry value for almost everything.

[mkretzer]

Ok - we might do that. Still, i think a data corruption is always something "critical" and not "warning".