Simply put, i have veeam jobs where i am wondering if it is best practice to enable the health check feature.
I do believe it is off by default.
The jobs in question are configured for 14 daily and a synthetic full once per week. They are running on a SOBR which is immutable.
In the case of a SOBR (immutable performance and capacity) i understand it checks the performance tier directly as per the last successful backup that ran, and the capacity tier via its metadata files.
If i have a customer that has a job with 40tb of vms added to it for example and this job runs daily to a sobr, should i be enabling this health check to run monthly (or more frequently) or would the check itself take too long due to the backup size and cause issues with the backup itself running the follow days?
Also if the check is run once a month as per the default schedule would the capacity tier I/O costs shoot up in price due to this check running? I realize its only checking the metadata files and replacing blocks it might not have but im trying to get an idea of how much I/O would increase as it is an item that is billed for by most providers. In this case, AWS S3.
IF it finds corrupt data i also understand that it cant "heal" that data because it cant modify it (because its immutable).
I do remember a LONG time ago the recommendation was forever forward incrementals with regular sure backup testing. With the health checks, im just looking for best practice and what to expect if it is enabled.
Also...IF it finds corrupt data and cant heal it, im sure it must mark it in some way and error out. What then is the path to remedy this if the data is immutable both on the performance tier and the capacity tier? Would you need to start a new backup chain and thus another full backup and thus....potentially use 2x the storage until the old chain ages out? Does veeam track the old chain if this is the case and age it out and clean it up or does it mark it as corrupt and then you have to go back and manually clean it up?
Apologies for all the questions. I just want to be clear on what to expect should i want to turn this on. I have a feeling with backup jobs that are this huge any sort of error checking would take forever and maybe never complete.
I have more questions but ill start with this. I did read the guide as far as health checks but it left me with these questions.
I do believe it is off by default.
The jobs in question are configured for 14 daily and a synthetic full once per week. They are running on a SOBR which is immutable.
In the case of a SOBR (immutable performance and capacity) i understand it checks the performance tier directly as per the last successful backup that ran, and the capacity tier via its metadata files.
If i have a customer that has a job with 40tb of vms added to it for example and this job runs daily to a sobr, should i be enabling this health check to run monthly (or more frequently) or would the check itself take too long due to the backup size and cause issues with the backup itself running the follow days?
Also if the check is run once a month as per the default schedule would the capacity tier I/O costs shoot up in price due to this check running? I realize its only checking the metadata files and replacing blocks it might not have but im trying to get an idea of how much I/O would increase as it is an item that is billed for by most providers. In this case, AWS S3.
IF it finds corrupt data i also understand that it cant "heal" that data because it cant modify it (because its immutable).
I do remember a LONG time ago the recommendation was forever forward incrementals with regular sure backup testing. With the health checks, im just looking for best practice and what to expect if it is enabled.
Also...IF it finds corrupt data and cant heal it, im sure it must mark it in some way and error out. What then is the path to remedy this if the data is immutable both on the performance tier and the capacity tier? Would you need to start a new backup chain and thus another full backup and thus....potentially use 2x the storage until the old chain ages out? Does veeam track the old chain if this is the case and age it out and clean it up or does it mark it as corrupt and then you have to go back and manually clean it up?
Apologies for all the questions. I just want to be clear on what to expect should i want to turn this on. I have a feeling with backup jobs that are this huge any sort of error checking would take forever and maybe never complete.
I have more questions but ill start with this. I did read the guide as far as health checks but it left me with these questions.
Statistics: Posted by jcofin13 — Jan 16, 2025 5:44 pm
![Nocona – Los Dos (2020) [FLAC 24bit/44,1kHz]](http://imghd.xyz/images/2023/07/14/c4bspku7jtv9b_600.jpg)
