Setting Up Veeam v13 with Scale Computing HyperCore: A Complete Integration Guide

Background: HyperCore and the Veeam Integration

Scale Computing HyperCore is a hyperconverged infrastructure platform built for simplicity and edge deployments. It runs KVM under the hood but presents a tightly integrated management layer where storage, compute, and virtualization are managed as a single system through the SC//HyperCore web interface and API. No separate vCenter-equivalent, no separate storage management plane. That design makes it attractive for remote offices, retail environments, manufacturing floors, and any scenario where full-time IT staff aren't on site to manage a complex infrastructure stack.

Veeam's plug-in for HyperCore brings the same worker-based backup architecture to these environments that's used for AHV, Proxmox, and oVirt KVM. The integration point is the HyperCore cluster API, not individual nodes, and everything flows through Veeam workers deployed directly into the cluster. The result is agentless VM backup and recovery managed entirely from the VBR console, with the full Veeam restore catalog available for HyperCore workloads.

Architecture: How the Plug-in Works

The plug-in connects VBR to the HyperCore cluster via the cluster's REST API. Veeam deploys Linux-based worker VMs into the HyperCore cluster. Those workers handle snapshot orchestration and data transfer during backup and restore sessions. Workers communicate with backup repositories using the standard Veeam Data Mover protocol. Firewall rules between the cluster, workers, and backup server are created automatically by Veeam during worker deployment.

One architectural detail that's specific to HyperCore workers: each concurrent backup task requires a dedicated VIRTIO virtual drive on the worker VM, plus one additional VIRTIO drive used by the worker system itself. This means a worker configured for 4 concurrent tasks needs 5 VIRTIO drives attached (4 for tasks, 1 for the system). The maximum number of parallel tasks across a HyperCore deployment is 25. Workers must be configured to handle a minimum of 2 concurrent tasks. Setting a worker to 1 concurrent task causes it to sporadically power on and off when a job contains 2 or more VMs, which is a confirmed known issue in v13.

System Requirements and Prerequisites

Important Note for Linux VBR 13.0.0 Upgrades

Step 1: Verify the Plug-in Is Installed

Open the VBR console and check Help > About to confirm the HyperCore plug-in is listed. If it is absent, install it manually from the VBR installation media or the Veeam downloads page. The plug-in ships pre-installed with fresh VBR v13.0.1 installations. Linux appliance upgrades from 13.0.0 are the exception noted above.

Once the plug-in is present, you will see Scale Computing HyperCore as an available server type under Backup Infrastructure > Managed Servers, and HyperCore will be available as a workload type in the backup job wizard.

Step 2: Configure a Backup Repository

Configure the backup repository where HyperCore VM backups will be stored. Any VBR-supported repository works. Two things to plan for:

Do not use a Veeam Cloud Connect repository as your primary target. Cloud Connect repos cannot serve as the primary backup target for HyperCore jobs. You can use them for backup copy jobs. Primary backups must go to a local or network repository.

If you plan to use a SOBR, target it directly from the start. If you add an existing repository to a SOBR as an extent after HyperCore backup jobs are already writing to it, those jobs will fail. The fix is to edit the jobs to target the SOBR directly. Avoid the problem by targeting the SOBR from job creation if your storage architecture uses one.

Step 3: Connect the HyperCore Cluster

In the VBR console, go to Backup Infrastructure > Managed Servers, right-click, and select Add Server. Choose Scale Computing HyperCore from the list.

After the wizard completes, the HyperCore cluster appears under Managed Servers with a green status. The VM inventory populates in the VBR console under Inventory > Virtual Infrastructure > Scale Computing HyperCore. Inventory changes in the HyperCore environment take up to 15 minutes to sync. Rescan the cluster to force an immediate update.

Step 4: Deploy Workers

Right-click the HyperCore cluster in Managed Servers and select Manage Workers. Click Add to define a worker.

Step 5: Create a Backup Job

In the VBR console, click Backup Job on the ribbon, select Virtual Machine, and choose Scale Computing HyperCore as the workload type.

Step 6: Configure Backup Copy Jobs

HyperCore deployments are frequently used in edge locations where the backup server and primary repository are also on-site. For these environments, an offsite backup copy is particularly important: a site-level failure (power, flooding, theft) that takes down the HyperCore cluster will also take down any local-only backup data.

Create a backup copy job targeting a secondary location: a repository at a central data center, an object storage target, or a Veeam Cloud Connect cloud repository (which is a valid backup copy target even though it cannot serve as the primary target). Configure the copy job to run on a schedule after the primary backup job completes.

Restore Operations

Veeam Plug-in for Scale Computing HyperCore supports a broad set of restore operations in v13.

Entire VM restore recreates the VM in the HyperCore environment from a selected restore point. You can restore to the original cluster and node or to a different cluster. If you restore a VM from a VMware, Hyper-V, oVirt KVM, or Proxmox VE backup to HyperCore, install Scale Guest Tools on the restored VM to resolve potential network connection issues that arise from the cross-platform restore.

Instant Recovery of HyperCore VMs is supported to VMware vSphere, Microsoft Hyper-V, and Nutanix AHV. Note that Instant Recovery back to HyperCore itself is not listed as a supported target in the current v13 documentation. For rapid recovery back to HyperCore, use entire VM restore.

File-level restore mounts the VM's backup disks and allows individual file and folder recovery. Available for supported Windows and Linux guest filesystems.

Application item restore for Microsoft Active Directory, Exchange, SharePoint, Oracle Database, and SQL Server is supported from HyperCore VM backups. This requires the relevant Veeam Explorer to be installed on the backup server.

Disk export to VMDK, VHD, and VHDX formats is supported for cross-platform migration and lab recovery use cases.

Restoring from archive tier: if the restore point is stored in the archive tier of a SOBR, you must first retrieve the backup data before restoring. Entire VM restore from backups stored in an Amazon S3 Glacier Instant Retrieval archive extent is not supported. For those backups, use Instant Recovery instead.

Limitations Worth Knowing

Closing Thoughts

HyperCore's appeal is its simplicity, and the Veeam integration extends that simplicity to the backup side: one plug-in, one cluster connection, workers deployed automatically, full restore capability managed from the same VBR console you use for everything else. For organizations running HyperCore at the edge alongside VMware or Hyper-V at a central data center, being able to manage protection for all of it from a single VBR instance is a genuine operational advantage.

The limitations table above is longer than most, but most of those limitations are edge cases that don't affect typical deployments. The ones worth keeping front of mind are the application-aware processing gap (plan your application backup strategy separately), the NAT gateway requirement (no NAT, direct IP only), and the concurrent task minimum (never set workers to 1). Get those three right at the start and the rest of the deployment is straightforward.

The VIRTIO drive requirement per concurrent task is unique to HyperCore compared to the other non-VMware plug-ins. It's not difficult to work around, but it does mean your worker sizing math needs to account for available VIRTIO drive slots on the worker VM, not just CPU and RAM. Check that before deploying workers into clusters where storage attachment limits might be a constraint.