Zero to Protected, Part 1: The Veeam v13 Appliance Model and Building the Backup Fabric

Veeam v13 on a greenfield VMware VVF vSAN 9.1 lab. A five part series.

Part 1: the appliance model and deploying the fabric (this post) · Part 2: assembling the backup infrastructure · Part 3: the first backup and proving immutability · Part 4: storage snapshot integration with HPE Alletra · Part 5: application-aware processing on an all-Linux fabric.

Fair warning: this is the long one. It walks all five appliance deployments screen by screen, 111 screenshots in all, so grab a coffee, maybe a whole pot, and settle in.

Why this series exists

This is the capstone of a Zero-to-VCAP journey. Over the preceding weeks I went from nothing to a fully built, brand new VMware VVF vSAN 9.1 cluster, the whole point of the exercise being to learn the modern VMware stack from the ground up rather than read about it. But once the platform was up and running workloads, the uncomfortable question showed up almost immediately: what actually protects it? A virtualization platform without backups is a very expensive single point of failure, and “I just built this beautiful cluster” is cold comfort the morning a workload goes sideways.

So rather than call the VCAP journey done at the platform layer, I kept going and stood up data protection on top of the fresh foundation, end to end, capturing every screen. This series walks through building a complete, greenfield Veeam Backup & Replication v13 environment from nothing: the new Linux based appliances, two immutable hardened repositories fronted by a scale-out repository, a set of proxies (including one built specifically for storage snapshot integration), HPE Alletra storage integration, and the first protected workload.

One honest caveat before we start: this is a lab, and I built it like one on purpose. In a production deployment you would very likely run the hardened repository and proxies on purpose built hardware appliances. A dedicated hardened-repository appliance gives you immutability with a physically separate root of trust, which is exactly what you want standing between a ransomware actor and your backups. Here, every Veeam role runs as a VM appliance on the same vSAN cluster it is protecting. That is a deliberate trade for a lab: it let me document the entire journey, reproduce it at will, and learn where v13 actually bites. If you are copying this into production, put the immutable tier on separate hardware.

Veeam v13 is a Linux appliance now

Veeam v13 is a real departure from the Windows centric world most of us grew up in. The backup server itself is now a hardened Linux appliance, and the supporting roles ship as a separate appliance image. If you have been running v12 on a Windows Server, unlearn some muscle memory before you start. There is no Windows box to log into, no .exe to run, and no SQL Server to babysit. The whole fabric is a set of hardened JeOS (Just enough OS) Rocky Linux appliances that you configure through an on-console wizard and then manage from a web UI.

That shift has real consequences later in the series (guest processing and storage integration both behave differently than they did on Windows), but at deployment time it mostly means one thing: you deploy appliances, not software.

The two appliances, and why there are two ISOs

v13 splits into two downloadable appliances, and you need both.

The Veeam Software Appliance (VSA) is the full backup server: a hardened JeOS Linux build with Veeam Backup & Replication, its configuration database, and the web UI baked in. You deploy exactly one of these. In this build it is dc1-bkp-veeam01 at 10.11.13.20. It is the large image, roughly 10 GB, and it takes noticeably longer to deploy than the others.

The Veeam Infrastructure Appliance (VIA) is a lighter, pre-hardened JeOS image that installs only an infrastructure role, either a hardened repository or a VMware backup proxy. There is no backup server inside it. You deploy one VIA per role instance, so in this environment that is four of them at the outset: two hardened repositories (dc1-bkp-vhr01, dc1-bkp-vhr02) and two proxies (dc1-bkp-prxy01, dc1-bkp-prxy02). A fifth VIA, a special iSCSI capable proxy, shows up in Part 4.

Both ISOs run the identical ten step initial configuration wizard, and both create the same two accounts. The only thing that changes between them is which product you select on the boot menu.

Two ISO checks worth doing before you boot anything

Two easy traps live right here at the staging step, and both are cheap to avoid.

