Tag Archives: Cloud Connect Backup

Update 4 for Service Providers – Tenant Connectivity with Cloud Connect Gateway Pools

When Veeam Backup & Replication 9.5 Update 4 went Generally Available a couple of weeks ago I posted a What’s in it for Service Providers blog. In that post I briefly outlined all the new features and enhancements in Update 4 as it related to our Veeam Cloud and Service Providers. As mentioned each new major feature deserves it’s own seperate post. I’ve covered off Tape as a Service and RBAC Self Service, and today i’m focusing on a much requested feature…Cloud Connect Gateway Pools

As a reminder here are the top new features and enhancements in Update 4 for VCSPs.

Gateway Pools for Cloud Connect

Cloud Connect has become the central mechanism for connectivity and communication between multiple Veeam services. When first launched with Cloud Connect Backup in v8 of Backup & Replication, the Cloud Connect Gateways where used for all secure communications between tenant backup server instances and the Veeam Cloud and Service Provider (VCSP) Cloud Connect backup infrastructure. This expanded to support Cloud Connect Replication in v9 and from there we have added multiple products that rely on communications brokered by Cloud Connect Gateways.

As of today Cloud Connect Gateways facilitate:

  • Cloud Connect Backup
  • Cloud Connect Replication
  • Full and Partial Failovers for Cloud Connect Replication
  • Remote Console Access
  • Veeam Availability Console Tenant and Agent Management
  • Veeam Backup for Microsoft Office 365 Self Service

With regards to acting as the broker for Cloud Connect Backup or Replication, prior to Update 4 the only way in which a VCSP could design and deploy the Gateways was in an all or nothing approach when it came to configuring the IP address and DNS for the service endpoint. When considering VCSPs that also provide connectivity such as MPLS for their customers it meant that to leverage direct connections that might be private the options where to either use the public address or setup a whole new Cloud Connect environment for the customer.

Now with Update 4 and Gateway Pools a VCSP can configure one or many Gateway Pools and allocate one or more Cloud Connect Gateways to those pools. From there, tenants can be assigned to Gateway Pools.

Cloud Gateways in a Gateway Pool operate no differently to regular Cloud Gateways. As with previous Cloud Gateways, If the primary gateway is unavailable, the logic built into Veeam Backup & Replication will failover to another Cloud Gateway in the same pool.

If tenants are not assigned a Cloud Gateway Pool they can use only gateways that are not a part of any cloud gateway pool. That situation is warned in the UI when configuring the gateways.

Wrap Up:

The introduction of Cloud Connect Gateway Pools un Update 4 was undertaken due to direct feedback from our VCSPs who wanted more flexibility in the way in which the Cloud Gateways where deployed and configured for customers. Not only can they be used to seperate tenants connecting from public and private networks, but they can also be used for Quality of Service by assigning a Gateway Pool to specific tenants. They can also be used to control access into a VCSPs Cloud Connect infrastructure if located in different geographic locations.

For a great overview and design considerations of Cloud Connect Gateway Pools and Gateways themselves, check out Luca’s Cloud Connect Book here.

References:

https://helpcenter.veeam.com/docs/backup/cloud/cloud_gateway_pool.html?ver=95u4

A Deeper Look at Insider Protection in 9.5 Update 3

With the release of Backup & Replication 9.5 Update 3 we introduced the concept of a Recycle Bin for customers sending offsite cloud backups to VCSPs using Veeam Cloud Connect. This deleted backup protection…or Insider Protection allows the VCSP to enable the deleted backups protection option for specific tenants and looks to add another level of data security for cloud based backups in the case of a malicious user gaining access to the Backup & Replication Console or in the case of accidental deletion by an administrator.

As shown above, this is set by checking a box (Also via PowerShell) in the properties of the tenant account. Once checked the SP will choose the retention period by setting the Keep deleted Backup files for <N> days option. With this option enabled, when a backup or a specific restore point in the backup chain is deleted or aged out from the cloud repository. The actual backup files are not deleted immediately, instead, they are moved to a _RecycleBin folder on the repositories.

Once moved, backup files in the recycle bin do not consume tenant quota however they obviously consume general storage. With that in mind it should be considered by the SP to charge for that used storage. I will release a post shortly detailing some tips on how best to size and charge for the recycle bin storage per client.

