VBR 13.1: VSA and VIA - what changed in practice

I have been following VSA and VIA since the release of VBR 13. The first version established the direction, but real projects quickly exposed limitations around storage, data transport and ongoing operations. Version 13.1 removes several of those gaps.

VSA and VIA both use Veeam JeOS, but they serve different purposes. Treating them as one appliance deployed through one common procedure is a design mistake.

VSA and VIA are not interchangeable

Veeam Software Appliance (VSA) is a complete VBR server. Veeam Infrastructure Appliance (VIA) hosts selected infrastructure roles and is added to an existing VBR server after initial configuration.

After deployment from ISO or OVA, the first configuration runs in the Initial Configuration wizard in the TUI. For VIA, this includes selecting an appliance profile such as Infrastructure Server, iSCSI & NVMe/TCP or Hardened Repository. System settings - networking, time, users, certificates, storage and updates - are then managed through Host Management Web UI or the TUI.

Only after this step is a VIA added to VBR and assigned the required infrastructure roles. Backup jobs are configured in the VBR console or, within its supported scope, in the VBR Web UI. Attaching a disk in Host Management does not create a repository. Selecting a VIA profile also does not automatically assign the proxy, WAN Accelerator or Cloud Gateway role.

Improvements shared by the appliance platform

The 13.1 appliance work is wider than one headline feature. It includes storage expansion, FC and iSCSI attachment, multipathing, more flexible deployment, update improvements and broader Host Management coverage.

The practical distinction is important: attaching a device at the operating system or Host Management layer prepares storage for a later role. VBR still owns the backup infrastructure configuration, repository definition and job placement.

Changes specific to VSA

Additional disks can now be attached to a running VSA. A new device can become another repository and, for example, a new extent in an existing scale-out backup repository. This does not mean an arbitrary in-place extension of an already used LUN or filesystem, and new storage does not become a repository automatically.

What’s New and the dedicated transport documentation describe HotAdd for an all-in-one VSA running on VMware vSphere. This matters when the appliance acts as both the VBR server and a backup proxy. However, the current VSA limitations page still says that only Network transport is supported. I would therefore confirm support for the exact build before production use.

In automatic mode, VSA uses HotAdd when it is enabled in Host Management and the transport is available; otherwise it falls back to Network. Adding local, iSCSI or FC storage to VSA restarts the HotAdd service. Active backup and restore operations using this transport will fail, so the change belongs in a controlled maintenance window.

Unattended VSA deployment has also been extended. Installation can open a time-limited window for connecting VSPC, Veeam ONE or Veeam Recovery Orchestrator, and prepare the VSA for later addition to an HA cluster. This does not register the VSA in a management system automatically and does not configure the cluster by itself.

VSA can automatically increase the internal database space limit when it becomes constrained, and it warns when the underlying volume itself is running out of capacity. A ready-to-deploy VSA image is also available for Hyper-V.

Changes specific to VIA

VIA can be deployed in a Single Disk layout without a separate data disk. This is useful for a proxy that uses a remote repository, or for a VIA with the Hardened Repository profile that will host an Application Backup Repository. In the latter case, the repository can be created at or below /var/lib/veeamdata/backup.

VIA now uses a common boot menu. The Infrastructure Server, iSCSI & NVMe/TCP or Hardened Repository profile is selected later in Initial Configuration.

A VIA using the iSCSI & NVMe/TCP profile can act as a VMware backup proxy using Direct SAN over FC or iSCSI. Production VMFS LUNs must be visible to the proxy, but they must not be formatted or added in Host Management as repository storage. The LUN remains the source VMware datastore. Multipathing on the Linux proxy provides path failover but does not load-balance traffic across paths.

That scenario is fundamentally different from attaching a new disk for a repository. Repository storage is added in Host Management and then used to create a repository in VBR. The current limitations also prohibit installing VSA or VIA on a machine that already has multipath devices configured.

Where I would use each option

The additions create several useful patterns:

an all-in-one VSA on VMware acting as VBR server and proxy, where HotAdd may replace part of the Network transport after its build-specific support is confirmed;
a VIA acting as a Direct SAN VMware proxy, with production LUNs presented for data access only;
unattended VSA deployments prepared for later connection to VSPC, Veeam ONE or an HA cluster;
a specialised VIA proxy using a remote repository, or a Single Disk Hardened Repository hosting an Application Backup Repository;
repository capacity growth by adding a new device and explicitly creating a repository or SOBR extent.

