Veeam Backup target freedom of choice

The freedom of choice regarding Backup Repositories has always been a strength of Veeam Backup & Replication. With the V12 release, the Veeam Backup target freedom of choice becomes even greater. In this article, I will take a look at the new possibilities.

In the Veeam V12 launch event, one of the main areas of innovation is titled “Data Freedom” and includes the new direct to object storage capability.

To get more insight into what happens on the object storage, Veeam also introduces the new Smart Object Storage API (SOSAPI). Its first version enables object storage vendors to report the remaining disk space in a bucket and gives them machine-level control over Veeam backup streams. For example,
they can instruct Veeam Backup & Replication to write backup data of a particular machine directly to the specific cluster node for faster performance. Hopefully, this eliminates the need for Load Balancers in front of the object storage cluster for large deployments. The Unofficial object storage compatibility list for Veeam Backup & Replication currently lists three supported object storage vendors with SOSAPI support – Cloudian, Object First, and Scality.

Complete list of possible backup targets in Veeam Backup & Replication V12:

• Direct attached storage
  • Microsoft Windows server
  • Linux server
  • Hardened Repository
• Network-attached storage
  • SMB (CIFS) share
  • NFS share
• Deduplicating storage appliances
  • Dell Data Domain
  • ExaGrid
  • Fujitsu ETERNUS CS800
  • HPE StoreOnce
  • Infinidat InfiniGuard
  • Quantum DXi
• Object storage
  • Amazon S3, Amazon S3 Glacier, and AWS Snowball Edge
  • S3 compatible
  • Google Cloud
  • IBM Cloud
  • Wasabi Cloud Storage
  • Microsoft Azure Blob, Azure Archive Storage, and Azure Data Box

However, the Data freedom of choice is ensured not only by the Veeam Backup target freedom but also by flexible data management. One key aspect of data management is moving backup chains between repositories. For backup targets where Veeam acts filesystem agnostic, like direct attached storage or network-attached storage this was possible even prior to V12. But for deduplicating storage appliances and object storage it was not possible to move backup chains. With Veeam Backup & Replication V12 the new VeeaMover feature is introduced and delivers a native backup movement engine that can move backups between any backup repository type. This even works seamlessly when you modify a Backup Job and change the backup target, this was always a hassle prior to V12.

What means Direct to object storage?

Prior to the V12 release object storage could only be used as Archive and Capacity Tier in a Scale-Out Backup Repository (SOBR). From now object storage can be used in every SOBR Tier and also as a stand-alone repository.

To quote the awesome “Veeam Backup & Replication – What’s New in V12?” document:

Take full advantage of the unlimited scalability, built-in reliability and resiliency of on-premises and cloud object storage without having to sacrifice backup and restore performance. With V12, you can leverage object storage both as a regular backup repository and as ANY Scale-out Backup Repository™ (SOBR) tier. Object storage repositories can also be a target for both primary (i.e., backup) and secondary (i.e., backup copy) jobs.

https://www.veeam.com/veeam_backup_12_0_whats_new_wn.pdf

Backup target freedom of choice – SOBR

Scale-out Backup Repositories (SOBR) are the most common backup target option with many benefits and huge operational benefits.

From my point of view, the most important benefit or feature is the inherent copy or move mechanism between the Performance and Capacity Tier. You can choose between two modes or combine both, all three options achieve different goals:

•  Copy backups to object storage as soon as they are created
  • Meet at least two goals of the 3-2-1 Rule
    • There should be 3 copies of data
    • On 2 different media
• Move backups to object storage as they age out of the operational restores window
  • Free up space on the typically more expensive Performance Tier after a specific time

However, there are also a few limitations, for example, you cannot use a scale-out backup repository as a target for the following types of jobs:

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

Let’s have a look at the Scale-out Backup Repositories (SOBR) extends freedom of choice:

Performance Tier – Limitations for Object Storage

• You can add only one type of object storage repository as performance extents of one scale-out backup repository. For example, if the first extent is an Amazon S3 object storage repository, the second extent must also be an Amazon S3 object storage repository.

Capacity Tier – Possible Repository Types

A capacity extent can be either a cloud-based object storage repository or an on-premises object storage repository:

