My Veeam Backup & Replication Project — From Trial Download to Monitored Backups (and an ESXi Bonus Round)

A beginner-friendly, hands-on walkthrough of standing up Veeam Backup & Replication end to end on a single lab server — concepts, trial setup, agent vs agentless, protection groups, the LVM snapshot error that broke my first job, firewall gotchas, restore testing, Veeam ONE monitoring and alarms, and a bonus ESXi VM-backup phase. My Veeam Backup & Replication Project — From Trial Download to Monitored Backups As part of my infrastructure showcase , I was given a fairly open-ended task: stand up Veeam Backup & Replication (VBR) from scratch and get a working, monitored backup environment running. No prior Veeam experience, no existing lab — just a blank slate and the trial edition. The lab ended up looking like this: 1 Windows Server doing triple duty as the Veeam Backup Server, the Backup Repository, and the Veeam ONE monitoring host — all on one ~700GB box 4 Linux clients (RHEL/Rocky/AlmaLinux) backed up with the Veeam Agent for Linux Later, a VMware ESXi host added on top, to get hands-on with agentless VM-level backup too This post documents the whole journey: what backup actually means and why it matters, how I got Veeam onto a test box, the agent vs. agentless decision, setting up protection groups (including the firewall issue that broke it), the LVM snapshot error that forced a change of backup mode, restore testing, reporting, Veeam ONE monitoring with alarms, and finally a bonus phase connecting a licensed ESXi host for VM backup and restore. Why backup even matters Before touching any software, it's worth being clear on why this whole exercise exists. A backup is simply a copy of your data (and sometimes your entire system) stored somewhere separate from the original, so that if something goes wrong — hardware failure, accidental deletion, ransomware, a bad update, a full server dying — you can restore and keep operating instead of losing everything. The classic argument for backup boils down to a few failure scenarios that happen to everyone eventually: Hardware failure — disks die, servers crash, and RAID isn't a backup strategy on its own. Human error — someone deletes the wrong folder, overwrites the wrong file, or fat-fingers a config change. Ransomware/malware — increasingly the #1 reason organizations lose data they can't get back, especially if backups themselves aren't protected. Software or update failures — a bad patch or corrupted database that isn't caught immediately. Without backups, any one of these can mean permanent data loss. With backups — and, just as importantly, tested backups — the same event becomes a recovery task measured in minutes or hours instead of a catastrophe. Veeam is one of the major players in this space, offering both backup and replication (keeping a warm standby copy of a VM ready to fail over to) for physical machines, virtual machines, and cloud workloads. Getting Veeam: creating an account and downloading the trial Veeam doesn't let you just grab an installer anonymously — you need an account first: Head to veeam.com and register for a free account (this doubles as your Veeam ID, used for licensing and support). Once registered, I could access the download center and grab the Veeam Backup & Replication installer. Community Edition is free and fine for a basic/proof-of-concept setup — it supports up to 10 workloads free — but registering also auto-activates a 30-day trial license, which unlocks the full enterprise feature set so you can evaluate everything before deciding what to license. This trial license is also why, near the end of this project, I started seeing expiry warnings pop up in the console — more on that later. Prerequisites checklist (worth confirming before you start) Local administrator credentials on the Windows server; root or a sudo-capable account (with SSH access) on the Linux clients .NET Framework and Windows updates current on the server (both the VBR and Veeam ONE installers will flag anything missing) The Windows server should comfortably clear Veeam ONE's minimums on top of running VBR: 4 CPU cores, 8GB RAM, 5GB free disk, in addition to whatever VBR itself needs Enough free disk space confirmed on the storage volume (leave some headroom, don't plan to fill it to 100%) SSH enabled and reachable on each Linux client — VBR connects to Linux machines over SSH, not WinRM Each client's OS major version checked ahead of time (cat /etc/os-release) — the offline install package is version-specific (el7/el8/el9/el10) A machine with internet access to download the veeam-libs and veeam-nosnap offline install packages, since the clients themselves have no direct internet access Network connectivity confirmed between the server and each client Veeam ONE installer downloaded, matching the VBR version A resource constraint worth mentioning: no separate storage In a "proper" production Veeam deployment, you'd typically keep the backup server (the brains — job scheduling, configuration database, console) separate from the backup repository (the actual storage where backup files live), and often separate again from backup proxies that handle the data movement, and from the monitoring host. This separation is best practice because it avoids a single point of failure — if your backup server dies, your backup data is still intact elsewhere. I didn't have that luxury for this project. With limited lab resources, I installed VBR, the backup repository, and Veeam ONE all on the same box. It's a deliberate single-point-of-failure design: if that Windows server goes down, backups and monitoring both stop at the same time. It's not how you'd want to run this in production, but it was enough to prove out the workflow — and it's worth flagging clearly here rather than glossing over it. Agent-based vs. agentless backup One of the first real decisions in Veeam is how it's going to reach into a machine to actually back it up. There are two fundamentally different approaches: Agentless backup Veeam talks directly to the hypervisor (VMware vSphere, Microsoft Hyper-V, Nutanix AHV, etc.) and uses its snapshot APIs to capture a consistent image of the VM — no software needs to be installed inside the guest OS at all. This is generally the preferred approach for virtualized workloads because it's less invasive, easier to manage at scale, and doesn't add any agent overhead inside the VM. Agent-based backup Veeam installs a small backup agent directly inside the machine's operating system (Windows or Linux). The agent talks to the guest OS at the file-system/volume level to do the backup. This is the only real option for: Physical (bare-metal) servers and workstations that aren't virtualized at all Machines running on hypervisors Veeam doesn't have agentless integration with Machines that are often offline or unreachable (laptops, remote/branch office servers) — agent-based jobs are typically managed as policies that run locally rather than being triggered by a central server Cases where you need guest-level granularity the hypervisor snapshot alone can't give you For my project, I started with the agent-based side — 4 Linux servers — and later added a licensed VMware ESXi host to get hands-on with agentless, hypervisor-level backup too. Step 1 — Install Veeam Backup & Replication on the server Log into the server with a local administrator account. Run the VBR installer. When prompted for the configuration database, accept the default — the installer sets up a local PostgreSQL instance automatically. You don't need a separate SQL Server for a basic setup like this. Let the installer also set up the local components it installs by default: the Backup Server service, the local Data Mover, and the console. Once installation finishes, open the Veeam Backup & Replication Console and confirm it connects without errors. This is your central control point for everything from here on. Step 2 — Add the local storage as a Backup Repository In the console, go to Backup Infrastructure → Repositories. Right-click → Add Repository. Choose Direct attached storage → Microsoft Windows server (since the repository is the same local server). Select the server itself as the location, and point it to the volume/folder where backup files should be stored. Finish the wizard, and confirm the repository shows up with its available capacity matching what you expect. Step 3 — Install Veeam Agent for Linux (offline/nosnap method) on each client The clients don't have direct internet access, so this uses Veeam's offline (nosnap) install — download the packages on a machine that does have internet, copy them over via SCP, then install locally. Since the clients are RHEL/Rocky/AlmaLinux, this uses .rpm packages, and there are two of them — order matters: veeam-libs (shared dependencies) has to go in before veeam-nosnap (the actual agent). Check each client's OS version first, since the package is version-specific (el7/el8/el9/el10): cat /etc/os-release Note the version for each client — they may not all match. On a machine with internet access, download both files for the matching version from Veeam's software repository. For version 9 clients, for example: veeam-libs-13.1.0.252-1.x86_64.rpm veeam-nosnap-13.1.0.252-1.el9.x86_64.rpm (the el9/el8/el7/el10 in the filename must match each client's actual version — using the wrong one is the most common failure here) Copy both files onto each client using SCP: scp "" @: Note the colon after the IP — it tells SCP where on the remote machine to put the file. You'll be prompted to accept the SSH fingerprint the first time (yes), then enter the account password. Repeat for each client, swapping the IP. On each client, install the libs package first, then the agent package, matching the version confirmed in step 1: sudo rpm -i /tmp/veeam-libs-13.1.0.252-1.x86_64.rpm sudo rpm -i /tmp/veeam-nosnap-13.1.0.252-1.el9.x86_64.rpm Confirm the agent installed and is running: sudo systemctl status veeamservice No local job needs to be configured on the client itself — like the Windows flow, this gets added and managed centrally from the backup server in the next step, as long as it's set up in "managed by backup server" mode. What is a Protection Group, and why do you need one? For the agent-based side of things, Veeam organizes target machines using Protection Groups. A protection group is essentially a dynamic (or static) list of computers that should be protected with agent-based backups. Instead of manually adding machines to a backup job one by one — and having to remember to add every new server that shows up — a protection group defines the scope (individual computers, an Active Directory OU, a CSV import, cloud instances, etc.) and Veeam periodically rescans that scope to catch new or removed machines automatically. The real value shows up at scale: if you're managing dozens or hundreds of Linux/Windows machines, you don't want backup coverage to depend on someone remembering to manually register every new server. A protection group can also handle agent deployment for you — though since I'd already installed the agents manually in Step 3, I made sure to leave that option unchecked (more below). Veeam gives you several ways to populate a group: Since I was working with a small, fixed set of Linux servers with no Active Directory in the mix, I used Individual computers — right-click Physical & Cloud Infrastructure → Create protection group, choose Individual computers, name it (e.g. Linux-Backup-Clients), and add each client's hostname or IP one at a time. On the Options screen of the wizard (deployment settings), since the agents were already installed manually: Install backup agent — leave unchecked (already done manually; checking it risks a conflicting reinstall) Install nosnap agent (Linux only) — leave unchecked, same reason Install application plug-ins — leave unchecked, not needed for a basic setup Install CDP agent (enables replication) — checked by default, uncheck it — continuous replication is out of scope here Enable auto-update for installed components — leave unchecked, so nothing changes unexpectedly mid-setup Perform reboot automatically if required — leave unchecked, don't let a client reboot itself unattended The default daily rescan schedule is fine to leave as-is — it only controls how often Veeam re-checks for new/changed machines, not the actual backup schedule Setting up credentials For Veeam to reach the Linux boxes, it needs credentials it can use to SSH in and elevate privileges. I set this up with a non-root account, using automatic privilege elevation via sudo (with a fallback to su if sudo isn't available). Testing connectivity — and the firewall gotcha Before trusting the deployment to actually run, Veeam lets you test the connection to every target first. My first attempt showed the hosts mid-test: Known issue hit during this deployment: all four clients failed the Test Connection step with a generic "Failed" status and no detail beyond "Credentials test has been completed." The root cause was firewalld blocking port 22 (SSH) on the clients — despite SSH itself running fine. Fix, run on each client: sudo firewall-cmd --permanent --add-service=ssh sudo firewall-cmd --reload Confirm with sudo firewall-cmd --list-all — you should see ssh listed under services:. Since this was a default firewalld config issue, it hit all four clients identically, so it was worth applying to all of them at once rather than fixing and retesting one at a time. Once that was sorted, all four hosts came back green: Once applied, Veeam ran through discovery, package installation, and database record creation automatically: If a client fails to add: the most common causes are SSH not running or blocked by a firewall on the client, or the account lacking sudo rights — check both before troubleshooting further. Building the Agent Backup Job With the protection group live, it was time to create the actual backup job. Veeam gives you three backup modes to choose from: Entire computer — full image-level backup, best for fast, any-level recovery Volume level backup — back up specific volumes only, reducing backup size File level backup — slower, but only backs up selected files/folders instead of a full image I pointed the job at the protection group I'd just created, and set Mode: Managed by backup server (not "Managed by agent"/standalone) — this keeps scheduling, jobs, and monitoring centralized in the VBR console rather than each client managing its own local job. The LVM snapshot error — and why I switched to file-level My first instinct was Entire computer mode. All four clients promptly failed with: "Insufficient free space for a snapshot in a volume group" Entire machine and Volume level backup both rely on LVM snapshots to run, and in this deployment none of the clients' volume groups had free/unallocated space for LVM to create one in. The fix: switch to File level backup, and check "Backup directly from live file system" (the snapshot-less option, only available in file-level mode). This skips the snapshot mechanism entirely and reads files straight off the live filesystem instead. The trade-off is no point-in-time consistency guarantee if a file changes mid-backup — a non-issue for a basic setup backing up static test data. For file-level backups, you scope the job down to specific objects/folders instead of the whole filesystem: sudo mkdir -p /veeam-test-data echo "test file for backup verification" | sudo tee /veeam-test-data/testfile.txt Deliberately using a small, known test folder (rather than /, which would drag in /proc, /sys, /dev and other virtual filesystems) also makes the restore test later completely unambiguous — you know exactly what should come back. Storage and retention Next up was picking a backup repository and setting a retention policy — in my case, keeping 14 days of restore points. Because the repository lived on the same machine as VBR itself (see the resource constraint above), this step was also a reminder of why production environments separate the two. Setting a basic schedule Under the job's Schedule properties, I set it to run daily at a time when the clients are least busy (e.g. overnight), and saved. Watching the job run Once the job kicked off, I could watch it process each host in real time from the Home → Jobs view — including throughput, processing rate, and per-object status. Right-click the job → Start triggers it manually rather than waiting for the schedule. All four clients should finish with a green "Success" status — yellow ("Warning") is worth reading into, red ("Failed") needs troubleshooting before moving on. Checking the repository's used space afterward confirms data actually landed there. Testing a restore (don't skip this) A backup that has never been restored isn't a verified backup. Since the job used file-level backup, I went to Home → Backups, right-clicked the job, and chose the File level (a.k.a. Guest OS files) restore option: Pick the client and the most recent successful restore point. This opens a file browser showing the backed-up filesystem as it looked at that point in time — navigate to /veeam-test-data and confirm testfile.txt actually shows up. Right-click testfile.txt → Restore → "Restore to the following location" (rather than overwriting the original) → point it at a temporary folder like /tmp/restore-test/. Restoring somewhere new lets you compare the two side by side rather than just trusting the process worked. On the client, confirm the file landed: ls -l /tmp/restore-test/ Open it and confirm the content matches exactly: cat /tmp/restore-test/testfile.txt It should print exactly test file for backup verification. Matching content — not just a file existing — is what actually proves the setup works end to end, not just that a backup file exists in the repository. Getting reports on the backups A backup job that runs is only useful if you can actually verify it worked — so part of this project was pulling reports out of Veeam to confirm job success/failure history, data transferred, and job duration over time, rather than just eyeballing the console. This is also what you'd hand to a manager or auditor as proof backups are actually happening on schedule. Connecting Veeam ONE for monitoring Backups are only half the story — you also want ongoing visibility into whether they're staying healthy over time, not just at the moment a job finishes. That's where Veeam ONE comes in: it's Veeam's monitoring, reporting, and capacity-planning layer that sits on top of VBR. Only do this once the backup job above is working and verified — Veeam ONE monitors an existing, functioning backup setup, it isn't part of getting backups running in the first place. Confirm the server still has enough free CPU/RAM/disk headroom on top of what VBR is already using — Veeam ONE's minimums (4 CPU cores, 8GB RAM, 5GB free disk) apply on top of, not instead of, VBR's requirements. Run the Veeam ONE installer, matching the version to the installed VBR version, and accept the default local configuration database — it uses its own separate database instance from VBR's, even though both run on the same machine. Let the installer set up its three components: the Veeam ONE Server (core monitoring engine), Veeam ONE Reporter (web-based reporting), and the Veeam ONE Client (console for real-time monitoring). Confirm the account you'll use has the right permissions. Veeam ONE needs a Windows account that's a member of the local Performance Monitor Users and Event Log Readers security groups, plus general access to VBR itself. Open the Veeam ONE Client, expand the Veeam Backup & Replication view in the left inventory pane, right-click the top-level node → Add Server (or Ctrl+I): Choose server type Veeam Backup & Replication server, enter the server's hostname/IP (more reliable than localhost, since some components resolve names rather than loopback addresses), and enter the credentials confirmed above — this is a standard Windows login, not a Veeam-specific account. I added the VBR server as a data source, reusing the same service account credentials: The Data Collection Overview page, before the server was registered: Rounding out the wizard, the deployment reuses the same credentials for connection, analytics service deployment, and backup monitoring: And here's the summary screen before finishing setup: The first sync can take a few minutes, since it pulls in everything VBR already knows: the repository, the backup job, the protection group, and all the clients within it — without you manually entering any of it into Veeam ONE. Setting up and testing alarms Configuration alone doesn't prove monitoring works — you have to actually trigger a failure and watch it get caught. In the Veeam ONE Web Client, open Alarm Management (configuration) — different from Alarms Overview (where triggered alarms actually show up). Expand the Veeam Backup & Replication branch, and find the job failure/warning alarm. Predefined alarms ship enabled by default, so this is mainly a confirmation check. Find the repository free-space alarm (default threshold is often 90–95%). With a tight storage budget across several clients, it's worth lowering that to around 80% so there's room to react before the repository actually fills. Confirm both alarms are scoped to include the VBR server — predefined alarms usually auto-apply to all connected data sources, but it's worth a quick visual check. Trigger a real test failure. On one Linux client, stop the Veeam Agent service so its next backup attempt fails cleanly: sudo systemctl stop veeamservice Back in the VBR console, right-click the job → Start. With one client's agent stopped, that client should fail while the others succeed — a partial failure, closer to a real-world scenario than a total outage. Go to Alarms Overview in Veeam ONE. Within a few minutes, a new triggered alarm should appear showing the affected job/client, severity, and timestamp. This — not the configuration steps above — is the actual proof the monitoring layer is watching your environment, not just installed. Clean up: restart the agent (sudo systemctl start veeamservice), re-run the job, confirm it now succeeds cleanly, and mark the alarm resolved/acknowledged. The Veeam ONE dashboard Once data started flowing in, the Veeam Backup and Replication dashboard in Veeam ONE gave a much richer overview than the VBR console alone — backup infrastructure inventory, backup window trends, job status history, protected workload percentage, job duration, and repository usage, all in one place. Checking the Threat Center Veeam also ships a Threat Center that scores your environment's overall data protection posture and flags any malware detected in restore points. My lab environment scored 59.7% ("Vulnerable Zone") — mostly because things like immutability and MFA weren't fully configured, which is a good reminder that a working backup job isn't the same as a secure backup setup. Bonus phase: adding a licensed ESXi host for VM backup Once the Linux-agent side was solid, the project added a second phase: connecting a VMware ESXi host to get hands-on with agentless, hypervisor-level backup too — dropping one Linux client from scope to make room. Licensing note confirmed for this phase: the fully free VMware ESXi hypervisor lacks the vStorage APIs Veeam needs for VM backup and is not supported, regardless of VBR edition. A licensed ESXi host (Essentials tier or higher) is fully supported for direct VM backup with VBR Community Edition, with no vCenter required. Remove one Linux client from the existing job and protection group (which one doesn't matter functionally — just document the choice). Add the ESXi host as a new infrastructure connection. In the VBR console: Inventory → Virtual Infrastructure (a separate section from Physical & Cloud Infrastructure, where the Linux clients live) → right-click → Add Server → VMware vSphere → choose ESXi host specifically (not vCenter Server, since this connects directly to a single licensed host). Enter the ESXi host's IP and its root/admin credentials — a different credential type from the Windows or SSH accounts used elsewhere. VBR connects over the vSphere API, typically port 443. Finish the wizard — VBR discovers the host's VMs, datastores, and networks. Confirm the host appears under Virtual Infrastructure with its VMs listed underneath. Backing up a VM from the ESXi host Home → Backup Job → Virtual machine (a different job type from the Linux Computer job — this is hypervisor-level, not agent-based). Name it clearly (e.g. ESXi-VM-Backup), add the specific VM as the source, and set the destination to the same repository used throughout. Leave retention at defaults, same approach as the rest of the basic setup. Right-click the job → Start, and confirm it completes successfully. This uses a native VMware snapshot mechanism rather than the LVM-based one that caused the earlier Linux client failure, so that specific issue shouldn't recur here. Restoring the VM and verifying it Once the backup completes: Home → Restore → choose a VM-level restore option (Entire VM restore or Instant VM Recovery). Select the VM and the restore point just created. Choose restore location — original location (overwrite) or a new location on the same host. Overwriting is more disruptive if the VM is actually in use, so this is worth confirming with a supervisor before doing it live. Confirm the VM is present and boots/runs correctly on the ESXi host — the same principle as the file-content check used for the Linux client restore: proof the restore produced a working result, not just that the wizard finished without error. Quick troubleshooting checklist Symptom Likely cause Client won't add to inventory SSH not running/blocked by ufw/firewalld on the client, or the account lacks sudo rights Job fails immediately Repository out of space, or client agent (veeamservice) not running — check with systemctl status veeamservice Job fails with "Insufficient free space for a snapshot in a volume group" LVM has no free space to create a snapshot. Fix: switch to File level backup mode and check "Backup directly from live file system" Test Connection fails with no detail beyond "Credentials test has been completed" Likely firewalld blocking port 22, even though SSH itself is running. Run sudo firewall-cmd --permanent --add-service=ssh && sudo firewall-cmd --reload and retest rpm -i install fails on a client Wrong version package used (el7/el8/el9/el10 mismatch), or veeam-libs wasn't installed first SCP command fails or hangs Missing colon before the destination path, wrong username/IP, or SSH not reachable Job is very slow Network throughput between client and server, or too much data selected in "Entire computer" mode Restore fails Backup file corrupted/incomplete — check the original job's log for warnings Veeam ONE can't add VBR as a source Credentials lack access to VBR server, or version mismatch between Veeam ONE and VBR Veeam ONE shows no alarms firing Confirm the VBR data source connection is active, not just added What's intentionally left out of this basic pass Retention policy tuning Offsite/second-copy design (currently a single point of failure by design — one server carries backup, storage, and monitoring together) Advanced Veeam ONE reporting/dashboards beyond basic failure and free-space alarms Immutability / ransomware protection Application-aware processing for anything running databases Replication or Continuous Data Protection (CDP) for the ESXi VM — this phase covers standard backup/restore only, not near-continuous replication Wrapping up By the end of this project, I had: Registered for a Veeam account and installed the 30-day trial edition Understood the trade-offs between agentless (hypervisor-based) and agent-based backup, and used both Built a protection group and deployed backup agents to a set of Linux servers, working through a firewalld connectivity issue along the way Hit and fixed an LVM snapshot error by switching to file-level, snapshot-less backup Created an agent-based backup job with a defined retention policy, and actually restored a file to verify it worked Pulled reports to verify backup success over time Wired up Veeam ONE for ongoing monitoring, dashboards, and alarms — and proved the alarms actually fire on a real failure Gotten a first look at the Threat Center and what a "healthy" score actually requires Connected a licensed ESXi host and backed up/restored a VM agentlessly A few things worth calling out for anyone doing this for the first time: Separate your backup server, repository, and monitoring host if you can. I couldn't, due to lab constraints, but it's a real single-point-of-failure risk worth understanding, not just a nice-to-have. Agent vs. agentless isn't a style choice — it's dictated by your environment. Physical servers, offline machines, and unsupported hypervisors need agents; supported virtualization platforms are almost always better served agentlessly. Firewall rules are easy to forget and will silently break agent deployment or job connectivity — always the first thing to check when something won't connect. LVM snapshot space isn't guaranteed — if entire-computer or volume-level backup fails with a snapshot error, file-level with "backup directly from live file system" is the pragmatic fallback. A "Success" backup job doesn't mean a "secure" environment. The Threat Center score was a good wake-up call that immutability and repository hardening are a separate step from just getting jobs to run. A backup that's never been restored isn't verified — and reports matter as much as the jobs themselves, since a backup nobody checks on is a backup you can't fully trust. And, right on schedule, the trial reminded me it wasn't going to stick around forever: