Could anyone shed some light on helper appliances under the properties of object storage repo in VBR 12, image below.
According to description it should help with health check operations and if trying to configure it, it offers me a list of our Managed Servers (all Windows VMs). What is considered close network proximity with object storage? Just a good network latency or should the appliance be deployed in the same bucket? It's a bit confusing...
The helper appliance becomes helpful if you use public cloud object storage such as Azure or AWS.
Having an helper appliance in their cloud environment allows you to run a health check without egress costs.
For on-premise object storage appliances, I recommend to have the helper appliance as close as possible to the object storage appliance. We need to read data from the object storage when we do the health check. The better network connectivity (bandwidth, latency) you have between the helper appliance and object storage, the better performance you will get.
I would also like some clarification. Is it correct that the helper appliance requires EC2 (or an equivalent) for cloud object storage? I have set up a Wasabi repository, and the dialog says that the helper appliance has been configured successfully, which confuses me. How does the helper appliance work with Wasabi and other providers that do not offer EC2 (or an equivalent)? Can health checks be performed on cloud object storage without a helper appliance?
It may not be the best wording for S3 compatible object storage targets.
- Automated "Helper appliance" deployment to the cloud (EC2 or Azure VM) is only available for Amazon S3 and Azure BLOB repositories. By deploying such a helper appliance as a VM in Amazon or Azure, we can reduce some costs and provide better performance for the health check process and applying retention for unstructured data backup files (NAS, Object storage backups).
- For S3 compatible object storages, the "helper appliance" can be any managed Linux or windows server added to the backup console. We cannot deploy any appliance to Wasabi or similar services. Therefore instead of deploying a new appliance, we use existing managed server to do the health check and applying the retention for unstructured data backups.
According to the documentation: "If you perform health check for encrypted backup files, Veeam Backup & Replication will pass encryption keys to the regular backup repository or cloud repository. For more information on encryption, see Data Encryption."
This raises a security concern for me. While I understand that the encryption keys are sent to the helper application in the cloud for validating the unencrypted data, how does this statement apply to S3 compatible storage, especially when the health check is conducted from one of my managed (and protected) servers? Will my encryption keys enter the cloud?
We will never send the encryption keys to Wasabi or any other S3 compatible service provider. Only specific Veeam components managed by your backup server will need to have access to the encryption key.
Cloud repository is in case you have backups on a cloud connect target. Then we need to send the encryption keys to the providers cloud connect environment for the health check process.
I will ask our tech writers to update the user guide with better information where the encryption key is passed on.
Mildur wrote: ↑Jan 05, 2024 3:12 pm
- For S3 compatible object storages, the "helper appliance" can be any managed Linux or windows server added to the backup console. We cannot deploy any appliance to Wasabi or similar services. Therefore instead of deploying a new appliance, we use existing managed server to do the health check and applying the retention for unstructured data backups.
So, to perform a health check with wasabi you (well, the helper appliance) need to download again the data, right?
I'm having problems connecting to the helper appliance for an Azure blob storage repository, so I'd like to just fall back to having the health checks done on the VBR server itself (it's in the Azure cloud, so it's "close" to where the Azure blob storage is), but I don't seem to find a place to do that. It won't let me "Delete" the helper appliance on the backup repository screen, but all of the "Linux helper" have been removed from the Azure Compute account. I've even turned off "Health Checks" in the job itself hoping that would allow me to remove it, but I haven't found the magic recipe that will allow me to "Unconfigure" a helper appliance once it's "configured" on an Azure repository.
You're correct—currently, there's no option in the UI to fully remove or disable the helper appliance once it's been configured for an Azure blob storage repository. This behavior is known, and we have noted it for potential enhancement in future releases.
In the meantime, I recommend contacting our Support team. They can assist with troubleshooting the connection issues you're experiencing with the helper appliance and may also be able to help unconfigure it directly within your environment if needed.
