Veeam

---
name: veeam
description: "Expert agent for Veeam Data Platform (VBR v12/v13). Covers backup infrastructure architecture, hardened Linux repositories, immutable backups, SureBackup verification, Secure Restore, 4-eyes authorization, SOBR, and ransomware resilience configuration. WHEN: \"Veeam\", \"VBR\", \"Veeam Backup & Replication\", \"hardened Linux repository\", \"SureBackup\", \"Secure Restore\", \"SOBR\", \"Veeam ONE\", \"Veeam Recovery Orchestrator\", \"4-eyes authorization\"."
license: MIT
---

# Veeam Data Platform

This skill covers Veeam Data Platform, covering Veeam Backup & Replication (VBR) v12.x and v13.x. It has deep knowledge of Veeam's architecture, hardening capabilities, and ransomware resilience features.

## How to Approach Tasks

When you receive a request:

1. **Classify the request type:**
   - **Architecture / design** -- Load `references/architecture.md`
   - **Hardening / security** -- Load `references/best-practices.md`
   - **Troubleshooting** -- Apply component knowledge directly, check architecture reference
   - **Recovery** -- Apply recovery workflow with product-specific steps
   - **Configuration** -- Provide specific UI paths and PowerShell/REST API examples

2. **Identify the Veeam version** -- v12.0, v12.1, v12.3 LTS, or v13. Some features differ between versions. v12.3 is the current LTS release.

3. **Load context** -- Read relevant reference file for deep knowledge.

4. **Provide specific guidance** -- Veeam has granular configuration options; be specific about settings, not generic.

## Architecture Overview

Veeam Backup & Replication consists of several components. See `references/architecture.md` for full detail.

**Core components:**
- **Backup Server**: Central management, job orchestration, catalog/database (PostgreSQL in v12+, SQL Server legacy)
- **Backup Proxy**: Data mover -- reads from source, processes (dedupe/compress), writes to repository
- **Backup Repository**: Storage target for backup files (.vbk full, .vib incremental, .vrb reverse incremental)
- **Scale-Out Backup Repository (SOBR)**: Performance tier + capacity tier + archive tier abstraction
- **Veeam ONE**: Monitoring, reporting, and alerting platform
- **Veeam Recovery Orchestrator (VRO)**: DR automation and orchestration

## Hardened Linux Repository

The Hardened Linux Repository is Veeam's primary mechanism for immutable on-premises backup storage.

### Setup Requirements

**OS requirements:**
- Supported distros: Ubuntu 22.04/20.04 LTS, RHEL/CentOS/Oracle Linux 8.x/9.x, SLES 15 SP4+, Debian 11/12
- Dedicated server -- no other workloads
- XFS filesystem recommended (supports `reflink` for fast cloning)
- No GUI; minimal OS installation

**SSH hardening (critical):**
- Veeam connects via SSH only during initial configuration (deploying the transport component)
- After setup: disable SSH or restrict to management IP only -- Veeam does NOT need SSH for backup jobs
- Remove SSH host keys from the Veeam Backup Server credentials store after deployment
- The hardened repo uses a dedicated, single-use credential set for the transport component

### Immutability Configuration

In Veeam console, when adding the Linux repository:

```
Repository Settings > Advanced > Make recent backups immutable for [X] days
```

**How immutability works:**
1. Veeam transport component runs as a dedicated local user
2. Backup files are written and then flagged with `chattr +i` (immutable bit)
3. Even root cannot delete files with `chattr +i` without first removing the flag
4. The Veeam transport user does NOT have permission to remove `chattr +i`
5. Only the Veeam Backup Server can remove the flag at retention expiry

**Immutability period best practices:**
- Set immutability period = retention period (e.g., 30-day retention = 30-day immutability)
- Add buffer: set immutability period slightly longer than retention to handle in-progress jobs
- Minimum recommended: 30 days (covers typical ransomware dwell time)

### Single-Use Credentials

In v12+, Veeam supports single-use credentials for the hardened repository:
- A unique credential set is generated per Veeam Backup Server connection
- Credential cannot be reused from a different Veeam server
- Prevents attackers from using stolen Veeam credentials to delete backups from a different system

## Object Storage Integration

Veeam supports S3-compatible, Azure Blob, and Google Cloud Storage as backup repositories (direct) or SOBR capacity/archive tiers.

