Veeam Basics – Cloud Tier And v10

Disclaimer: I recently attended Veeam Vanguard Summit 2019.  My flights, accommodation, and some meals were paid for by Veeam. There is no requirement for me to blog about any of the content presented and I am not compensated by Veeam for my time at the event.  Some materials presented were discussed under NDA and don’t form part of my blog posts, but could influence future discussions.

Overview

Depending on how familiar you are with Veeam, you may already have heard of the Cloud Tier feature. This was new in Veeam Availability Suite 9.5 Update 4, and “is the built-in automatic tiering feature of Scale-out Backup Repository that offloads older backup files to more affordable storage, such as cloud or on-premises object storage”. The idea is you can use the cloud (or cloud-like on-premises storage resources) to make more effective (read: economical) use of your primary storage repositories. You can read more about Veeam’s object storage capabilities here.

 

v10 Enhancements

Move, Copy, Move and Copy

In 9.5 U4 the Move mode was introduced:

  • Policy allows chunks of data to be stripped out of a backup files
  • Metadata remains locally on the performance tier
  • Data moved and offloaded into capacity tier
  • Capacity Tier backed by an object storage repository

The idea was that your performance tier provided the landing zone for backup data, and the capacity tier was an object storage repository that data was moved to. Rhys does a nice job of covering Cloud Tier here.

Copy + Move

In v10, you’ll be able to do both copy and move activities on older backup data. Here are some things to note about copy mode:

  • Still uses the same mechanics as Move
  • Data is chunked and offloaded to the Capacity Tier
  • Unlike Move we don’t dehydrate VBK / VIB / VRB
  • Like Move this ensures that all restore functionality is retained
  • Still makes use of the Archive Index and similar to Move
  • Will not duplicate blocks being offloaded from the Performance Tier
  • Both Copy + Move is fully supported
  • Copy + Move will share block data between them

[image courtesy of Veeam]

With Copy and Move the Capacity Tier will contain a copy of every backup file that has been created as well as offloaded data from the Performance Tier. Anthony does a great job of covering off the Cloud Tier Copy feature in more depth here.

Immutability

One of the features I’m really excited about (because I’m into some weird stuff) is the Cloud Tier Immutability feature.

  • Guarantees additional protection for data stored in Object storage
  • Protects against malicious users and accidental deletion (ITP Theory)
  • Applies to data offloaded to capacity tier for Move or Copy
  • Protects the most recent (more important) backup points
  • Beware of increased storage consumption and S3 costs

 

Thoughts and Further Reading

The idea of moving protection data to a cheaper storage repository isn’t a new one. Fifteen years ago we were excited to be enjoying backup to disk as a new way of doing data protection. Sure, it wasn’t (still isn’t) as cheap as tape, but it was a lot more flexible and performance oriented. Unfortunately, the problem with disk-based backup systems is that you need a lot of disk to keep up with the protection requirements of primary storage systems. And then you probably want to keep many, many copies of this data for a long time. Deduplication and compression helps with this problem, but it’s not magic. Hence the requirement to move protection data to lower tiers of storage.

Veeam may have been a little late to market with this feature, but their implementation in 9.5 U4 is rock solid. It’s the kind of thing we’ve come to expect from them. With v10 the addition of the Copy mode, and the Immutability feature in Cloud Tier, should give people cause to be excited. Immutability is a really handy feature, and provides the kind of security that people should be focused on when looking to pump data into the cloud.

I still have some issues with people using protection data as an “archive” – that’s not what it is. Rather, this is a copy of protection data that’s being kept for a long time. It keeps auditors happy. And fits nicely with people’s idea of what archives are. Putting my weird ideas about archives versus protection data aside, the main reason you’d want to move or copy data to a cheaper tier of disk is to save money. And that’s not a bad thing, particularly if you’re working with enterprise protection policies that don’t necessarily make sense (e.g. keeping all backup data for seven years). I’m looking forward to v10 coming soon, and taking these features for a spin.

Veeam Basics – Configuring A Scale-Out Backup Repository

I’ve been doing some integration testing with Pure Storage and Veeam in the lab recently, and thought I’d write an article on configuring a scale-out backup repository (SOBR). To learn more about SOBR configurations, you can read the Veeam documentation here. This post from Rick Vanover also covers the what and the why of SOBR. In this example, I’m using a couple of FlashBlade-based NFS repositories that I’ve configured as per these instructions. Each NFS repository is mounted on a separate Linux virtual machine. I’m using a Windows-based Veeam Backup & Replication server running version 9.5 Update 4.

 

Process

Start by going to Backup Infrastructure -> Scale-out Repositories and click on Add Scale-out Repository.

Give it a name, maybe something snappy like “Scale-out Backup Repository 1”?

Click on Add to add the backup repositories.

When you click on Add, you’ll have the option to select the backup repositories you want to use. You can select them all, but for the purpose of this exercise, we won’t.

In this example, Backup Repository 1 and 2 are the NFS locations I configured previously. Select those two and click on OK.

You’ll now see the repositories listed as Extents.

Click on Advanced to check the advanced setttings are what you expect them to be. Click on OK.

Click Next to continue. You’ll see the following message.

You then choose the placement policy. It’s strongly recommended that you stick with Data locality as the placement policy.

You can also pick object storage to use as a Capacity Tier.

You’ll also have an option to configure the age of the files to be moved, and when they can be moved. And you might want to encrypt the data uploaded to your object storage environment, depending on where that object storage lives.

Once you’re happy, click on Apply. You’ll be presented with a summary of the configuration (and hopefully there won’t be any errors).

 

Thoughts

The SOBR feature, in my opinion, is pretty cool. I particularly like the ability to put extents in maintenance mode. And the option to use object storage as a capacity tier is a very useful feature. You get some granular control in terms of where you put your backup data, and what kind of performance you can throw at the environment. And as you can see, it’s not overly difficult to configure the environment. There are a few things to keep on mind though. Make sure your extents are stored on resilient hardware. If you keep your backup sets together with the data locality option, you’l be a sad panda if that extent goes bye bye. And the same goes for the performance option. You’ll also need Enterprise or Enterprise Plus editions of Veeam Backup & Replication for this feature to work. And you can’t use this feature for these types of jobs:

  • Configuration backup job;
  • Replication jobs (including replica seeding);
  • VM copy jobs; and
  • Veeam Agent backup jobs created by Veeam Agent for Microsoft Windows 1.5 or earlier and Veeam Agent for Linux 1.0 Update 1 or earlier.

There are any number of reasons why a scale-out backup repository can be a handy feature to use in your data protection environment. I’ve had the misfortune in the past of working with products that were difficult to manage from a data mobility perspective. Too many times I’ve been stuck going through all kinds of mental gymnastics working out how to migrate data sets from one storage platform to the next. With this it’s a simple matter of a few clicks and you’re on your way with a new bucket. The tiering to object feature is also useful, particularly if you need to keep backup sets around for compliance reasons. There’s no need to spend money on these living on performance disk if you can comfortably have them sitting on capacity storage after a period of time. And if you can control this movement through a policy-driven approach, then that’s even better. If you’re new to Veeam, it’s worth checking out a feature like this, particularly if you’re struggling with media migration challenges in your current environment. And if you’re an existing Enterprise or Enterprise Plus customer, this might be something you can take advantage of.