It’s not a secret that we’re calling Veeam Availability Suite v10 the biggest release in Veeam’s history. There are lots of goodies we’ve baked into this version and now it’s my turn to unveil features which could be collectively named “Linux enhancements”, allowing you to leverage Linux ecosystem in the ways you wanted but couldn’t before. Without any further ado, let me please divide features by categories and then show them in order.
Linux Backup Proxy for VMware
Backup Proxy is an essential component of Veeam Backup & Replication’s distributed architecture. It acts as a data mover, retrieving the data from the production storage, processing it on the fly (compression, deduplication and encryption) and pushing it to the target repository. Prior to v10, it has always been a requirement for a Proxy Server to run on a Windows-based OS, which sometimes wasn’t the best scenario for users due to additional Windows license overhead, automation challenges and whatnot. Version 10 introduces the long-awaited capability to run a Backup Proxy on Linux distributions.
This will effectively prevent users from Proxy lock-in, enable better automation scenarios as well as help to reduce licensing cost and will be an especially good candidate for ROBO and VMware vSAN environments. Under the hood, there is a 100% Veeam written code, as we don’t rely on VMware VDDK. That’s why only the Virtual appliance (hot add) transport mode will be available for now. As for the setup, there is no new requirements: have perl, bash and ssh installed and off you go. Important note to mention here is that we don’t provide a pre-built appliance. VBR users will have to provision Linux VMs, get them approved, patched (very good from a security department point of view) and then added as a Backup Proxy themselves. Preference-wise, VBR doesn’t pick Linux over Windows or vice versa, it still analyzes several factors, but ultimately decides on Proxy selection, based on the most important metric — performance.
XFS block cloning support
Ok, let’s switch to the next important program component — Veeam Backup Repository. The first new capability here is related to “Block cloning” technology, which got somewhat popular after the release of Windows Server 2016 and ReFS 3.1. As a quick reminder, block cloning allows ReFS to handle synthetic disk operations (e.g. forever forward incremental backup) differently compared to other file systems. The logic was to write the data blocks on storage only once and if they needed to be copied, to not actually do that, but rather create “pointers” to the same blocks, reducing the overhead and speeding up operation completion.
Very similar technology (reflink) has made its way into XFS public branches some time ago and got official support by some distributions, like Ubuntu 18.04 and onward. This allowed us to leverage the technology, thus simplify and speed up all synthetic operations for Linux backup repositories based on XFS.
Now, let me address all of you who use NAS devices and SMB/NFS shares as a target destination for the backups. Our history supporting such targets encounters some challenges that users face. SMB protocol generally provides very poor reliability with non-continuously available shares and is a huge problem recognized by our technical support. When an application (like VBR) writes data to an SMB share using WinAPI, it receives success for this I/O operation prematurely, despite of the actual result, so it can sometimes result in data corruption. Prior to v10 Veeam has been recommending to work around it by setting an SMB gateway proxy as close as possible to the SMB share. In case of NFS shares, we had to ask users to mount them to a Linux server before using as it was the only way to transfer backups there.
VBR v10 is introducing native (write-through) support for NFS shares, overcoming the aforementioned limitations. The goal of this capability is to provide a more reliable option for growing number of non-enterprise class NAS users as well as to simplify backup creation process for customers with NFS repositories.
Networkless processing for Linux-based VM
vSphere Guest Operations API (formally known as VIX API) is a set of technologies, that can allow vSphere users to interact with a VM and its guest OS without using the network stack. Historically, Veeam has been utilizing VIX as a second choice for application-aware guest processing of Windows VMs and failing over to it if the VM is inaccessible via the TCP/IP stack.
Starting from v10, we’re going to enable VBR utilizing vSphere Guest Operations API for Linux VMs too. Due to this change, guest VM processing operations (ex. pre-freeze and post-thaw scripts, file-level recovery, etc…) will be possible via the said API. That is handy in challenging environments where there’s no direct network connection to the VM for some reason. Let me give you an example here. For FLR recoveries enterprise administrators won’t need to put an FLR appliance in every network segment, they will simply deploy one and will be able to use it regardless of network connection to the targeted VM.
Conclusion
These new Linux enhancements are the perfect example of how Veeam strives to listen to the community and aims to address challenges coming from rapidly growing environments that you run. I’m very excited about this v10 release and can’t wait for a moment when you upgrade and have a look at all the things I have just described here (and much more) yourself. Stay tuned!
Register for the launch event and be the first to know when NEW Veeam Availability Suite v10 is here!
