[Feature request] More flexibility for health check

[DoMoSbg]

Hello,
I started a discussion in the veeam community, because we have a problem runnning health check on a backup copy job. The repository is powered on and off only during the backup copy job, so there is actually no possibility to run the health check because running a script before and after the health check is not possible. For more information see the full post on veeam community (https://community.veeam.com/discussion- ... ackup-6339).

It would be very helpful to allow to run scripts before and after the health check or alternatively to add an option to start the health check immediatly after the backup copy job is done and before the after job script. The last option would be better in our use case, because I would like to finish the whole process as fast as possible. But if I have to schedule the health check, I can't start health check immediately after the backup, because I don't know exactly how long it takes.

If you need any further information or have additional questions don't hesitate to ask.

Best regards

[Dima P.]

Hello Dominik,

The repository is powered on and off only during the backup copy job

Backup copy job was designed around cases like periodic network disconnects so it survives the repo power on / off thanks to the internal logic. It can identify restore point is being incomplete, and resume the copy process from the last transferred data block. Healthcheck for backup copy is required to validate the data that has already been transferred due to possible storage corruption issues (such as bit rot for example).

It would be very helpful to allow to run scripts before and after the health check or alternatively

Thank you for the feature request! Mind me asking what type of scripts you want to start after health check? Or the script itself is aimed to trigger the health check start?

[AlexHeylin]

That seems a very edge case. Can you explain why the repo is being powered off?

[DoMoSbg]

Hello,
thanks for the feedback.

Our use case is as follows:
- The copy job copies the backup files to an USB HDD which is connected on a small NAS Device (Synology).
- This NAS is powered on by a script which is executed before the backup copy job (via the veeam job script functionality). Besides this script cleans up the USB HDD.
- After the backup copy job the NAS is powered off by the script which runs after the backup copy job (via the veeam job script functionality).

Reasons for powering off the NAS Device:
- The USB HDD is changed every few days (for the backup on a separate location). Disconnecting and reconnecting the HDD is saver, if the NAS is powered off. Besides in this case it generates no error message on the NAS and it is easy to see whether the HDD can be changed or not (NAS off -> HDD can be changed, NAS on -> wait until it is off).
- Backup copy on the powered off storage is harder to access e.g. in case of a ransomware attack.
- lower energy consumption
- noise emission of the powered on NAS device (is located in an office room).

From my point of view there are a few possible solutions that solve my problem:
- Adding an option in the backup copy job which allows to start the health check immediately after the backup job.
- Adding the functionality to trigger a script before and after the health check. With this scripts I can power on and off the NAS. This solution has the disadvantage that I cannot trigger the health check immediately after the backup because the backup duration is not the same every day.
- Adding a function to manually trigger the health check from the command line or powershell. Then I can start it in the script after the job.

Hope that helps to understand our problem and the use case.

Best regards

[AlexHeylin]

That's a great explanation thanks. While it doesn't directly address your issue, I would advice considering immutable storage on Wasabi S3 as your ransomware (etc) protection. While what you're doing now is certainly safer than leaving the storage online, it is no substitute for properly immutable storage where even if an attacker gets full access to the VBR machine (so has access to all the secrets and scripts etc, and can start the storage up) they can't damage / remove the immutable backups. I offer this advice having seen some very near misses and hits when I've been called in to new clients to deal with ransomware attacks.

Your first and last proposed solutions seem sensible. The last is probably possible now - but possibly only via some obscure .Net native call in PowerShell and not a nice clean native PowerShell command. Veeam would likely "not support" making the native call, as they might change it in a later version etc.

[DoMoSbg]

I know that powering off the device is not the perfect solution to protect against ransomware. But I think it increases the protection a little bit without any costs for the moment.

Can you give me any information about the mentioned "obscure .Net native calls" in power shell? I think that could be a workaround as long as there is no other solution available. So I would try it out, if it is not too complicated.

Best regards

[AlexHeylin]

I can't, because I don't know what those calls (if any are exposed) might be as Veeam does not release documentation for them externally as they're designed for use by Veeam products only and are not supported for use by "end users".