At the tenant end those backup files that are moved into the recycle bin are not registered and will not show up in the job information window. They can’t access or do anything with the files in the recycle bin. For the moment if a tenant wants to restore data they must contact the SP to obtain the necessary backup files. Once the retention period has expired all files that fall out of that period are deleted.

Basic Mechanics:

When the option is checked for a tenant a new folder is created under the _RecycleBin\<tenant> folder of the repository. In the case of a Scale Out Backup Repository there is a recycle bin folder created per extent which ensured that any split tenant VM files are processed locally and not between extents.

Once files in the repository start to age out the tenant folder will start to populate with backup files. If there is an event that triggers a change of retention or a VM removed from a job or the deletion of a whole job, any remaining VBK or VIB files in the tenant repository are moved into the recycle bin.

The files remain in the _RecycleBin folder until the retention period has passed or if the service provider moves them out of the folder for recovery purposes.

Working Example:

I have a Cloud Connect Backup account that I am using to back up five VMs that reside on premises, using a standard Backup Job with Forward Incrementals and a Synthetic Full done once a week. I have configured this job to keep two restore points.

I then have configured a secondary destination for the job via a Backup Copy Job to the Cloud Repository and I have set a GFS to happen weekly so I have a full archive offsite. If I hadn’t enabled GFS retention (for those running Update 3) a warning would appear as shown below.

Tip: If the tenant plans to create off-site copies of backed-up data with a backup copy job, it should enable GFS retention settings in the job properties. This way, Veeam Backup & Replication will be able to protect backups created by the job against an attack when a hacker reduces the job’s retention policy and creates a few incremental backups to remove backed-up data from the backup chain.

The Cloud Connect Tenant account has a deleted backup protection setting of 2 days configured as shown in the first image of this post.

Below is the local jobs folder structure:

Looking at the Cloud Connect repository (split over two SOBR extents) you can see that the main repository holds the VM backup files as per the job configuration. Notice the GFS _W files there as well.

Taking a look at the _RecycleBin folder for the tenant after a few days the aged out incremental will start to appear in the folder. Notice that there are no full backup files in the recycle bin at this stage.

Tip: The retention period will look at all backup jobs completed in a 24 hours period and have any expiring or deleted backup files moved into the recycle bin directory. This means that if you are copying up VMs that have a local backup interval of every 4 hours you will have six lots of backup files ageing out daily.

In this example I’m simulating an malicious attack or accidental deletion the VM (TPM03-RMQ-01/VM-120) from the backup. For the sake of this example we are deleting the VM from the Backup & Replication Console under Backups and Cloud. If the Included Archived copies option was chosen then the GFS weekly full backup file is also moved into the recycle bin.

Once the deletion process has been completed the _RecycleBin folder for the tenant will now be populated with the deleted full, plus three incremental files. If the Included Archived copies option was chosen then the GFS weekly full backup file is also moved into the recycle bin.

These will stay in the recycle bin until the retention period is met. From here these files can be transported back to the tenant to be recovered (see here for full process) from within the on-premises Backup & Replication console.

Conclusion:

As shown above, deleted backup protection or Insider Protection is an excellent enhancement to Cloud Connect Backup. It goes some way to having an air gapped backup in the cloud and protects against malicious attacks and rogue or clumsy administrators. There is a lot happening behind the scenes to make it work, however the concept is simple and this features extends the 3-2-1 rule by protecting that offsite copy as part of the Cloud Connect solution. VCSP’s should be looking to offer this as a value add to their clients and Veeam customers should be looking to take advantage of Cloud Connect Backup and Replication for their offsite backup and replication needs.

References:

https://helpcenter.veeam.com/docs/backup/cloud/cloud_connect_bin.html?ver=95

https://helpcenter.veeam.com/docs/backup/cloud/cloud_connect_bin_restore.html?ver=95

VCSP Important Notice: 9.5 Update 3 RTM Is Out…With Insider Protection and more!

Earlier this week, Veeam made available to our VCSP partners the RTM of Update 3 for Backup & Replication 9.5 (Build 9.5.0.1335). Update 3 is what we term a breaking update, meaning that if a Cloud Connect tenant upgrades from any previous 9.5 version before VCSPs this will break backup or replication functionality. With that in mind the RTM has been made available for our VCSP partners to ensure it is installed and tested before being pushed out to production before the GA release. Veeam Backup & Replication releases from 8.0 (build 8.0.0.2084) can write backups to a cloud repository on 9.5 Update 3, and any release from 9.0 (build 9.0.0.902) can write replicas to a cloud host on 9.5 Update 3.

