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.

Cohesity Basics – Cloud Tier

I’ve been doing some work with Cohesity in our lab and thought it worth covering some of the basic features that I think are pretty neat. In this edition of Cohesity Basics, I thought I’d quickly cover off how to get started with the “Cloud Tier” feature. You can read about Cohesity’s cloud integration approach here. El Reg did a nice write-up on the capability when it was first introduced as well.

 

What Is It?

Cohesity have a number of different technologies that integrate with the cloud, including Cloud Archive and Cloud Tier. With Cloud Archive you can send copies of snapshots up to the cloud to keep as a copy separate to the backup data you might have replicated to a secondary appliance. This is useful if you have some requirement to keep a monthly or six-monthly copy somewhere for compliance reasons. Cloud Tier is an overflow technology that allows you to have cold data migrated to a cloud target when the capacity of your environment exceeds 80%. Note that “coldness” is defined in this instance as older than 60 days. That is, you can’t just pump a lot of data in to your appliance to see how this works (trust me on that). The coldness level is configurable, but I recommend you engage with Cohesity support before you go down that track. It’s also important to note that once you turn on Cloud Tier for a View Box, you can’t turn it off again.

 

How Do I?

Here’s how to get started in 10 steps or less. Apologies if the quality of some of these screenshots is not great. The first thing to do is register an External Target on your appliance. In this example I’m running version 5.0.1 of the platform on a Cohesity Virtual Edition VM. Click on Protection – External Target.

Under External Targets you’ll see any External Targets you’ve already configured. Select Register External Target.

You’ll need to give it a name and choose whether you’re using it for Archival or Cloud Tier. This choice also impacts some of the types of available targets. You can’t, for example, configure a NAS or QStar target for use with Cloud Tier.

Selecting Cloud Tier will provide you with more cloudy targets, such as Google, AWS and Azure.

 

In this example, I’ve selected S3 (having already created the bucket I wanted to test with). You need to know the Bucket name, Region, Access Key ID and your Secret Access Key.

If you have it all correct, you can click on Register and it will work. If you’ve provided the wrong credentials, it won’t work. You then need to enable Cloud Tier on the View Box. Go to Platform – Cluster.

Click on View Boxes and the click on the three dots on the right to Edit the View Box configuration.

You then can toggle Cloud Tier and select the External Target you want to use for Cloud Tier.

Once everything is configured (and assuming you have some cold data to move to the cloud and your appliance is over 80% full) you can click on the cluster dashboard and you’ll see an overview of Cloud Tier storage in the Storage part of the overview.

 

 

Thoughts?

All the kids are getting into cloud nowadays, and Cohesity is no exception. I like this feature because it can help with managing capacity on your on-premises appliance, particularly if you’ve had a sudden influx of data into the environment, or you have a lot of old data that you likely won’t be accessing. You still need to think about your egress charges (if you need to get those cold blocks back) and you need to think about what the cost of that S3 bucket (or whatever you’re using) really is. I don’t see the default coldness level being a problem, as you’d hope that you sized your appliance well enough to cope with a certain amount of growth.

Features like this demonstrate both a willingness on behalf of Cohesity to embrace cloud technologies, as well as a focus on ease of use when it comes to reasonably complicated activities like moving protection data to an alternative location. My thinking is that you wouldn’t necessarily want to find yourself in the position of having to suddenly shunt a bunch of cold data to a cloud location if you can help it (although I haven’t done the maths on which is a better option) but it’s nice to know that the option is available and easy enough to setup.