When reading the story about how the Italian municipality of Palermo lost both their VMware infrastructure and their backups in one fell swoop, I couldn’t help but think about the 1961 novel Catch-22. The author coined the titular phrase in that book, a great example of which is needing to print out a form to request more toner.
Given that a single piece of malware took out both their VMware and Veeam infrastructure, it appears the folks in Palermo created a Catch-22 in their backup system by putting their Veeam backup servers in VMware VMs. Virtualizing backup servers is actually very common, and Veeam documentation even gives instructions on what to do. I have always thought it was a really bad idea because it creates a Catch-22 in your backup system. You can’t recover your VMware infrastructure without your backup infrastructure – which is inside your VMware infrastructure.
I understand there are so many reasons why you would want to virtualize your backup environment. Virtualization is amazing, and it solves so many problems! Over the last twenty years, many organizations have moved many I/O intensive applications like backup inside VMware, even if it was only one VM in a physical server. They did this because of everything VMware brings to the table – which is a lot.
But I still think it’s a bad idea, and now there are even more reasons this is the case. Historically we were mainly concerned about typical backup and recovery scenarios, like the loss of a single VMware node or data center outage caused by a natural disaster. Someone directly attacking your VMware infrastructure completely changes the game, because they could potentially take out your primary and secondary systems – even if they are in another location. In case you haven’t been keeping score at home, that’s exactly what some malware attempts to do. VMware has tools to help battle this new threat, but no computing system is impervious to attack. This is why I think that – more so than ever before – virtualizing your backups servers inside the thing you’re backing up is inviting disaster.
If you’re still using on-prem backup software – even though you’re using SaaS for your email, CRM, and single-sign-on – one idea would be to install any on-prem backup software on a physical server. That stinks, of course, because it means your backup system doesn’t benefit from virtualization. It also means that the backup server can be directly attacked by ransomware – especially if it’s a Windows-based backup server. So that’s not exactly a good choice either.
Druva: The solution to Catch-22s in your backup and data protection strategy
A better idea would be to not have on-prem backup infrastructure at all. To start, use a SaaS service for backups where all backup infrastructure is in the cloud and someone else’s job is to secure it. Druva’s customers don’t have Catch-22s. Their backups are encrypted and stored in an immutable datastore inside AWS. The protocols used to spread ransomware within a data center (e.g. RDP, SMB, NFS, FTP) simply aren’t available in S3 – where Druva stores your backups – preventing ransomware from spreading directly from your data center to your Druva backups. Even if Druva backed up malware from your account, it is stored in a deduplicated and encrypted object in S3, preventing the malware from executing. (Druva also has tools to prevent it from being restored, reinfecting your environment.) S3 is also configured to only allow GETs and PUTs from the Druva environment, preventing a direct attack against your backups via the S3 protocol.
Druva’s environment uses the most vetted infrastructure provider on the planet (AWS), while also ensuring the service automatically follows current security best practices in each account. Because it is SaaS, all Druva customers are also always running the latest and most secure version. Contrast that with on-prem environments, where customers must constantly update their operating system and backup software to keep up to date, while also manually ensuring they are following current best practices.
When Druva customers get hit by ransomware, they simply need to login to the Druva UI in their favorite browser and begin the single-click disaster recovery process that supports a 15-minute RTO and a 1-hour RPO – all without having to buy or manage the infrastructure that makes it happen.
Next steps
Keep your data resilient and compliant with the Druva Data Resiliency Cloud’s multi-layered defense-in-depth, air-gapped architecture, sensitive data governance, eDiscovery, and ransomware response and recovery. Discover Druva for cyber resilience with a live demo and free trial. See firsthand how easy it is to safeguard your backups and ensure your company doesn’t become a headline.