Offloading to Capacity Tier Object Storage - Where To Encrypt?

[wa15]

We are using Capacity Tier to offload data to Azure S3 and using Veeam Backup Copy Jobs and GFS to do this (7+ years retention). Where is the best place in the process on the Veeam side to configure encryption?

1. Do we configure it on the backup job?
2. Do we configure it on the backup copy job? This is where we currently have it configured.
3. Do we configured it on the settings SOBR Capacity Tier settings?
4. Is having it configured on the backup or backup copy job enough to make sure the data is encrypted at rest on S3 with the backup key configured in Veeam?

Thanks in advance!

[HouseAtreides]

I have it configured in all 3 places

[Gostev]

I would go with 2 in your scenario (offloaded backups are produced by Backup Copy jobs), as 4 is the correct statement.

1. If you do this, then you don't really need encryption at the Capacity Tier level. It's a waste of compute resources that adds slight performance impact, and potential reliability impact from unnecessary data transformations.

3. This is designed specifically for the case when your on-prem backups are not encrypted, for example because you land them on a deduplicating storage.

By the way, potentially you can also enable Amazon-managed encryption on the bucket itself, making it triple encryption

Thanks!

[wa15]

Thanks Gostev, good to know.

One more question: I assume if down the road we want to enable encryption at the backup job level, and leave it disabled at the backup copy and Capacity Tier level, it will still accomplish the same purpose of having data encrypted at rest in the cloud? i.e. the encryption will copy over through the backup copy and beyond?

[Gostev]

Yes, because
• Backup Copy preserves the original encryption for each block (at least with the default job settings)
• Capacity Tier passes all blocks to object storage without applying any modifications (except when they contain raw data, in which case it automatically applies compression to reduce storage consumption)

[wa15]

Another follow-up question: If we encrypt backups at the backup and backup copy job layers and these files eventually end up in a Capacity-Tier and offloaded to the cloud, will Veeam still be able to only upload the changed blocks for each VBK that's offloaded to the cloud? Encryption won't interfere with Veeam's ability to only offload the changes to cloud S3 storage?

[Gostev]

Correct, it won't make any difference.

[wa15]

Thanks!

Sorry one last question (no promises though )...you noted that if encryption on a backup job is enabled, the backup copy job for it will carry over encryption even if I don't include encryption on the backup copy job. But I just tested this and it doesn't appear to be the case?

[Gostev]

Sorry, then perhaps I just confused it with compression... I just remember there was "Auto" settings on the Storage settings page for Backup Copy job.

[wa15]

No worries, thanks. After more testing, backup copy definitely does NOT copy encryption if enabled on the backup job as there is even a warning when you backup copy an encrypted backup that:

“Source backup job has encryption enabled. Consider enabling encryption for Backup Copy job as well.”

[wa15]

I am back one more time...I am getting conflicting answers on the capacity-tier encryption setting and the backup copy encryption setting.

Support is telling me:

"Adding the encryption to the capacity Tier is simply wrapping it in another layer of encryption for the transmission itself - that encryption is not maintained in the backups that are on the capacity tier - and it also encrypts the metadata, etc. which normal job encryption does not. So it's not necessary, but it's also not a bad idea."

and

"The encryption for the capacity Tier is only in transit - basically to keep any man-in-the-middle attacks on the larger internet from sniffing your metadata and so forth."

But Gostev you had noted that:

"This (capacity tier encryption) is designed specifically for the case when your on-prem backups are not encrypted, for example because you land them on a deduplicating storage."

"If you do this (encrypt backup files), then you don't really need encryption at the Capacity Tier level. It's a waste of compute resources that adds slight performance impact, and potential reliability impact from unnecessary data transformations."

1. So support is saying having both is not a bad idea as metadata is also encrypted and that capacity-tier encryption is in transit only (which doesn't make sense to me as there is a also a network traffic rule that by default encrypts everything uploaded to the internet). So which is it?

2. Also, sounds like in case of deduplication appliances, having ONLY capacity-tier encryption enabled does NOT mean that the backups are encrypted at rest in S3 with Veeam kept keys (according to support), which is a problem because having backups encrypted at rest with Veeam kept keys is a huge plus as opposed to having provider encryption with keys that they keep. Is what support saying incorrect?

Case # 03945170 FYI.

[Gostev]

Your support engineer is incorrect (or there's a misunderstanding between you two, I didn't dig the support case).

Capacity Tier level encryption is "at-source" data encryption, meaning objects are encrypted before they are uploaded, and as such they rest encrypted on object storage. Note I specifically avoid using "at-rest" term for encryption, because this is a feature Amazon supports as an option too (encrypting incoming objects before storing them into S3) - but we don't use this feature, because we encrypt data "at-source" instead, which is more secure anyway.

"In-transit" encryption will be happen regardless of anything else, because we require HTTPS connection to object storage to be established, which uses TLS encryption.