Health Check, Synthetic Full, ReFS

[dbr]

Hi guys,

first some parameters:
V&R 9.5 U4b
6 backup jobs, each 3TB full backup file

Because we need to use (active) full backups in order to run virtual labs longer than one day and didn't want merges or synthetic operations and no need to defrag/compact, we had large fulls on the primary backup repository. The time had come to replace the repository and we sized the new on with ReFS in mind. In the best practices guide I read it's recommended to enable health check on all forever incremental respectively incremental with synthetic full chains. And now the dilemma: Health check runs once the month but takes up to 14 hours per job and delays subsequent copy job. I have to use health check to ensure integrity. Another option would be to re-enable active full but that means losing ReFS space savings. Had anyone the same problem or has an advice to get around this issue? Any hints / ideas welcome.

Thanks, Daniel.

[HannesK]

Hello,
in general, what you are talking about is a common question, so many people think about it. As far as I see, most people don't do health check and hope that backup or backup copy is fine in worst case.

I have to use health check to ensure integrity.

as an alternative, you could also check for event 133. Also SureBackup fails, if a backup file is broken (at least it failed in all the tests I have done without full integrity check)
- https://www.veeam.com/blog/advanced-ref ... suite.html
- http://www.running-system.com/how-to-mo ... og-id-133/

hmm, if reading 3 TB takes 14 hours... that's only about 125 MByte/s read rate. Maybe upgrading your repository could also help.

Best regards,
Hannes

[dbr]

Hi Hannes,

thank for your fast reply. I really thought about just hoping the chain won't get currupted but to me it looks a bit naive. I didn't know about the event 133, that seems to be a good way. We have some kind of nagios system in place so it should be possible to look for event 133. Regarding throughput: I agree, that's quite slow. I will check that.

[srdegeus]

Would a health check on the primary/first repository really add reliability? Wouldn't any corruption be detected by the Backup Copy job that needs to read the primary backup in order to compose the Backup Copy?

[HannesK]

no, the backup copy job does not do an integrity check. it costs too much performance (we are thinking about to add optional health check to BCJ, but no timeline yet).