Moving to v13.1, Part 2: Architecting the Server, Proxies, and Repos

Part 2 of 8. The two architecture diagrams from Part 1 live here in their full context; lab screenshots will join as the build progresses.

Design before you migrate

The worst time to make architecture decisions is mid-migration. The appliance model in v13 changes enough old defaults that the design deserves a fresh sheet of paper, not a copy of whatever the Windows server had. So before anything moves, this is the target.

The constraint that picks your platform

Here’s the fact that shaped this whole design, and it’s one you won’t find on a datasheet: the plugin I need for the Everpure integration currently runs only on the Linux appliance under Directed Availability. Windows support arrives with 13.1, when Everpure releases the matching plugin. So if you want this integration today, the Linux appliance isn’t a philosophical choice, it’s the only door in. If you’re a Windows shop, your path is to lay this same framework and meet the plugin at 13.1. This series will cover both roads.

And one more requirement that shapes everything downstream: the plugin, from 13.0 Directed Availability and forever after, requires Fusion fleets. Fusion, Pure’s fleet control plane, is part of this architecture, not an optional extra. Since Fusion’s access model is built on SSO and MFA, the identity framework coming in Part 4 isn’t a compliance checkbox. It’s a prerequisite for the integration this whole series is building toward. The secure way forward and the functional way forward are the same road, which is exactly the layered security message Veeam has been preaching.

The backup server: an appliance you don’t log into

The v13 backup server is a hardened, Veeam-managed Linux appliance. You don’t own the OS anymore; you manage Veeam through the web console, and that’s the point. Fewer knobs, smaller attack surface, no patching treadmill for the brain of your backup environment.

If you read my Leaving Squarespace series, you know where I stand on giving up OS access: it’s liberating. I already run my website like a pipeline instead of a platform I log into, and the appliance brings the same posture to backup. The function is the point, not the technology. An OS I can’t touch is an OS I can’t break, and more importantly, one an attacker finds a lot less interesting.

Placement rules that don’t change with the packaging: the backup server is the control plane, so keep it out of the blast radius of what it protects. Don’t run it on the cluster it backs up if you can avoid it, and document how you reach it when the environment is down.

Starting size in my lab: 8 vCPU, 32 GB RAM, 200 GB disk. It’s the brain, not the muscle.

Proxies: close to the data

Proxies are the muscle, so they live near the source. In v13 they’re Veeam Infrastructure Appliances (VIA): the same locked-down JeOS base as the backup server, deployed as a role. No hand-built Linux, no OS to maintain.

Sizing is about concurrency, not peak theory: roughly 1 vCPU and 2 GB RAM per concurrent task, so a 4 vCPU, 8 GB proxy moves about four disks in parallel. I run one in the lab; the production map calls for two, because one proxy is a single point of slow.

The Pure angle matters here. With storage snapshot integration, the proxy reads from FlashArray snapshots instead of hammering the production datastores, and the VMs barely notice the backup window exists. That integration is exactly what the plugin unlocks, which is why the platform constraint above decides so much.

Repositories: where the real decisions live

The repo layout is the part you live with longest. Two shapes, both valid, picked by what storage you own.

Map one: the classic production shape.

A hardened repository as the immutable primary landing zone, object storage as the offsite copy tier. The hardened repo is a Linux box where backups physically cannot be deleted during the immutability window, and the VIA now makes it a supported appliance role instead of a DIY hardening project. The caveat I’ll keep repeating: a hardened repo earns its name when it’s physical. Virtualize it and a hypervisor admin can delete the VM, immutability and all. In production, put it on iron.

Map two: what I’m running in the Everpure lab.

My lab doesn’t have spare iron for a physical hardened repo, so I go object-first: the VIA proxy acts as the gateway and writes straight to an S3 object repository with Object Lock immutability, and a copy job sends a second copy to a different bucket on a different platform. The bucket must be created with versioning and Object Lock enabled from day one; Veeam handles the retention flags after that.

Same 3-2-1 skeleton either way, different immutability engine: filesystem in map one, Object Lock in map two. Pick by what storage you own, and decide your immutability windows now, not after the first scare. I’ll publish my lab’s retention and immutability numbers with the build results in Part 5, once they’ve survived contact with reality.

The second environment: why Windows stays

There’s a box that doesn’t appear in either map above, on purpose: my existing Windows-based 13.0 deployment. It isn’t going anywhere yet, and that’s a design decision, not procrastination.

It stays for three reasons. Some features still live in the Windows console client, so honest coverage of the platform needs a Windows environment to show them. It’s where Part 4 illustrates the SSO story. And until the Linux side has earned production trust and 13.1 brings the Everpure plugin to Windows, it’s both the parachute and the eventual migration source. Two environments, each earning its place, and readers on either platform can follow the road that matches theirs.

What I deliberately did not add

No clustering, even though the appliance supports an active and passive pair as of 13.0.1. In a lab it’s complexity without a payoff, and even in production I’d want the operational story proven before adding a second brain. No extra repo tiers beyond the two copies. No component that can’t justify its 2am failure mode. Same rule as everything I build: each piece does one job.

Where this goes next

This design is the sheet of paper the rest of the series executes against. Part 3 builds 13.0.x on it under Directed Availability, and Part 4 lays the security framework across the whole stack: SSO, MFA, the arrays, and Fusion, the identity groundwork the plugin requires.

Next up, Part 3: Directed Availability, building 13.0.x on the map.