Skip to main content
  • EN

For the last few years, I have spent a lot of effort along with others at Veeam carefully watching the industry behavior when it comes to ransomware and its devastating impact it can have on an organization. I’ve also spent a lot of time putting together a lot of great works in the form of whitepapers, webinars and other assets to get the word out. Before I forget, check out these three key whitepapers:

The important takeaway is that today, it is easier than ever to have backup copies ready to restore from ransomware with Veeam.

What are the Immutability Options?

I say there are more options than ever, but in fact, I’ve made a word for a backup copy that is in a state where recovery from ransomware is favorable: a copy on an ultra-resilient media. Ultra-resilient is a media type that is offline, air-gapped or immutable. Some media can in one state be all three at once, take for example WORM tape media when removed from the library.

Today, it doesn’t have to be cloud or tape only to get these levels of data comfort, there are more ways than ever to have ultra-resilient backup copies. Here’s the quick list:

  • Tape media, especially when media is removed from library or WORM
  • Veeam Cloud Connect backups with Insider Protection
  • Rotating media or removable drives that are offline
  • Immutable backups that are in a cloud target that is Veeam-Ready Object with Immutability
  • The Veeam hardened repository

What is Double-Play Immutability?

This is a way of implementing the 3-2-1 Rule with exceptional modern standards, even doing better than the 3-2-1-1-0 Rule. Check out a recent blogpost I did explaining the 3-2-1 and 3-2-1-1-0 Rule: What is the 3-2-1 backup rule? (veeam.com)

Double-play or even triple-play Immutability is where the implementation has two backup copies that are ultra-resilient. Let’s walk through a few examples so you can see both how easy this is and how resilient this is against ransomware. Each example has the explicit ultra-resilient copies identified with a number of first copy, second copy, third copy, etc.

Double-Play: Hardened Repository and Veeam-Ready Object with Immutability

This configuration would be leveraging the following configuration:

  • One Scale-out Backup Repository configured as followed:
  • One extent being a hardened repository
  • The capacity tier targeting a Veeam-Ready Object with Immutability provider (AWS S3 for example)
  • Copy mode configured

This is a robust configuration visualized in the diagram below:

Double-Play Immutability with the SOBR

Double-Play: Hardened Repository and Veeam Cloud Connect Backup with Insider Protection

This configuration would be leveraging the following configuration:

  • One backup repository being a hardened repository
  • A backup copy job to a Veeam Cloud & Service Provider partner offering Cloud Connect with Insider Protection

This is a robust configuration visualized in the diagram below:

Service Providers with Veeam Cloud Connect can achieve double-play copies that are ultra-resilient

Triple-Play: Hardened Repository and Veeam-Ready Object with Immutability and Tape Jobs

In baseball, a triple-play is a thing of beauty — it’s just as awesome if leveraging the following example configuration:

  • One Scale-out Backup Repository configured as followed:
  • One extent being a hardened repository
  • The capacity tier targeting a Veeam-Ready Object with Immutability provider (AWS S3 for example)
  • Copy mode configured
  • A backup to tape job configured as well

This is a robust configuration visualized in the diagram below:

Triple-Play Immutability for the Win

You can get the point that between the capabilities of the backup copy job (which there is a whole double-play immutability story there with the hardened repository site-to-site), the value of Veeam Cloud & Service Provider partners and the Veeam Ready Object with Immutability partners, it becomes very easy to add the second or third immutable copy.
 

Adding ultra-resilient copies without complete reconfiguration of your backup infrastructure

The examples above and some of the other ones that may make sense to you do not have to be a heavy lift to get started. This is where the Backup Copy Job and the Scale-out Backup Repository can help you out big time!

  • You can configure backup copy jobs to a newly created hardened repository or a Cloud Connect Backup target without reconfiguring your backup jobs
  • You can create a Scale-out Backup Repository and add your existing repositories to it to incorporate the copy mode as well as introduce the hardened repository with seal mode for the existing repositories.

It’s actually somewhat ironic that the Scale-out Backup Repository can play such a critical part in this double-play immutability story. It was initially designed to handle the situation of a backup target being full, then it was expanded to accommodate the lower cost opportunities by policies for object storage — here it is being the hero for ransomware resiliency.

Absolute Portability Drives Complete Recovery

What is really powerful here is that each copy is absolutely portable and self-describing. You only need to have the password the backups were encrypted with as part of the Veeam backup job. No part of the Veeam infrastructure is required, no servers on premises or in the cloud are needed either. These backup copies are each complete and fully recoverable only from the data they are. Additionally, there is no persistent connection back to the Veeam infrastructure to protect these copies in a ransomware scenario.

When it is this easy to have multiple ultra-resilient copies of backup data, there really is no reason not to have one, two or even three copies. Having copies that are ultra-resilient is by far the strongest best practice to drive high confidence for data recovery in a ransomware scenario.

 