The first is version skew. Veeam expects the backup server to run at or above the version of the infrastructure components it manages, so you want the Software Appliance and Infrastructure Appliance on the same build before you deploy anything. Here both land on 13.0.2.29, which satisfies the requirement. If yours do not match, pull the correct Software Appliance ISO, or plan to update the backup server up to the components’ version before you pair any of them.

The second is upload integrity, and it bit me. My first Software Appliance re-upload to the datastore reported “operation failed” with zero bytes transferred, yet still left a file behind. That file was about 685 MB where a valid Software Appliance ISO is roughly 10 GB. A truncated image passes a glance but fails the install later with a much more confusing error. Before you boot the install, glance at the file size on the datastore and confirm it is in the right ballpark (the Infrastructure Appliance is about 1.8 GB, the Software Appliance about 10 GB), and verify the checksum if you have it. Thirty seconds here saves a baffling failed install later.

The environment

Five VMs to start, all with DNS A-records already in place under e360demo.com. Confirm forward and reverse resolution for every name before you boot anything. The appliances want FQDNs, and the certificate based pairing you will use in Part 2 is name sensitive. Get this wrong and you will chase phantom failures during registration.

Role	Hostname	IP	Appliance
Backup server (VBR)	dc1-bkp-veeam01	10.11.13.20	Software Appliance
Hardened repository 1	dc1-bkp-vhr01	10.11.13.21	Infrastructure Appliance
Hardened repository 2	dc1-bkp-vhr02	10.11.13.22	Infrastructure Appliance
VMware proxy 1	dc1-bkp-prxy01	10.11.13.23	Infrastructure Appliance
VMware proxy 2	dc1-bkp-prxy02	10.11.13.24	Infrastructure Appliance

Sizing the VMs

Right-size before power-on rather than resizing later. The backup server wants 8 vCPU and 16 GB of RAM as a floor (6 vCPU is acceptable for five or fewer workloads), plus roughly 500 MB of RAM per concurrent job, on two disks of at least 240 GB each. Each proxy needs a modest 2 vCPU and starts from the VIA base of 8 GB RAM on two 120 GB disks, scaling up with concurrent tasks. Each hardened repository takes the same 2 vCPU and 8 GB VIA base on two 120 GB system disks, plus the actual backup capacity disks, which you should present now.

Two details trip people up here. First, on these appliances any additional disks you present get automatically absorbed into an LVM spanned volume behind the second system disk, so present your repository capacity deliberately. Second, and this is the one that actually stopped my install: the VIA installer refuses to proceed with a single disk. Build every VIA VM with at least two disks (a system disk and a data disk) before first boot, or the Anaconda installer aborts with “At least 2 disks are required” and you get to power off, add a disk, and start over.

And the hardened repository must sit on block storage, no NFS or SMB mounted volumes, because immutability relies on filesystem attributes that network mounts cannot guarantee. XFS is the filesystem of choice for its block cloning (Fast Clone) support, which Part 2 leans on.

The two accounts you create on every appliance

Every appliance, all five of them, creates the same pair of accounts during install.

veeamadmin is the host administrator, your day-to-day admin identity in the Host Management console. Its multi-factor authentication is enrolled inline during installation: the wizard shows you a QR code, you scan it into an authenticator app, and you confirm with a one-time code before you can continue.

veeamso is the security officer, a separate identity that approves sensitive and destructive operations, giving you a second pair of hands against a compromised admin account. Unlike veeamadmin, its MFA initializes at first login rather than during install.

Both accounts share a strict password policy: at least 15 characters, with an uppercase, a lowercase, a number, and a special character, and no more than four characters of the same class in a row.

Two warnings that will save you a rebuild:

First, do not skip the security officer account. The wizard lets you skip it, but the only way to add it afterward is to reinstall the appliance from scratch. On the hardened repositories it is stricter still: the veeamso account has to be initialized before you can even add the repository to the backup server. Set it on all five appliances, no exceptions.

Second, MFA lives and dies by the clock. Because veeamadmin‘s MFA is time based, clock drift between the appliance and your authenticator will lock you out. Configure NTP properly during setup, before you enroll MFA. The wizard defaults to a single time.nist.gov server, and you want at least three.

