← Beta Society Projects
← Veeam
Veeam · Jul 15, 2026

Moving to v13.1, Part 1: Sketching the Move

This is the start of a full series on moving Veeam Backup & Replication from v13 on Windows to the v13.1 Software Appliance: a map you could follow in production, proven first in my Everpure lab. We start with the sketchpad, because the design conversation turned out to be interesting on its own.

The JeOS family, briefly

The headline of v13 is that Veeam no longer needs a Windows Server underneath. What makes that work is Veeam JeOS (“just enough OS”): a minimal, Veeam-managed Linux distribution built on Rocky Linux, shipped as a bootable ISO, pre-hardened to DISA STIG standards. You don’t patch it, tune it, or log into it. Veeam manages the OS; you manage backups.

Two appliances are built on that base:

The Veeam Software Appliance (VSA) is the command center. It runs the backup server itself, managed entirely through a web console. This replaces the Windows VBR server. One honest note: the web console doesn’t cover everything yet, and a few features still want the Windows console client installed on a workstation. Malware detection is the example I hit first. That’s a client app on your laptop, not a Windows server in the design, but plan for it.

And speaking of malware detection: keep an eye out for a separate post on the Veeam and Everpure workflow integration, which wires Everpure’s anomaly detection into Veeam’s dashboard. Storage and backup agreeing on when something smells wrong is a story worth its own write-up, and I’m happy to share how it’s built.

The Veeam Infrastructure Appliance (VIA) is the execution unit. Same JeOS base, but it deploys as a role: backup proxy, mount server, or hardened repository. Minimum footprint is small (2 cores, 8 GB RAM), so you can stamp these out wherever the architecture calls for a component.

The punchline: every box in a Veeam design can now be a locked-down appliance. No hand-built Linux servers, no Windows anywhere, nothing to babysit at the OS layer. If you have read my Leaving Squarespace series, you know this philosophy is exactly my speed: each piece does one job, and the pieces you don’t manage can’t break at 2am.

Map one: the classic production shape

Veeam v13.1 production architecture with hardened repositoryAdmin browserVeeam appliance (VSA)v13.1 control planeEverpure labVMware hostsprotected VMsPure FlashArrayarray snapshotsBackup proxiesVIA · Linux data moversHardened repoimmutable primaryObject storageoffsite copy tierVeeam appliancesbackup storagebackup datamanagement

This is the shape most shops will recognize: the VSA as control plane, VIA proxies close to the data, a hardened repository as the immutable primary landing zone, and object storage as the offsite copy tier. The hardened repo is the star. It’s a Linux box where backups physically cannot be deleted during the immutability window, and with the VIA it’s now a supported appliance role rather than a DIY hardening project.

One honest caveat for lab builders: a hardened repository earns its name when it’s physical. Virtualize it and a hypervisor admin can still delete the whole VM, immutability and all. In production, put it on iron.

Map two: what I’ll actually run in the Everpure lab

Veeam v13.1 all-appliance object-first architectureAdmin browserVeeam appliance (VSA)v13.1 control planeEverpure labVMware hostsprotected VMsPure FlashArrayarray snapshotsProxy applianceVIA · JeOS locked downObject repositoryS3 · Object LockOffsite bucketcopy job · second S3Veeam appliancesobject storagebackup datamanagement

My lab doesn’t have spare iron for a physical hardened repo, so map two goes object-first: the VIA proxy writes straight to an S3 object repository with Object Lock immutability, and a copy job sends a second copy to a different bucket offsite. The bucket must be created with versioning and Object Lock enabled from day one; Veeam handles the retention flags from there.

Same 3-2-1 skeleton, different immutability engine: filesystem in map one, Object Lock in map two. Which one you pick comes down to what storage you own. If your object platform is something like FlashBlade with SafeMode, object-first is a feature. If your S3 is a budget cloud bucket, restore speed becomes the caveat, and you should test it before you trust it.

What’s coming

The full series, “Moving to v13.1,” walks the whole move: the production map, this architecture in depth, the migration itself (spoiler: config restore from Windows to the appliance is not supported, so it’s a real migration project), day 2 in the web console, and the restore tests that prove it. Every step runs for real in the Everpure lab before it goes in the map.

If you’re planning the same move, these two sketches are the conversation to have with your team first. Pick your map before you touch anything.