On this journey we'll follow a single file: invoice_2026.pdf, living inside the accounting server SRV-ACCOUNTING. We'll pull it out of the production environment, carry it through every dimension of the Veeam universe, and bring it back alive from a disaster. By the end, you'll understand end-to-end how backup actually works.
Veeam never stops a running VM. Instead it tells the hypervisor (vSphere/Hyper-V), "take a photo of this VM's current state." But before the photo there's a critical step: Application-Aware Processing. A temporary runtime process is sent into the VM and Windows VSS is triggered; applications like SQL, Exchange, and Active Directory bring their disks to a consistent state. That way a database restored from backup doesn't wake up "corrupted" — it wakes up spotless.
The snapshot is ready. Now the Backup Proxy steps in: its Veeam Data Mover service reads, compresses, and deduplicates the data, then sends it to the repository (data channel: TCP 2500–3300). But first there's a decision — which transport mode will the proxy use to reach the VM's disk? Click one:
The proxy connects directly to production storage over FC/iSCSI/NFS. It never touches the ESXi hosts or the production network.
FASTESTThe virtual proxy attaches the VM's disks to itself via SCSI hot-add and reads from the hypervisor I/O stack.
FAST · VIRTUAL PROXYData is pulled over the network through the ESXi management interface. The slowest — but it works in every environment.
UNIVERSAL FALLBACKThe answer: Changed Block Tracking (CBT). The hypervisor keeps a map of which blocks have changed since the last backup. Veeam simply asks, "what changed since yesterday?" — and reads only those blocks. Press the button and see the difference:
The data the proxy sends is written to files in the repository: a full backup .VBK on Sunday, the nightly changes on weekdays as .VIB (increment) files, and the chain's map as the .VBM metadata file. At restore time, Veeam reads this chain to rebuild whichever day you want. Try it yourself — take a few nights of backups:
One full + endless increments. When retention fills, the oldest VIB is merged into the VBK — little space, little I/O. (This is what you just did.)
The most recent point is always a full VBK; older states are written back into .VRB files. Fastest restore, but 3x I/O during the backup.
A periodic new full is synthesized on the repository from the existing chain rather than from production. Production is never strained.
SOBR combines multiple storage devices into a single logical pool and manages the backups' lifecycle automatically. Use the slider below to age invoice_2026.pdf's backup — watch which tier it filters down to:
Fast block storage. Daily operational restores come back from here within seconds.
S3-compatible object storage. With a move/copy policy, backups are moved here automatically — the off-site copy (the "1" in 3-2-1) is created on its own.
S3 Glacier / Azure Archive. The oldest backups are kept in frozen space for years at the lowest cost.
The first target of modern attacks isn't production — it's the backups, because a victim with no backup pays the ransom. Below are two repositories: an ordinary Windows share and a Hardened Repository (Linux + XFS immutability: for a set period the backups can't be deleted or altered, not even by root). Launch the attack and see the difference:
The production server was encrypted, but the chain in the Hardened Repository is intact. Now the critical question: how will you get back? Veeam offers you not one path but options that fit the scenario. Pick one:
The VM is run directly from the backup file — the Mount Service (TCP 9401) publishes the backup like a datastore. You're up in minutes; in the background it's migrated to production via Storage vMotion.
RTO: MINUTESNo need for the whole VM — the backup is mounted and only invoice_2026.pdf is pulled from the file browser. Thanks to the Guest Catalog index, the file is found in a second by search.
SINGLE FILEThe entire VM is rebuilt from the chosen restore point. The cleanest return — it takes a bit longer, and after an attack it's usually done with antivirus-scanning Secure Restore.
FULL REBUILDinvoice_2026.pdf has been recovered. Now let's tie the big picture together — who watches all these dimensions, who manages them?
Manages multiple VBR servers from a single web console (TCP 9443). Federated catalog search finds files across all sites in one query; with the self-service portal users recover their own files themselves — no one gets called at 3 a.m.
The monitoring and reporting telescope: SLA reports, capacity planning, protection-gap analysis, and the ransomware anomaly alarms you just saw.
The current release, v13: a Linux-based hardened Software Appliance, a browser-based Web UI, gRPC communication, BLAKE3 hashing, Kerberos-first, Threat Hunter, and the Veeam Intelligence AI assistant.
| SERVICE | ROLE | PORT |
|---|---|---|
| Veeam Backup Service | Job engine & coordination (VBR) | TCP 9392 |
| Guest Catalog Service | File indexing catalog | TCP 9393 |
| Mount Service | Instant recovery / file restore mount | TCP 9401 |
| Installer Service | Component deployment (all managed servers) | TCP 6160 |
| Transport Service | Proxy/repository component communication | TCP 6162 |
| Data Mover channels | The actual backup data stream | TCP 2500–3300 |
| Enterprise Manager | Web UI & REST API | TCP 9443 |
| PostgreSQL | Configuration DB (v12+ default) | TCP 5432 |