Deploying an appliance, screen by screen

The wizard is identical across all five appliances. The only difference is the product and role you pick at the boot menu. Here is that flow end to end on each appliance, in the order they were deployed: the backup server first, then the hardened repositories, then the proxies.

1. Boot and product selection. Power on the VM with the ISO attached. At the JeOS boot menu, pick the role: Veeam Hardened Repository for the two VHR boxes, Veeam Backup Proxy for the two proxy boxes, or Veeam Software Appliance for the backup server. Then choose Install for a fresh deployment.
2. Rocky Linux base install. Confirm the disk wipe. The hardened base lays itself down unattended. (This is the step that fails immediately if the VM has only one disk.)
3. Initial Configuration wizard. The on-console wizard sets hostname, network, time, and the two accounts. Set the hostname to the FQDN (for example dc1-bkp-vhr01.e360demo.com), configure networking as static with your DNS resolvers, and do not rush the time step. It explicitly governs MFA and job scheduling: set the time zone, add three or more NTP servers, and sync the clock before you enroll veeamadmin‘s MFA. Then configure veeamadmin (set the password, scan the MFA QR code, confirm the one-time code) followed by veeamso.
4. First boot and Security Officer initialization. After services restart, the appliance shows its Host Management URL on port 10443. Browse to it, accept the self signed certificate, and log in as veeamso to initialize the security officer: set a new password, enroll its MFA, and capture the recovery token. Store that recovery token in a secrets vault. It is the only way back into the security-officer account if MFA is lost.

Work through the appliances in order. In this build that meant the backup server (dc1-bkp-veeam01, the big 10 GB image), then the two hardened repositories (dc1-bkp-vhr01, dc1-bkp-vhr02), then the two proxies (dc1-bkp-prxy01, dc1-bkp-prxy02). The backup server also exposes the VBR web UI on port 443 in addition to the Host Management console on 10443; the infrastructure appliances only have the console.

The backup server (Software Appliance)

Start with the backup server. The Software Appliance runs the identical wizard, with a few differences worth seeing: it is the large image, its Security Officer initialization adds a Configuration Backup passphrase step the infrastructure appliances do not have, and it is the only appliance that exposes the VBR web UI on port 443. It is also where the license goes.

The first hardened repository (dc1-bkp-vhr01)

With the backup server up, deploy the two hardened repositories. Here is the full walkthrough on dc1-bkp-vhr01, the reference build: the same wizard as the server, with Veeam Hardened Repository selected at the boot menu.

The second hardened repository (dc1-bkp-vhr02)

The same Hardened Repository role as vhr01, on a fresh appliance. The wizard is identical, so this is the condensed version.

The first proxy (dc1-bkp-prxy01)

Same wizard, but at the boot menu you pick the Infrastructure Appliance in its Backup Proxy role instead of Hardened Repository. Note in Part 4 that this standard proxy variant is not the one that can back up from storage snapshots.

The second proxy (dc1-bkp-prxy02)

Identical to prxy01, one address higher.

Where this leaves us

At the end of Part 1 you have five hardened Linux appliances running and reachable, each with its own veeamadmin and veeamso accounts, MFA enrolled, and recovery tokens stored. What you do not have yet is a backup fabric: the appliances do not know about each other. None of the proxies or repositories are registered with the backup server, there is no scale-out repository, and vCenter has not been added as a source.

That assembly is Part 2, where certificate based pairing replaces the old stored-SSH-credentials model, the hardened repositories get their immutability window, and the two repos become a single scale-out destination.

Next: Part 2, Assembling the Backup Infrastructure.

Veeam documentation

• About Veeam Backup & Replication (v13 User Guide)
• Backup infrastructure system requirements
• Using a Veeam Infrastructure Appliance as a hardened repository

Technical detail verified against the Veeam Backup & Replication v13 User Guide (build 13.0.2.29): Software and Infrastructure Appliance ISO install, system requirements, and used-ports documentation.