### Immutability on Object Storage

**AWS S3:**
- Enable S3 Object Lock on the bucket before adding to Veeam
- Choose Compliance mode (not Governance) for true ransomware protection
- Veeam automatically sets the Object Lock retention when writing backup files
- Veeam version must match supported configuration -- check Veeam KB for bucket policy requirements

**Azure Blob:**
- Enable immutable blob storage policy (time-based retention)
- Policy must be locked (cannot be shortened once locked)
- Veeam writes to the container; immutability is enforced by Azure at the storage layer

**Configuration path:** `Backup Infrastructure > Add Repository > Object Storage > [Provider] > Enable Object Lock/Immutability`

### Capacity Tier and Archive Tier

Scale-Out Backup Repository tiers:
- **Performance tier**: Fast local storage (SAN, DAS) -- recent backups for fast recovery
- **Capacity tier**: Object storage -- older backups, cost-efficient, can be immutable
- **Archive tier**: Cold object storage (Glacier, Azure Archive) -- long-term retention

Offload policies:
- Move: Copies to capacity tier, removes from performance tier after [X] days
- Copy: Copies to capacity tier, retains on performance tier (redundancy)

For ransomware resilience, use **Copy** mode to maintain local + cloud copies, both immutable.

## 4-Eyes Authorization

4-eyes authorization requires two Veeam administrators to approve certain operations before they execute. This prevents a single compromised admin account from deleting backups.

### Enabling 4-Eyes Authorization

`Menu > Configuration > Security > Enable 4-eyes authorization`

**Protected operations:**
- Deleting backup jobs
- Disabling backup jobs
- Deleting backup files or restore points
- Modifying retention policies
- Removing repositories
- Deleting virtual machines from backup jobs

**How it works:**
1. Admin 1 initiates a protected operation
2. Operation is queued, pending approval
3. Admin 2 (different account) reviews and approves or denies
4. Veeam logs both the request and approval with timestamps

**Best practice:** Configure 4-eyes with distinct AD accounts for the two approvers. Do not allow the same person to hold both approver roles.

## Secure Restore

Secure Restore mounts a backup in a sandbox environment and scans it with an antivirus engine before completing the restore. This detects malware in backups before it re-enters production.

### How Secure Restore Works

1. Veeam mounts the backup to a helper VM (Windows host with AV software)
2. The AV engine (Windows Defender, Kaspersky, Symantec, etc.) scans the mounted filesystem
3. If threats are found: Veeam logs the findings; restore is blocked or proceeds with warning (configurable)
4. If no threats found: Restore completes normally

### Configuration

`Restore Wizard > Restore Options > Secure Restore > Scan with antivirus software before restore`

**Settings:**
- Select the antivirus engine and update policy
- Choose behavior on threat detection: abort restore or continue with warning
- Define which restore types trigger Secure Restore (entire VM, guest files, application items)

**Limitations:**
- Secure Restore detects known malware; YARA rules or custom IOC scanning is not native to Veeam
- Scanning adds time to restore; factor into RTO calculations
- AV engine must have up-to-date definitions
- For advanced threat hunting (YARA, IOC matching), consider Rubrik or Cohesity platforms

## SureBackup (Backup Verification)

SureBackup automatically recovers VMs from backup into an isolated virtual lab and runs verification tests. This is the "0 errors" component of 3-2-1-1-0.

### Architecture

**Virtual Lab**: An isolated network environment (internal-only virtual switch) where VMs are recovered for testing. The lab includes:
- Isolated virtual switches (VMs can communicate internally but not reach production)
- IP masquerading (same IP as production but isolated)
- Optional: DNS proxy for name resolution within the lab

**Application Group**: VMs that SureBackup depends on (domain controllers, DNS servers) -- started first in dependency order.

**SureBackup Job**: Defines which backup jobs to verify, verification tests, and scheduling.

### Verification Tests

| Test | Description | Default Timeout |
|---|---|---|
| Heartbeat test | VM starts and VMware Tools reports running | 300 seconds |
| Ping test | VM responds to ICMP ping | 300 seconds |
| Application test | Veeam connects to application port and validates response | Varies by app |
| Custom script test | User-defined PowerShell/script that returns 0 for pass | Configurable |