A documentation inconsistency that needs a decision

Several current pages describe the same build differently:

What’s New 13.1 and Host Management document the addition of new local, iSCSI and FC devices;
the VSA and VIA considerations and limitations pages, labelled for build 13.1.0.411, still say devices cannot be added or resized after deployment;
What’s New and the HotAdd page describe HotAdd for an all-in-one VSA, while the VSA limitations page for the same build still lists Network as the only transport;
the limitations prohibit installing VSA or VIA on a machine with existing multipath devices, although attaching FC/iSCSI storage and using multipathing later is documented as a new capability.

I read this as a documentation alignment issue, not permission to ignore the restrictive page. For a production design I would record the exact build and obtain confirmation for the intended path, especially where a support case or SLA may depend on it.

Architectural boundaries that remain

A VBR server used by a Veeam Cloud Connect service provider must still run on Windows.
Migrating an existing Windows VBR server to VSA is not supported in 13.1. The Release Notes advise interested customers to remain on the latest 13.0 build and contact Veeam Support before starting such a project.
VSA is not an automatic replacement for every Windows backup server. The decision depends on required features, integrations, licensing and the planned migration path.

How much time to reserve for a VSA or VIA update

Updating a VSA or VIA covers more than Veeam components. Veeam Updater installs operating system and security updates, checks dependencies, restarts services and, when required, reboots the appliance.

A VSA reboot makes Host Management and the VBR Web UI unavailable and disconnects the console from the VBR server. A VIA reboot takes Host Management and the roles on that appliance offline, while the primary VBR server remains available unless the current operation depends on that VIA.

Veeam does not publish one duration that fits all appliance configurations. I reserve a wider window than for an ordinary Veeam component update. Slower disks, constrained CPU and slow package downloads can noticeably extend the operation.

I have already completed several VCC environment upgrades to 13.1. The main VBR servers upgraded without issues. Individual VIAs working as WAN Accelerators or Cloud Gateways needed more attention; in one case I restarted a VIA upgrade manually from Host Management.

The Release Notes document a related but narrower case for a VIA with the WAN Accelerator role: after an upgrade from 13.0 to 13.1, the host may remain Out of Date following a failed operating system update. Veeam recommends running Host Upgrade Wizard again. I would not automatically generalise that note to every Cloud Gateway - that part is a separate field observation.

Before updating, the documentation recommends a configuration backup. In practice, I also verify that the latest configuration backup succeeded, is encrypted and resides outside the VSA being updated. Without encryption, a configuration backup does not include credentials, encryption keys or certificates.

For VIA, this means the configuration backup of the managing VBR server. It is not a full system image of the VIA, so I separately record its profile, network settings, attached storage and assigned roles.

Immediately after upgrading VBR or VSA is not the right time to judge performance. A configuration database optimisation task can run for up to roughly an hour, depending on database size. This does not apply to every standalone VIA.

Minimum pilot checklist

Confirm the exact VBR, VSA/VIA and JeOS builds.
Create and verify an encrypted configuration backup outside the appliance being changed.
For VIA, record its profile, network, attached storage and VBR roles.
Document which devices are repository storage and which are production LUNs exposed only for Direct SAN.
Schedule any storage attachment that restarts HotAdd outside backup and restore sessions.
Create the repository or SOBR extent explicitly after storage is attached.
For Direct SAN, present production LUNs without mounting or formatting them as repository storage, then verify datastore mapping.
Test Network fallback and HotAdd only within the support boundary of the exact build.
Validate a Single Disk VIA layout only for roles that do not require a separate data disk.
Test unattended VSA deployment and then verify the VSPC or Veeam ONE connection during the temporary access window.
Record realistic update and reboot times on representative hardware.
After the update, verify Host Management, Web UI, services, host status, first jobs and any VIA left Out of Date.

What has worked in your environment?

VSA and VIA are deployed on very different infrastructure: local disks, FC arrays, iSCSI, VMware, Hyper-V, constrained Internet links and existing monitoring stacks. A successful installation is only the beginning; the edge conditions reveal more.

I am particularly interested in how teams separate repository devices from production LUNs presented to a VIA only for Direct SAN, whether HotAdd on an all-in-one VSA outperforms Network at their scale, and how much time they reserve for appliance updates.

Sources

Has anyone received a definitive support statement on adding drives and using HotAdd with build 13.1.0.411? Once the documentation is aligned, the result is worth adding directly to the discussion.