Encryption not known to target repository

[dcit]

We have Veeam Backup & Replication server in DR offsite datacenter, primary backups are going to backup proxy (with local storage) at primary location.

I would like to backup whole Windows Server with VBR using Veeam Agent backup managed from that server (it is running at VMware VM but as I understand gifted VUL licences to socket based Veeam Essentials Enterprise Plus can be used only for Agent based backups, we do not have socket based licence to ESXi server at DR site, on which VM with VBR is running on). Backups should be encrypted. Target of that backup should be that backup proxy in primary, but I do not want to this proxy to see any data from that backup in unencrypted form, as my concern is that someone can hack our primary site then from that backup extract access data to VBR at DR site and delete our backups. I would like no access from primary to VBR allowed, only when initiated from VBR. I hope that when VBR initiates copy backup from that backup proxy at primary to offsite backup server at DR, that it does not open door for attacker to delete data at offsite copy backup server.

According to help (https://helpcenter.veeam.com/docs/backu ... ml?ver=110) encryption when target is Veean backup repository is done at VBR, which I interpret in our case as at backup proxy which has that repository as local disk space, or encryption is done at Veeam Agent computer if target is network share.

So solution to my problem can probably be: create network share at that backup proxy, and VBR creates network share repo and set is as target.

Other possible solution could be: Veeam Agent backup to offsite server at DR (used as copy backups target) with encryption enabled, then copy backup to backup proxy at primary with encryption enabled, but I do not see in help if encryption is in that case done at source or at target. Only I have found this post veeam-backup-replication-f2/encryption- ... 24065.html which claims that:

"If using a backup job with encryption specified, Veeam will unencrypt the data before sending it to my DR site. It will then re-encrypt the data before flight. My WAN accelerator will not be able to dedupe the data" and "Veeam handles transmitting data via the build-in WAN accelerator:
3. Data blocks are passed to the target backup repository in the unencrypted format.
4. Received data blocks are encrypted on the target site and stored to a resulting backup file on
the target backup repository."

[Dima P.]

Hello dcit,

Yes, you can register file share as a repository on the same machine that acts as a proxy server for other backups. Encryption will be controlled by Veeam B&R server (via Repository Access server), however, backup proxies do not interact with agent jobs and backups at all.

[dcit]

So backup proxies do not interact with agent jobs and backups at all. But what about backup repositories? From that help I have understood that Veeam Agent backuping to backup proxy will send that data to it unencrypted (probably through encrypted connection but Veeam backup repository will get those data unencrypted), and encryption will be done by backup repository.

At DR site we have two physical servers, first one with Windows Server for backup repository for copy backups, second one ESXi server and on that we have VBR in virtual machine (and we are planning to replicate VMs from primary site to).

Finally I have choosen this solution:
Veeam Agent managed by VBR backups Windows Server with VBR installed on to that repository for copy backups, encrypted, and I do not mind if this copy backup repository server will see unencrypted data
then copy backup to network share shared from backup repository/proxy at primary, encrypted
(that network share is added to VBR using that copy backup server as gateway server) (when copy backup in action I see in Windows Resource monitor that data are transfered to network by System, so Veeam is using Windows on that copy backup repository/proxy as samba client, so target server should see data only in encrypted form for sure)

and I will backup that copy backup repository/proxy using Veeam Agent managed by VBR to that network share too
(this time directly as primary backup target; and copy backup will not be created)

[Dima P.]

Hello dcit,

So backup proxies do not interact with agent jobs and backups at all. But what about backup repositories?

Backup repo is used during recovery.

From that help I have understood that Veeam Agent backuping to backup proxy will send that data to it unencrypted (probably through encrypted connection but Veeam backup repository will get those data unencrypted), and encryption will be done by backup repository.

Yes, encryption is performed by the repository but data block are encrypted during transport.

Veeam Agent managed by VBR backups Windows Server with VBR installed on to that repository for copy backups, encrypted, and I do not mind if this copy backup repository server will see unencrypted data
then copy backup to network share shared from backup repository/proxy at primary, encrypted

Sounds ok.

P.S. Came up with another option: you can use agent in standalone mode with it's own encryption password set. You can use regulars file share as a target (not added to Veeam B&R as repo). Then the backup will be encrypted by agent itself and any Veeam B&R component cannot interact with the backup (unless you type in the password used for standalone agent encryption to the Veeam B&R console).

[dcit]

P.S. Came up with another option: you can use agent in standalone mode with it's own encryption password set. You can use regulars file share as a target (not added to Veeam B&R as repo). Then the backup will be encrypted by agent itself and any Veeam B&R component cannot interact with the backup (unless you type in the password used for standalone agent encryption to the Veeam B&R console).

I have been considering this myself, and I have saw
- cons:
not managed "under one roof" in VBR
- pros:
VUL license not needed

So when we have not used gifted VUL to socket licenses, and encryption password being known to offsite VBR server seems OK to me (when I can be sure enough that this password will not be given to onsite backup proxy/repository), I have choosen to have it managed by VBR.