The Veeam 100 Summit 2026 is taking place in Lisbon, Portugal, as I write. On day one, I attended the Object First track. Object First was acquired by Veeam in Q1 2026. While I cannot disclose anything discussed here, I can share that these people are (very) ambitious. It was a technical, no-nonsense experience where I voiced my enthusiasm, wishes, and concerns in my usual feedback style. Direct, unapologetic but polite, with the occasional strong “force multiplier” wording.
That led to some interesting discussions with lead architect Alexey Vasilev and Anthony Cusimano at the evening networking event. The level of interaction didn’t disappoint, as we have come to expect at the Veeam 100 Summit 2026. Great first day.
The release of Veeam Backup & Replication v13.1 introduces a significant new capability: the Application Backup Repository (ABR). Positioned as a secure landing zone for application‑generated backups, ABR brings hardened storage, snapshot lifecycle management, and immutability to workloads that generate backups of data or configurations to an NFS share. Databases and network devices come to mind and are mentioned in the documentation here: Application Backup Repositories – Veeam Backup & Replication User Guide.
“Configuration data of network devices: firewall or switch configurations.”
These “backups” or exports traditionally operate outside Veeam’s agent‑based or hypervisor‑based protection models. But while ABR is a powerful addition, it’s important to understand where it truly fits and where it doesn’t. When I first read the blog posts from Michael Cade and Anthony Spiteri, my first use case were network and IoT devices as they both mention it.
In particular, the idea that “network devices and IoT systems” can directly use ABR is more theoretical than realistic for most devices. The majority of those devices do not have an NFS client to write to an NFS share directly. That said, we can leverage the Application Backup Repository to improve backup and recovery services to our (internal) customers.
This post gives you a clear, realistic overview.
What ABR Actually Is
ABR is a feature of the Veeam Hardened Repository appliance. It exposes managed NFS volumes that applications can write their own backup files to. Each application receives its own isolated NFS export, and Veeam handles:
Snapshot creation and retention
Immutability enforcement
Instant rollback to any snapshot
Backup copy to secondary storage
Secure access control (Kerberos optional)
This allows application teams to continue using their native backup tools, such as RMAN, Backint, pg_dump, MongoDB dump, MySQL dump, custom scripts, while gaining Veeam’s hardened storage and recovery workflows.
Where ABR Shines
ABR is ideal for workloads that already support writing backup files to NFS:
Oracle RMAN Incremental Merge
SAP HANA Backint or file-based backups
PostgreSQL (pg_dump, WAL archiving)
MongoDB / MySQL / MariaDB dumps
Linux-based application exports
DevOps pipelines writing artifacts to NFS
These workloads benefit from ABR’s snapshot rollback, immutability, and backup copy integration without changing their native backup processes.
Network appliances and IoT device limitation
When it comes to most network appliances and IoT devices we are confronted with the limitation that they cannot write to NFS as they lack:
an NFS client
POSIX-compliant file handling
kernel-level NFS support
secure session handling (Kerberos, AUTH_SYS)
Typical network gear supports:
TFTP
FTP / FTPS
SFTP / SCP
HTTPS API upload
Proprietary backup formats
Typical IoT devices support:
local flash storage
MQTT / HTTP upload
cloud sync
proprietary export formats
NFS is almost never supported. So while ABR can technically accept NFS writes from any capable device, the practical reality is that network and IoT devices will not use ABR directly. This is something to keep in mind.
A Practical Workaround: How to Still Protect Network & IoT Backups with ABR
Even though network/IoT devices cannot write directly to NFS, you can still protect their backups using ABR by introducing a simple intermediary.
Workflow
Network/IoT device exports its backup (TFTP, SFTP, SCP, API, etc.)
A Linux server or automation node collects these backups
That server or servers write(s) the collected files into the ABR NFS share
Veeam handles snapshots, immutability, and backup copy from ABR
Benefits
Hardened storage for device backups
Snapshot rollback
Immutability
Backup copy to secondary storage
No unprotected local storage
This is the realistic way to use ABR for network gear and IoT systems.
Pricing
Well, it could work out to be cheaper than a NAS license for Veeam, but maybe not if you only store config file backups on there. I mean 1TB goes a long way for config backups only.
That said, in both cases you pay some money to have additional Veeam capabilities and immutability with granular and backup admin-managed recovery options. That might be the reason you want it over just backing up one or more virtual machines with the network appliance and IoT device backups on it. Think about it, a backup admin can provide a network engineer with a secured download of an encrypted zip at zero-dark-thirty in the morning without needing to restore files from a virtual machine, which might require a recovery key etc. Does that fit your security rules? Maybe, maybe not. But that is up to management to decide when they are down an extra 6 hours waiting for the file(s) from inside the Virtual Machine to be restored.
Conclusion
The Application Backup Repository is one of the most interestingl additions to Veeam v13.1, especially for enterprise databases and Linux-based applications that already support NFS. It brings hardened storage, immutability, and snapshot-driven recovery to workloads that previously lived outside Veeam’s ecosystem.
However, ABR is not a direct backup target for most network devices or IoT as far as I can see. These devices simply do not support NFS. The good news: with a lightweight collection server acting as an intermediary, you can still bring their backups into ABR and benefit from its security and lifecycle management.
ABR is powerful — but only when used where it actually fits. All this is lab and theory, it is early days yet and I am sharing my thinking process out loud with you. Nothing more, nothing less.
Veeam’s Software Appliance (VSA) and Infrastructure Appliance are hardened by design out of the box. They’re secured, protected, consistent, and predictable, but they’re also unapologetically locked down. There is no SSH, no shell, no root, no sudo. Everything is protected via requests and explicit approvals.
That’s good for security. But it also means you need to understand the actual workflow for getting shell access, especially root access, when you might need it.
This post walks through the real‑world process, the UI flow, the approval logic, and the operational pitfalls. We’ll even cover the “I disabled the web console and need to fix that” scenario.
There are two ways to get SSH access. First, there is the Veeam Host Management console locally on the machine, the one that is available at first boot. After configuration, you will also have access via the web host management console over port 10443.
How to get root access?
Root access can be obtained through 3 pathways that are essentially the same. The first two are again the Veeam Host Management console, locally on the machine, and the web host management console on port 10443. Once you have SSH access, you can request root access via the Veeam Host management console over SSH as well. You can also restrict access via these interfaces.
Note
I also enable the security officer option in the lab. That can indeed be annoying during testing, but I like to train with the tools I will use when it’s for real. You learn and operate under the same restrictions as in production and, yes, suffer the same frustrations at times. That is the price of security.
The local Veeam Host Management console
At your appliance console, select Sign In.
Enter your username and password and hit ENTER.
When prompted, enter your OTP to login.
From that point on, everything you need lives under the Remote Access configuration.
To request shell access, you choose Enter shell.
As mentioned, we have a security officer, so approval must be granted by that person.
The security officer can now approve or decline your request.
FYI: the security officer sign-in is only available via the web console!
Note that the entry for the approved request does not disappear. The security officer can decline it at any moment. For example, when you notify the security officer that you have completed your work. If not, it will expire after 8 hours.
Anyway, the console message changed to “Press <Enter> to access shell” and “Press <F1> to disable shell access.”
Hit ENTER, and you have shell access with root privileges.
Note that this root shell access is:
Time‑limited / non‑persistent
Audited
The only supported escalation path
Enabling root shell access via the web host management UI
Navigate to the IP address or the FQDN of your appliance over port 10443 and log in.
Under Overview, you can request root access. Again, this triggers the security officer approval workflow.
Once approved, a warning is displayed indicating that access privileges have been elevated to root. Note that you can revoke these yourself at any time.
Once approved, the TUI will allow you to open a temporary, audited root shell.
Once shell access is approved, you can:
Choose Enter shell in the TUI on the physical or virtual console
or enable SSH and log in remotely
Note that you always authenticate as the Host Administrator, not root. Dropping into the shell is always as root. When logged in via SSH, you do not use sudo or su to become root. You have to launch the TUI manually. Just run:
/opt/veeam/hostmanager/veeamhostmanagertui
That is useful when you want to activate an already-approved root shell without returning to the physical or virtual console.
As you can see, you have the same interface and have to sign in again. You can then enter the shell only if approval has already been granted; otherwise, you’ll have to wait for your security officer to approve your request. For people without access to the physical or virtual console, requesting SSH access in combination with root shell access is the only option. SSH alone will never get you to root. Remember that. Because:
root login is disabled
SSH root login is disabled
sudo is restricted
No direct escalation paths exist outside the TUI, making it the only supported privilege‑escalation mechanism.
Turning off the host management web UI
The appliance also lets you turn off the host management web UI. Sure, it might sound great for even further hardening, but it comes with an ⚠️ Important catch: turning off the host management web UI can Lock You Out (unless you have physical or virtual console access).
If you disable the web console and you do not have shell access or SSH enabled, the only way back in is through the hypervisor VM console. The physical or virtual console is your last‑resort access path. If you lose that, you have basically lost the appliance if all other options are disabled.
Some operational tips
Use root access with care and only when needed
I hope this is self-explanatory.
Use the web host management console & enable SSH on demand
We handle normal operations via the web consoles and the full console. When SSH is needed, request it.
Never turn off the web console unless you have guaranteed VM console access
If your hypervisor is managed by someone else, for example, think twice. Silos and multiple layers of communication and responsibilities are productivity, efficiency, and support-killing factors in way too many “enterprise”- grade environments. For real people, “enterprise IT” is not the badge of quality and efficiency many think it is; quite the contrary.
The Security Officer must be on call
When you tie actions to a security officer, ensure they are on call and kept informed. Make sure these are people with a clue, not just someone who approves anything without knowing what or why. Also, make sure they are very well aware of what normal backup and recovery operations require and what constitutes an exceptional but valid request. Otherwise, you can’t approve shell or root requests when you need them, or everything gets approved. The technology is only as good as the people and the processes.
Conclusion
While root shell access may be needed in a real-world environment, it should be used only when necessary and with great care. That is why I advise you to enable the security officer in production. And if you are like me, use the security officer feature in labs to make sure you learn and know the processes where this approval is required. How to Open a Root Shell on the Veeam Software or Infrastructure Appliance is also documented on Veeam Backup Enterprise Manager Guide
Occasionally, I hear comments like “Veeam is too expensive.” Sometimes, when combined with the remark, it has become overly complex. In this blog I will discuss why Veeam V13 delivers for everyone.
I understand and accept those remarks. I do not fully agree, though I sympathize with the fact that businesses face more threats and challenges than ever before. The cost of living and doing business has not declined in the last five years. But beyond bar inflation, supply chain issues, and political turmoil, there are other factors driving rising costs and a perception of greater complexity. The world is different, and you need to critically evaluate your own perception if that is your view.
I will discuss here why Veeam V13 isn’t only for the Fortune 500, their needs, and their pockets. It’s for any seized SMB that can’t afford a single day of downtime.
Complexity and Cost
While many products today include compliance checkboxes that vendors must complete to be selected, most items have a far better reason for their existence. They are necessary.
The visceral reaction that it has become too complex and/or expensive is dead wrong. A statement like “My small business running a few dozen virtual machines doesn’t need this complexity or cost” is easy to make but ignores some realities.
It’s an infrastructure-blind perspective that fails to factor in the modern operational risk profile. The technical advancements in the Veeam Data Platform (VDP V13) are fundamentally about addressing the need for operational simplification and providing (mandatory) cyber resilience (GDPR, NIS2, DORA). From that perspective, it is precisely what an SMB (like an enterprise) requires.
When budgets are tight, you need solutions that aggressively reduce TCO by minimizing administrative overhead and guaranteeing recovery. If you cannot guarantee recovery, you are just window dressing and cosplaying at data protection. And while I have seen that happen even in large organizations and with partners, that is a recipe for disaster. Veeam V13 delivers what you need to guarantee recovery, the very thing that you buy and implement it for.
Minimizing configuration complexity and OPEX
The high cost of software isn’t just the license fee; it’s the weekly administrative hours and the price of the OS and database licenses required to run it. V13 tackles both.
The Veeam Software Appliance (VSA) is a Game Changer
The Veeam Software Appliance is the most significant gift to small and medium businesses. The VSA is a hardened, Just Enough OS (JeOS) based on Linux.
No Windows License Tax: You immediately eliminate the Windows Server OS license required for your backup repository server. That’s a direct, measurable savings on perpetual or subscription licensing. The same applies to the database: PostgreSQL incurs no license fee.
Reduced Patching Cycle: The VSA is purpose-built. It automatically updates the core Veeam components, reducing required Linux OS maintenance. For a small team, this is an immediate, significant reduction in the security and patching OpEx drain. We are shifting from managing a full Windows Server install to managing a streamlined appliance.
Immutability Baseline: It enforces immutability by default, providing an air-tight technical barrier against ransomware that could delete your backups. That isn’t a premium feature; it’s essential data-integrityengineering. You can’t afford to secure and audit a Windows repository to this standard manually.
VUL is protecting the infrastructure investment and adds flexibility
The Veeam Universal License (VUL) isn’t just flexible; it’s a TCO defense mechanism.
Infrastructure Agnostic: Your license protects a VM, a Physical Server (via Agent), a Cloud VM (AWS/Azure), or even an M365 user.
Future-Proofing the Budget: If you decide to ditch VMware for Hyper-V or move 10 VMs to Azure next year, your license stack does not change. You avoid the capital expense of acquiring new platform-specific licenses and maintain vendor leverage. VUL protects your budget against unforeseen architectural changes. You can switch between hypervisors and on-prem/hybrid/cloud at your discretion.
You can migrate to a hypervisor of your choice or to the cloud and continue using your existing licenses. Veeam has been adding support for additional providers as the market has become more volatile again.
Risk Mitigation
Backups must be restorable to justify the time and effort you invest.
The cost of VDP Essentials is insurance against the cost of failure. A single ransomware event or hardware failure can bankrupt an SME, even if it results in only a multi-day outage. Veeam focuses on assuring recoverability and crushing the RTO (Recovery Time Objective).
Instant VM Recovery: This technology means your RTO can be minutes, not hours, even for large VMs. You boot the VM directly from the deduplicated backup file while the permanent restoration occurs in the background. If you can’t afford to be down for four hours, this feature is worth its weight in gold.
SureBackup Validation: No professional IT operation should ever expect its backups to work. SureBackup automatically verifies the image file’s integrity and restorability, validating RPO/RTO goals with no administrative effort. It provides the definitive technical proof that your backup chain is good.
There is free functionality via Community Editions
For the absolute tightest budgets, the Community Editions are a technical lifeline, providing the production-grade core engine at zero cost.
Product
Capacity Constraint
Essential Technical Functionality
VBR Community Edition
10 Instances (VMs, Servers, or 3 Workstations per instance).
Full Instant VM Recovery, Veeam Explorers (granular recovery for AD/Exchange/SQL), Scheduled Jobs, Backup Copy support (for 3-2-1 rule).
Veeam Backup for M365 CE
10 Users / 10 Teams / 1TB SharePoint.
Granular recovery for all M365 workloads. Essential for closing the M365 retention gap and protecting against rogue admins/ransomware.
Cloud-Native Editions
10 Instances per cloud (AWS, Azure, Google Cloud).
Policy-based, native snapshot management and data protection for cloud-resident workloads.
The Bottom Line
Veeam designed V13 for maximum security and minimal operational overhead. At an SMB, you don’t have the resources to secure complex systems manually. The VDP Essentials product, paired with the VSA, delivers a hardened, low-maintenance, recovery-guaranteed system that significantly lowers your operational risk profile, making it a sound, justifiable technical investment. Veeam hides the complexity of its deployment; the simplicity you experience daily comes from adopting and running it. Once you have that base, you can enhance and expand your cyber resilience as your needs demand and budgets allow. But if you do not get the basics right, you are not in a good place to begin with.
Why are we at this point?
It isn’t 2015 anymore. The amount, diversity, and sophistication of threats are staggering. Moving from basic “set and forget” backups to a Zero Trust Data Resilience (ZTDR) architecture isn’t free. There are financial and engineering efforts to make it happen. That comes at a cost.
Transitioning from a simple backup job to a hardened, ransomware-proof posture involves more moving parts. You’re dealing with hardened repositories, MFA for everything, service account isolation, automated verification, and early-detection capabilities. If anyone tells you that adding immutability and Zero Trust doesn’t increase your operational footprint, they are paper architects who never have to live with their grand designs, let alone that they have never managed a production environment in the past few decades.
However, we need to distinguish between complex overhead and necessary engineering to keep you safe and keep it operationally manageable. Let’s discuss this a little bit more, without going into too much detail.
Hardware and storage costs
People will spend money on hyperconverged storage solutions with 25/50/100 Gbps networking, often all-flash, and with relatively low net usable capacity, yet then complain about having to use one or more dedicated storage servers to store and protect their backups. That is nothing new. Will have to invest in sufficient storage on a dedicated box as a backup target and/or use Veeam Data Cloud Vault, keeping it hardened and protected from other workloads.
That comes at a cost, especially if you need the performance to run Instant VM Recovery effectively. You should run your VBR Server on a VM on a different host, but most mini servers running a hypervisor can handle that for you. While you end up with a slightly higher BOM (Bill of Materials), you do get a backup fabric that can actually survive a scorched-earth ransomware attack.
The Configuration Burden
Implementing Zero Trust means keeping your backup fabric isolated, separate, and independent of the production workloads it protects, with only the minimal connectivity required to function. That means authentication and authorization must be performed securely (MFA, certificates), with immutability and hardened hosts. That used to be a lot of work and required extra effort, as it involves additional layers that complicate setup and configuration. But the payoff is a secured fabric that prevents a single compromised credential from wiping out your entire company’s history. And guess what? The Veeam VSA/JeOS handles most of that complexity for you. It is actually a complete TCO win that provides a level of protection many would never achieve on their own! You can automate restore testing and sleep easier: your backups are not a soft target, and you actually know restores work!
Conclusion
Yes, V13 requires a more disciplined approach to IT operations. Yes, there is some “overhead” in terms of ensuring your architecture follows the 3-2-1-1-0 rule. But that is no different than it was in V12, V11, … In an era where an SME is just as likely to be targeted as a global bank. Veeam designed V13 not only for “enterprise requirements and budgets”; they aim for professional-grade survival, no matter what size of business, so your company doesn’t close down for good in the event of a cybersecurity incident.