What do you think about double-play or triple-play immutability? Share your comments below and configurations you would recommend.

Great article @Rick Vanover 

Very good configurations. 😎👍🏼

Really liking this article @Rick Vanover will come in handy for some configurations. :sunglasses:

Great piece! 

Good article @Rick Vanover 

interesting recap, double-play should be mandatory with the ascent of hardened linux repo on performance tier.

Thanks for this - it goes into the script immediately.

interesting recap, double-play should be mandatory with the ascent of hardened linux repo on performance tier.

I think it indeed does gravitate to best practice, there’s no additional Veeam cost for it - so why not?

Great post and recap of the possibilities @Rick Vanover !

In this concept I have a question for you and others :wink: .

As working for a MSP and being responsible for the Veeam Cloud Connect infrastructure…

We deliver BaaS using VCC (at the moment insider protection as an option). Most customers don’t take this option. I mention normally that VCC standard (without Insider Protection) delivers a offsite copy and gives a good protection against ransomware. If you want to have a real ‘airgapped’ protection and protected against hackers at the customer you need insider protection.

Now, we will renew and upgrade the whole VCC infrastructure. I will implement also Veeam ready immutable object appliances to COPY the backups of the customers on the primary storage to this immutable object appliances using the SOBR immutable copy capacity tier. I want to implement this by default for all the customers. In this way all backups of all customers are being protected to ransomware, hackers at the customer and hackers at the VCC side. 

Now my question : what is the added value of implementing then the insider protection at the VCC side?

I personally find 1 added value : when a hacker compromises the backups on the VCC side, we can rapidely copy the backup-chain in the recycle-bin (insider protection) on the primary repositories of the VCC to removable media to deliver to the customer. Otherwise we would need to copy those (and transform) from the object storage appliances. But in fact the customer can still restore backups from those object storage appliances directly… Are there other reasons to implement insider protection in this scenario? Just something I don’t have a 100% valid answer to this at the moment. Thx for the feedback!

@Nico Losschaert 

Insider protection also protect older gfs restore points.

If a hacker deletes all monthly gfs restore points from the cloud repo, you will have still access to them in the recycle bin.

With capacity tier, chances are great that only the last 30-90 days are protected from the deletion. You can configure much more in the shell, but How you want to remove the data if a customer doesn‘t want to use the Service anymore? With really high immutability retention, it is impossible to remove the data fast after the customer has cancelled his contract with you.

 

For us, it will always be like this:

  • Insider protection enabled for protecting GFS Restore Points older than 90 days
  • Capacity Tier Immutability not more than 90 days.

Copy Policy is the right way todo it. If you configure move policy and you need to download the entire customers data to the performance tier, you will not be able to offload it again. That could be an issue if you don‘t have the storage available on the Performance tier.

@Mildur  and @Nico Losschaert you actually bring up a point I need to write in my next discussion… Do you want:

“More immutability or More Immutability?”

More duration or more immutability types… A classic risk v reward but I’m on team more immutability types, with the duration up for debate. Cheers.

@Nico Losschaert

Insider protection also protect older gfs restore points.

If a hacker deletes all monthly gfs restore points from the cloud repo, you will have still access to them in the recycle bin.

With capacity tier, chances are great that only the last 30-90 days are protected from the deletion. You can configure much more in the shell, but How you want to remove the data if a customer doesn‘t want to use the Service anymore? With really high immutability retention, it is impossible to remove the data fast after the customer has cancelled his contract with you.

 

For us, it will always be like this:

  • Insider protection enabled for protecting GFS Restore Points older than 90 days
  • Capacity Tier Immutability not more than 90 days.

Copy Policy is the right way todo it. If you configure move policy and you need to download the entire customers data to the performance tier, you will not be able to offload it again. That could be an issue if you don‘t have the storage available on the Performance tier.

Thx for this feedback @Mildur . Not thought about this because we never protect restore points that long at the VCC infrastructure, so far.

Thanks @Rick Vanover, really a great article. Immutability is the showstopper for ransomware and creates additional barriers for attackers, so we should use it where possible. For me an offline tape is still a very convenient solution, so I would combine it like in your triple-play scenario.

I love the Veeam double-play and triple-play.  Rick V. and his team clearly hit a home run :blush:

Awesome article @Rick Vanover 

I have a new “Double-Play” configuration that actually has both copies requiring 4-eyes recovery - a special hat-tip to ExaGrid Retention Time Lock and a Cloud Connect Backup with Insider Protection. This is a very resilient specimen friends!
 

 

I have a new “Double-Play” configuration that actually has both copies requiring 4-eyes recovery - a special hat-tip to ExaGrid Retention Time Lock and a Cloud Connect Backup with Insider Protection. This is a very resilient specimen friends!
 

 

That is a great setup.

Comment


Terms & Conditions