I am going to assume (need to verify) that the Gateway selected for the Object Repository that you add to the SOBR would be the one that does the offloading and encryption. But let me try to confirm this.
Now if direct mode then I believe it is any server that can access the Object storage would do the offloading and encryption.
Thanks, @Chris.Childerhose
I went through all of them already. Neither one states where exactly the compute will be consumed. Only another reference to “at source” can be found.
So any evidence who exactly does capacity tier encryption would be appreciated.
I would say the gateway server is probably 90% safe to be responsible.
Thanks, @Chris.Childerhose
I went through all of them already. Neither one states where exactly the compute will be consumed. Only another reference to “at source” can be found.
So any evidence who exactly does capacity tier encryption would be appreciated.
I would say the gateway server is probably 90% safe to be responsible.
Yeah I am thinking when the offloading task runs whichever server is chosen as the “Gateway” server would be the one doing the encryption.
Yeah I am thinking when the offloading task runs whichever server is chosen as the “Gateway” server would be the one doing the encryption.
If anyone could find proof for it…
Downside would be, that data in transit internally BEFORE the offloading (extent->gw-srv) would be NOT be encrypted unless you also request in-flight encryption in network options. So there’s also pro points for encrypting directly on the repo-extent in the first place (=@source).
@tim.hudson @SSimpson -- Are you guys able to confirm the answer for Michael?
Hi @Michael Melter -
Great question...curious of this myself, at the very least, for knowledge. I honestly think your best bet is to ping the PMs directly over at the Forums.
@tim.hudson @SSimpson -- Are you guys able to confirm the answer for Michael?
Yeah! Chris you were right all along. The Gateway server for a given object server handles the read/write activity from Veeam → Repo. This means it will be the server that handles encrypting backup data before it lands on the target repository.
In direct mode the Proxy / Agent (if VAW/VAL/etc.) will be the system that performs the encryption of backup data before delivering to repository.
Thanks @tim.hudson.
Does this answer your question @Michael Melter ?
Yeah I am thinking when the offloading task runs whichever server is chosen as the “Gateway” server would be the one doing the encryption.
If anyone could find proof for it…
Downside would be, that data in transit internally BEFORE the offloading (extent->gw-srv) would be NOT be encrypted unless you also request in-flight encryption in network options. So there’s also pro points for encrypting directly on the repo-extent in the first place (=@source).
Michael is right (editing my previous post). Veeam data movers don’t encrypt traffic (on private networks) unless you specify those networks & that option in the Network Traffic rules option. (https://helpcenter.veeam.com/docs/backup/vsphere/enable_network_encryption.html?ver=120)
I am running this by one of the SA on my team as well.
I am running this by one of the SA on my team as well.
Thanks, Sean.
Encryption can happen at multiple levels. It's the same without VCC in the scenario. In both cases, encryption can be configured for the backup job and it can also be configured for the Capacity Tier extent. If both are enabled, then encryption is taking place twice
A service provider might decide to enable capacity tier encryption to ensure that unencrypted backups are encrypted.
Per Tim its the gateway server in this case...
@tim.hudson @SSimpson -- Are you guys able to confirm the answer for Michael?
Yeah! Chris you were right all along. The Gateway server for a given object server handles the read/write activity from Veeam → Repo. This means it will be the server that handles encrypting backup data before it lands on the target repository.
In direct mode the Proxy / Agent (if VAW/VAL/etc.) will be the system that performs the encryption of backup data before delivering to repository.
This is what I would have estimated. Thanks, @tim.hudson .
Do you maybe have a link that explains it in detail?
Honestly, would be nice to have the Technical Writing team add that, imo pertinent information, to the User Guide.
Yeah I am thinking when the offloading task runs whichever server is chosen as the “Gateway” server would be the one doing the encryption.
If anyone could find proof for it…
Downside would be, that data in transit internally BEFORE the offloading (extent->gw-srv) would be NOT be encrypted unless you also request in-flight encryption in network options. So there’s also pro points for encrypting directly on the repo-extent in the first place (=@source).
All data in transit from Veeam → Veeam (including repo extent → gateway server included) is encrypted. You can’t turn it off, AFAIK.
*Might be wrong on the above. Gonna need to research a bit more.
This is AFAIK not the case. You decide about that using traffic rules. https://helpcenter.veeam.com/docs/backup/vsphere/network_rules.html?ver=120
Encryption in flight also costumes resources. Therefore it's not per default.
Thanks
Michael
Yeah I am thinking when the offloading task runs whichever server is chosen as the “Gateway” server would be the one doing the encryption.
If anyone could find proof for it…
Downside would be, that data in transit internally BEFORE the offloading (extent->gw-srv) would be NOT be encrypted unless you also request in-flight encryption in network options. So there’s also pro points for encrypting directly on the repo-extent in the first place (=@source).
All data in transit from Veeam → Veeam (including repo extent → gateway server included) is encrypted. You can’t turn it off, AFAIK.
*Might be wrong on the above. Gonna need to research a bit more.
This is AFAIK not the case. You decide about that using traffic rules. https://helpcenter.veeam.com/docs/backup/vsphere/network_rules.html?ver=120
Encryption in flight also costumes resources. Therefore it's not per default.
Thanks
Michael
I’ve adjusted my earlier post so nobody is mis-directed later. You’re correct re: data mover encryption on private networks.