Update 3 is a very significant update and contains a number of enhancements and known issue fixes with a lot of those enhancements aimed at improving the scalability of the Backup & Replication platform that VCSPs can take advantage of. One important note is around new licensing for Cloud Connect Backup that all VCSPs should be aware of. There is a detailed post in the VCSP Forums and there will be emails sent to explains the changes.

We have also pushed out a number new features for our VCSPs with two of them highlighted below. One of which is the new Insider Protection feature or Recycle Bin for Cloud Connect Backups and the other is the a long awaited ask from our providers in the Maintenance Mode for Cloud Connect.

  • Insider protection: Option to hold backups deleted from a tenant’s cloud repository in a “recycle bin” folder for a designated period of time. For more information, see this post in the VCSP forum.

    • Maintenance Mode: Allows you to temporarily stop tenant backup and backup copy tasks from writing to cloud repositories. Already running tenant tasks are allowed to finish, but new tenant tasks fail with an error message indicating that the service provider infrastructure is undergoing maintenance. This is supported at the tenant end in 9.5 Update 3 GA, Agent for Windows 2.1 and Agent for Linux 2.0.

There has also been a lot of work to improve and enhance scalability in the Backup & Replication Cloud Connect functionality to accomodate the increasing usage of Veeam Agent for Windows of which there is a new version (2.1) coming in early December and prepare for the release of Veeam Agent for Linux (2.0) that will include support for backups to be sent to Cloud Connect repositories. For the recently released Veeam Availability Console, Update 3 is 100% compatible with the 2.0 GA (Build 2.0.1.1319) released last week and is good from Update 2 or later.

Conclusion:

Once again, Update 3 for Veeam Backup & Replication is an important update to apply for VCSPs running Cloud Connect services in preparation for the GA release which will happen in about two weeks. Once released I’ll link to the VeeamKB for a detailed look at the fixes but for the moment, if you have the ability to download the update do so and have it applied to your instances. For more info in the RTM, head to the VCSP Forum post here.

Veeam Cloud Connect Backup: What are Subtenant’s?

When Veeam Backup & Replication 9.5 was released, there where a lot of significant features added to enhance Veeam Cloud Connect Backup and Replication. One of the lesser known features that came out in 9.5 was the addition of Cloud Connect Subtenants. This in effect was a pre-seeded feature for our Veeam Agent for Microsoft Windows that went into public beta earlier in the year and is set to GA sometime in Q2 of 2017.

Subtenants can be configured by either the VCSP or by the tenant consuming a Cloud Connect Backup service. Subtenants are used to carve up and assign a subset of the parent tenant storage quota. This allows individual agents to authenticate against the Cloud Connect service with a unique login allowing backups to Cloud Repositories that can be managed and monitored from the Backup & Replication console.

End users on the tenant side can connect to the SP and create backups on the cloud repository under the tenant account. However, it is recommended to provide every tenant-side user with a separate subtenant account. In this case, the tenant or SP can allocate storage resources on the cloud repository individually for every subtenant so that subtenants’ data is stored in the cloud in an isolated and segregated way

Note that a subtenant account can not be used to connect directly to a Cloud Connect Service Provider from the Backup & Replication console and is only intended for use with the agents. If you try to do that you will see the error below:

As a Veeam Cloud Service Provider offering Cloud Connect Backup services it’s important that if not done so already…start wrapping your heads around the subtenant construct and how it works with Veeam Agent for Microsoft Windows (currently in beta) as you want to be in a position to take advantage of them for when Veeam Agent for Windows does go GA.

Stay tuned to veeam.com for more blog posts around the Veeam Agent for Microsoft Windows ability to backup to Cloud Connect repositories using subtenants and also keep an eye out on my fellow team member, Clint Wyckoff’s blog cdubhub.us for some great upcoming content around all things Veeam Agent for Microsoft Windows.

References:

https://helpcenter.veeam.com/docs/backup/cloud/cloud_connect_subtenants.html?ver=95