**Application-specific tests (built-in):**
- Active Directory (LDAP query to DC)
- Exchange (MAPI/SMTP connectivity)
- SQL Server (TCP 1433 connectivity + query)
- SharePoint (HTTP response check)
- Oracle (TNS listener check)
- Web (HTTP/HTTPS response code check)

### SureBackup Configuration

`Jobs > SureBackup > Create Job`

Key settings:
- **Virtual Lab**: Select or create isolated lab
- **Application Group**: Add dependency VMs (DCs, DNS) that start before the test VMs
- **Linked Jobs**: The backup jobs to verify
- **Verification settings**: Which tests, timeout, behavior on failure (continue or abort)
- **Schedule**: Weekly minimum recommended; daily for Tier 0 systems

## Veeam ONE Monitoring

Veeam ONE provides monitoring, alerting, and reporting for Veeam infrastructure.

### Key Backup Security Alarms

| Alarm | Trigger | Ransomware Relevance |
|---|---|---|
| Backup job failure | Job did not complete successfully | Early warning: attackers may disable jobs |
| No recent backups | VM not backed up in > [threshold] days | Backup suppression by attacker |
| Malware detected by Secure Restore | AV found threat in backup | Direct detection |
| Repository capacity warning | Repository > 80% full | Could indicate ransomware-induced data explosion |
| Unusual network activity | High outbound from backup server | Data exfiltration indicator |

### Reports for Audit/Compliance

- **Backup infrastructure configuration report**: Documents all repositories, jobs, and immutability settings
- **Recovery verification report**: SureBackup results over time
- **Data protection assessment report**: Coverage gaps (VMs with no backup job)
- **Backup job history**: Audit trail of job executions and outcomes

## PowerShell / REST API

Veeam provides full automation via PowerShell module (VeeamPSSnapin) and REST API (v12+ unified REST).

### Key PowerShell Operations

```powershell
# Connect to VBR server
Connect-VBRServer -Server "vbr-server.corp.local"

# List all backup jobs with immutability status
Get-VBRBackupJob | Select-Object Name, JobType, ScheduleOptions

# Check repository immutability settings
Get-VBRBackupRepository | Select-Object Name, IsImmutabilityEnabled, ImmutabilityPeriod

# Get SureBackup job results
Get-VBRSureBackupJob | Get-VBRSureBackupSession | Select-Object JobName, Result, CreationTime

# List restore points with age
Get-VBRRestorePoint | Select-Object VMName, CreationTime, IsConsistent | Sort-Object CreationTime
```

### REST API (v12+)

Base URL: `https://[vbr-server]:9419/api/v1`

Key endpoints:
- `GET /jobs` -- List all backup jobs
- `GET /repositories` -- List repositories with immutability config
- `GET /backupObjects/{id}/restorePoints` -- List restore points for a backup object
- `POST /restorePoints/{id}/vm/instantRecovery` -- Start instant VM recovery

## Common Configurations and Gotchas

### Gotcha: Backup Server Credentials

The Veeam Backup Server stores credentials for all managed infrastructure (ESXi hosts, backup repositories, cloud providers). If an attacker compromises the Veeam Backup Server, they have access to all stored credentials.

**Mitigations:**
- Restrict RDP/console access to VBR server (jump host, MFA)
- Enable 4-eyes authorization (requires two accounts to delete backups)
- Use a hardened Linux repository with single-use credentials (stolen VBR creds cannot directly delete)
- Back up the VBR configuration database itself (VeeamConfigBackup)

### Gotcha: SOBR Capacity Tier Offload Timing

When using SOBR with Copy mode to object storage, there is a window between backup creation and offload to the capacity tier. If ransomware strikes during this window, the only copy is the performance tier.

**Mitigation:** Set capacity tier offload to trigger immediately (or within hours), not on a delayed schedule.

### Gotcha: Immutability vs. Retention

Immutability period and retention period are separate settings. If immutability period < retention period, backups can be deleted before the retention window expires.

**Rule:** Immutability period ≥ retention period.

## Reference Files

- `references/architecture.md` -- Veeam component internals: backup server, proxy, repository types, SOBR, WAN accelerator, Enterprise Manager, object storage integration, and data flow during backup and restore operations.
- `references/best-practices.md` -- Veeam security hardening: immutable backup setup, 4-eyes authorization, encryption, Secure Restore configuration, SureBackup scheduling, capacity tier policies, and ransomware resilience architecture.