Learn Veeam - Encryption & Key Management

#Introduction

With the network secured in episode 14, we close the last gap on the data side: encryption. Backups are the most valuable concentration of data in an organization — if a repository is stolen or carried out, its contents must be unreadable without the key. In episode 15 we cover per-job AES-256 encryption, key management, and auditing.

Backup encryption has two dimensions: protecting from outside (theft/copy of a repository) and sometimes fighting back (encrypted backups are useless to ransomware trying to read them). Both use the same mechanism.

#Backup Encryption: AES-256

#Active Encryption (Per Job)

Veeam encrypts backups with AES-256 at the block level, per job — each job has its own encryption key. When a backup runs, every block is encrypted before being written to the repository:

Encryption in the backup flow

VM data ──▶ Proxy (AES-256 encrypt) ──▶ Repository (encrypted)

Enable it from the job: Storage → Advanced → Encryption, enter a password. Jobs, replication, and backup copy jobs can use the same policy.

#Passive and Other Encryption

At-rest encryption at the repository/storage level — done by storage, not Veeam; combining both is still recommended.
In-transit — Veeam communication uses TLS 1.2+ (episode 13); data encryption in the proxy→repo flow is handled by Veeam when enabled.
For object storage, client-side encryption ensures data in the cloud is unreadable by the provider.

#When to Enable

Always enable if:

Backups are sent to cloud/object storage (data leaves the perimeter).
Backups are stored on stealable media (tape, removable disks, off-site).
Compliance (PCI-DSS, HIPAA, GDPR) requires encryption.

Note

Encryption is not free: proxy CPUs work harder, and the dedup ratio drops (the same block encrypted produces different output — it can't be deduplicated across blocks). For secure local repositories, you can choose to encrypt only on the capacity tier/off-site. Consider the performance vs security trade-off.

#Backup Encryption Key Management

#One Key, Many Copies

The biggest problem with backup encryption is not creating the key, but managing it. Losing the key means permanently losing the backup — the files still exist but are unreadable. The principles:

Store the key in more than one place (e.g. team password manager + central vault).
Don't store the key on the same VBR server — if the server is lost, the key goes with it.
Document who holds the key and the recovery procedure.

#Best Practices

Use a strong, unique password per job (or per group of jobs).
Consider HSM / KMS integration for centralized key storage.
Record the password hash in a safe place for verification without storing plaintext.
Rotate keys when the personnel holding them leave.

#Auditing: Logs, Reports, and Cyber Event Response

#Logs and Session Logs

Veeam stores detailed logs at C:\ProgramData\Veeam\Backup\... (episode 16). For auditing, what matters:

Session logs — the history of each job/restore (who ran it, result, duration).
Security logs — configuration changes, server connections, console access.
Windows Event Log — authentication and service changes.

#Reports for Compliance

Make reporting automatic (details in episode 20 with Veeam ONE): backup job success rate, restore point retention, repository capacity, and unverified backups. These reports are the compliance evidence during external audits:

Concise job status report

Get-VBRBackupSession -Last | Group-Object Result | Select-Object Name,Count

#Cyber Event Response

When an attack is detected (episode 13 — CyberDCR):

Isolate — disconnect the infected host; don't restore from a suspected repo.
Identify — determine which backups are clean vs suspect (Malware Detection).
Recover — Cleanroom Recovery in an isolated environment.
Audit — collect logs for forensics and remediation.
Report — complete documentation for compliance and lessons learned.

Warning

A lost encryption key cannot be recovered — there is no backdoor in AES-256. This is why key management must be designed before encryption is enabled, not after. Create a "person lost / key lost" procedure and test key recovery at least once a year.

#Verification

After this episode, make sure:

Critical jobs are AES-256 encrypted; the cloud backup copy is also encrypted.
Backup keys are stored in 2+ secure locations, not on the VBR server.
Routine job status reports run (Veeam ONE in episode 20).
The cyber event response procedure is written down and understood by the team.

#Closing

Key takeaways:

Per-job AES-256 encryption protects backups from theft and ransomware re-reading.
Enable it for cloud/off-site and stealable media; watch the impact on dedup.
Key management is the highest responsibility: store in 2+ places, not on the VBR server.
Audit via logs, session logs, and compliance reports.
Cyber event response: isolate → identify → Cleanroom → audit → report.

In the next episode, episode 16, we will cover troubleshooting & support — support bundles and logs at C:\ProgramData\Veeam, session logs, common cases (proxy failures, full repos, SFTP/storage timeouts), as well as Veeam Community, paid Technical Support, and the Veeam Universal License (VUL). You will become an admin who doesn't panic when a job fails!