• S3-compatible object storage repository
• Amazon S3
• AWS Snowball Edge
• Microsoft Azure Blob storage
• Microsoft Azure Data Box
• IBM Cloud Object Storage
• Google Cloud Object Storage
• Wasabi Cloud Object Storage

Capacity Tier – Limitations for Object Storage

• You can add only one type of object storage repository as a capacity extent. For example, if you first added Microsoft Azure Blob object storage as a capacity extent, you cannot add Amazon S3 object storage as a second capacity extent.
• You cannot add more than one instance of Azure Databox or Snowball Edge AWS object storage repository as a capacity extent.

Archive Tier – Possible Repository Types

The archive tier consists of a single archive extent.

• Amazon S3 Glacier
• Microsoft Azure Archive Storage

Archive Tier – Limitations for Object Storage

• For archive extents, you must use the same object storage provider, that you use for the tier (either the performance tier or the capacity tier) from which data moves to the archive tier.
  • If data moves from the performance tier to the archive tier, the object storage on these tiers must be of the same provider. Capacity tier, in this case, can be another provider.
  • If data moves from the capacity tier to the archive tier, the object storage on these tiers must be of the same provider. Performance tier, in this case, can be another provider.

Backup target freedom of choice – Backup Copy

When using Backup Copy to meet the 3-2-1 Rule you have even more Backup Copy target freedom of choice as in the SOBR Capacity Tier. But this comes with some management overhead and other limitations.

When Backup Copy over SOBR Copy Mode

From my point of view, there are only a few cases where the additional management overhead of Backup Copy over SOBR Copy Mode should be taken into consideration:

• No object storage is available
• When Backup Copy Intervals matter and SOBR Copy mode does not meet requirements
• Long-Term Retention Policy (GFS) only on Copy Target (not sure if there really is a use case for)
• Copy Backups from external repositories 
• When Scripts need to be executed after Backup Copy Intervals
• You need to Copy only specific objects and not all data on the SOBR Performance Tier
• Copy target should be a Veeam Cloud Connect Service Provider (e.g. for DRaaS)

But SOBR and Backup Copy it is not an either-or question, you can also combine both. In this Example Backup Copy from SOBR to stand-alone object storage:

Cloud-based vs. on-premises object storage

Using cloud-based object storage might be the natural choice for storing your backup data because of several reasons.

• It’s definitely another location
• Cloud consumption model
  • No upfront investment for an on-premises backup storage
  • Scale on demand
• Less maintenance
• Available in several regions

However, if we look a little closer, there are also some disadvantages or design implications to consider.

• Impact on the Backup performance
• Impact on the Restore time
• Complex cost forecast (Storage Cost & Transaction Cost)
• Outbound or inbound data streams might saturate WAN Links or security devices

From my perspective, a specific design goal is the door opener for cloud-based object storage for large on-premises environments: Desaster Recovery to Cloud when the whole primary site (on-premises) is unavailable. Let’s have a look at this architecture:

In case of a disaster, these steps need to be done:

• Spin up new Veeam Backup & Replication Server
• Import Backup from Capacity Tier Bucket
• Restore to Cloud Platform native VM or VMware Cloud (VMware Cloud on AWS, Azure VMware Solution, etc.) VM

As always with recovery and especially with disaster recovery, all of this should be tested, documented and practiced regularly.

For more details, have a look at the chapter Importing Object Storage Backups of the Veeam Backup & Replication 12 User Guide.

Another option to add the capability of disaster recovery to the cloud is leveraging a Veeam Cloud Provider with DRaaS competency.

My personal recommendation

In most cases, cloud-based object storage as a SOBR Performance Tier, or a stand-alone repository for Backup Jobs creates more problems than it solves.

In case, you only have a single on-premises datacenter site, cloud-based object storage as SOBR Capacity Tier, or a stand-alone repository for Backup Copy Jobs is a great option to meet the 3-2-1 Rule.

References

• v12 – What’s New
• v12 – Release Notes
• Azure Price Calculator
• Veeam Size Estimator (VSE)
• Veeam Backup & Recovery v12 aims at four object storage targets by Blocks & Files
• Unofficial object storage compatibility list for Veeam Backup & Replication
• Veeam Backup Repository / Microsoft Azure Object Storage by @HammondRhys