This is the fourth in a series of blog posts about the challenges of data protection. In previous posts I covered how backups were mostly sent to tape using large monolithic backup systems that were difficult to design, purchase, and scale, and how target dedupe helped give life to those legacy systems. Another challenge of these traditional backup implementations was the advent of VMware, as they initially treated VMware backups like every other server they’d been responsible for – creating a market opportunity for a new solution. This blog covers the multi-billion dollar business of virtualization backup, a market consisting of Veeam and its competitors who stepped into the opportunity to innovate.
Evolution to Windows or Linux on Intel systems
In the last few decades, data centers moved away from traditional Unix platforms running Solaris, AIX, and HP-UX and started installing virtual machines on Intel-based servers running VMware and Hyper-V. This drastic simplification of the computing environment created an opportunity to simply backups as well. Virtualization admins saw traditional backup products as inefficient, costly, and difficult to learn and maintain. (They weren’t wrong. Be sure to check out the first and second blog in the series that details the challenges of traditional backup systems, as well as part three that covers target dedupe.)
Veeam takes the opportunity and leads backup innovation with Windows, automation
Veeam was the complete opposite of most traditional backup products. It was based entirely on Windows, an operating system VMware admins were familiar with. All backups were stored on disk, versus the tape-centric products of the past. Their backup system was VM-centric and simple to configure. It was exactly what VMware admins were looking for.
Veeam’s backups were more reliable than the backup systems that came before them, leading them to adopt the marketing slogan that their backups “just worked.” This backup success rate was likely due to multiple factors, starting with an easy to understand interface running on an easy to understand operating system (Windows). They also did not have to deal with the complications that tape drives were having in traditional backup systems. Finally, their support for VMware (and eventually Hyper-V) was definitely ahead of what other vendors were doing at the time. They were not the only vendor to address the virtualization backup market, but they definitely are the leader of the space.
In 2011, Veeam was the first backup product to introduce automated testing of your backups. Users could easily select a number of VMs and have those VMs booted in a particular order directly from backups in order to automatically verify that backups were successful. This removed the age-old concern of “I know my backups worked, but are they restorable?” I remember being very excited about this feature at the time, but also frustrated that, while they had a feature no one else had, they were (at the time) missing a number of features that I considered table stakes for a backup product (e.g. the ability to copy backups to a second location.) They’ve since added most of the missing features I was asking for.
Veeam’s challenges: alternate locations, deduplication, risk of ransomware
One of the biggest challenges for Veeam is ensuring that all backups are reliably stored in an alternate location from the primary. While Veeam has added this functionality to their product in recent years, the process still requires additional configuration and monitoring. (This isn’t so much a knock against Veeam as it is an acknowledgment of how most backup products were designed, except for Druva, where all backups are automatically sent off-site and copied to three locations.)
One of the questions I posed in the previous blog post was why target deduplication is still prevalent. Almost all backup products have implemented source dedupe in their products. So why do so many Veeam customers have an associated Data Domain or Exagrid appliance? The answer is Veeam’s built-in deduplication is nice, but it does not support the performance customers are looking for for many types of restores. This is especially true for instant boot and the restore testing mentioned above, which requires read-write random-access to backup data – so their customers buy a dedupe appliance.
This leads me to another concern – an increased security risk of ransomware. Storing all backups on an on-premises disk system that is immediately accessible to the on-premises backup system removes the air gap that we had for years in any good backup system. Yes, it is possible to configure Veeam in a way that protects yourself from this risk, but it is an advanced configuration that you might not even be aware of or even know you need.
Windows is a liability, consider the security impact
This brings me to my biggest concern about the Veeam architecture. Like CommVault, its core technology runs only on Windows – the OS of choice for hackers and ransomware attackers. It is true that you can have a Linux backup repository (just like CommVault), but that is unlikely to happen in most Veeam customers since they tend to be primarily Windows environments. Linux is not without vulnerabilities or even ransomware, but I do believe the popularity of Windows and its popular Remote Desktop Protocol (RDP) do make it more of a risk than Linux.
As mentioned in my post on target dedupe, however, the real risk here is an on-premises backup server that can be attacked at any time via a variety of methods. A compromised on-premises backup server can be a dangerous thing, which is why it seems particularly dangerous to use a backup system that requires it to run on Windows.
In case you think I am being alarmist, feel free to take a look at Veeam’s own forums where its customers talk about having their backups encrypted with ransomware. Veeam is increasingly making its customers aware of this risk and offering them ways to protect against it. But the threat will always be there if there is an on-premises system.
Additional challenges: sizing, purchasing, maintenance, scale
Finally, Veeam did not address the issues around sizing, purchasing, patching and upgrading its OS and applications, buying hardware way before you need it, which is why it requires large capital expenditures. They also did little to address the scaling issues, as large Veeam customers simply have many separate instances of Veeam, each of which they must manage.
Veeam definitely made things better – especially for VMware and Hyper-V customers. But the things it left on the table created the opportunity for yet another challenger. Check back in a few weeks to read my discussion of hyper-converged backup architectures such as Rubrik, Cohesity, and Actifio.
In the meantime, we recommend you check out this Druva white paper on Data Protection for VMware Cloud on AWS and read these customer case studies on how one customer saved 30% in TCO in moving from Veeam to Druva, and another who saved more than 50% in time and effort by replacing Veeam with Druva.