Together with my colleague Koen Buddelmeijer, I presented a session at Veeam’s VeeamON conference today. We talked about using Cloud Connect in different use cases, going beyond the current Backup-as-a-Service use case. Naturally, we spent some time discussing the new features of Veeam Backup & Replication version 9 and how it focusses on the Disaster-Recovery-as-a-Service or DRaaS use case as well.

Using Cloud Connect in 3 unexpected, awesome ways

I want to do a short recap of our session in this blog post so that the information from the session is available to those who did not attend the VeeamON conference.

Easy as 1, 2, 3.

First, we talked about the importance of having a sound data availability strategy. This strategy is summarized using the ‘3-2-1’ rule:



This rule basically states that you need at least three copies of your data (one on your primary, production environment and two backup copies) on two different media (separate primary and backup storage systems, preferably on storage by different vendors) and one backup copy placed off-site (using a secondary site, a tape shipping service or a cloud-based BaaS or DRaaS solution).

Now, Cloud Connect solves the off-site issue and makes the back-up recoverable to IaaS, DRaaS or back on-prem via BaaS.


Why B/DRaaS make sense for customers

I talked about tape not being such a good medium anymore, since it doesn’t enable fast or easy full-on recovery of your data center.
With that out of the way, let’s look at the option of a secondary data center. In my experience, customers don’t really want to deal with the cost and complexity of building and maintaining a secondary site and especially storage growth issues. They really want to react flexibly to changing requirements and have no patience for downtime or data loss.


What is Veeam Cloud Connect?

To figure out if Cloud Connect fits the BaaS and DRaaS bill, let’s reiterate what the product does.

A technology that allows a Service Provider to easily set up and maintain a secure multi-tenant environment for hosting off-site back-ups and replicated VMs

We can see that Cloud Connect is a good fit to enable BaaS and DRaaS:

  1. Cloud Connect is cloud-based (or delivered ‘as-a-Service’)
  2. It’s owned and operated by the Service Provider, so the customer doesn’t need to build their own data center.
  3. It’s very easy to set up and connect to with a single-port SSL connection (without VPN or dedicated lines).
  4. It offers secure and WAN-optimized data transfer.
  5. As it’s a shared service, it allows for flexible, pay-as-you-go resource usage.
  6. It can be backed by a Service Level Agreement, detailing and guaranteeing difference service levels.
  7. Cloud Connect is specifically designed for Service Providers to offer BaaS and DRaaS services in a secure, isolated multi-tenant way.


Use Case – Migrate on-prem tenant workloads to IaaS

For the IaaS-platform we’ve been building at OGD ict-diensten, Cloud Connect really enabled a very specific use case: migrate on-prem tenant workloads to our IaaS-platform using Cloud Connect. A very similar use case would be using Cloud Connect to migrate a tenant to a new (or rebuilt) data center.

In order to utilize this scenario, the tenant needs to have Veeam Backup & Replication running in their on-prem data center. Optionally, the Service Provider can choose to install Veeam B&R at the start of the migration project. I’m really excited about the newly announced Veeam Managed Backup Portal for Service Providers, because this allows us as a Service Provider to manage those (temporary) on-prem Veeam installations from a central Web Portal.
As a side-note: there are a couple of options to license those on-prem installations if it’s specifically implemented as part of a Cloud Connect solution. We’re using so-called project licenses that enables us to include the on-prem licenses in our Veeam Cloud & Service Provider rental agreement.

In addition to the on-prem installation, the customer needs a staging repository, used to hold the backup files before they’re sent off to Cloud Connect. To efficiently transfer data to Cloud Connect, the customer needs a decent amount of bandwidth. I usually recommend a minimum of 50 Mbit, but it really depends on the amount of data in each incremental backup run. For the initial full backup, we usually use an offline pre-seed using a portable disk.

Lastly, and pretty important, too, is that Cloud Connect (in any use case) won’t be able to do a cross-hypervisor migration. So if the customer’s running VMware vSphere, the infrastructure behind Cloud Connect needs to run vSphere, too.

I talked about some of the design considerations to take into account when designing a Cloud Connect environment. But really, I’d recommend you look at the Cloud Connect Reference Architecture, written by Cloud Connect guru Luca Dell’Oca. That document talks about how to design and implement (Cloud) Repositories, Cloud Gateways and WAN Accelerators.

Use Case – Migrate workloads cross-platform to IaaS

Look up a couple of paragraphs and notice how I mention that cross-hypervisor migrations are not possible. That’s kinda restrictive, don’t your think? That’s why we developed a method to actually do cross-hypervisor migrations.

We’re using Veeam Endpoint Backup to make this happen. Cool thing that was announced at VeeamON 2015 is the Veeam Backup for Linux product, that enables us to do cross-platform migrations for Linux source machines, too!

Besides running a IaaS-platform, we have a co-location facility. This facility is completely integrated into the IaaS-platform using NSX-v using VLAN-to-VXLAN bridging and allows customers to bring their own hardware to the IaaS-platform.

Using VEB and VBL enables a couple of other use cases for us:

  1. Migrate physical machine to IaaS VM
  2. Migrate physical machine to a physical machine in the co-location facility
  3. Re-protect physical machines in the co-location facility


These use cases build on the first use case, and as a result have the same requirements: on-prem Veeam install for the Cloud Connect client-side and intermediate repository. There are a couple of technical challenges as well, such as making the bare-metal ISO available to the restore target (a physical or virtual machine) on-demand to the tenant and making the Cloud Connect Repository available to this target as the Cloud Connect Repository usually is tucked away in the Service Provider’s back-end network and you don’t usually want to expose that network to the tenant directly.

Use Case – DRaaS for on-prem workloads

This Use Case is also known as ‘OMGWTF Veeam v9 is awesome’, as v9 brings much of the DRaaS features to Cloud Connect.

In short, DRaaS with Cloud Connect entails the following:

  • Use the IaaS-provider’s infrastructure as a DR-site
  • Copy backup data off-site with Cloud Connect
  • Reserved compute resources on IaaS-platform for failover

v8 versus v9

I want to focus on the differences between v8 and v9 for a little bit:

Cloud Connect v8 is BaaS-focused

  • Restore to tenant on-prem infrastructure
  • Assumes on-prem infrastructure is still there
  • Requires custom steps to failover, failback and re-protect for DR-like features
  • Assumes Backup Copy job type (backup on repository)

Cloud Connect v9 is DRaaS-focused

  • Restore, failover and failback to anywhere
  • Initiate restore from DR-site
  • Failover, failback and re-protect handled out-of-the-box
  • Assumes Replication job type (replication to hypervisor & primary storage)

With constructs like the Cloud Host, the Self-Service Web Portal (with single-click failover and failover plans and failover testing) and the Transparant network extension, v9 is really a large step forward in the DRaaS-space.

I won’t dive into v9 too much, other than giving you some links to read up on:

  1. Veeam Availability Suite v9
  2. Veeam Cloud Connect Replication coming in v9
  3. An Exclusive Preview of Veeam Cloud Connect Replication
  4. Delivering DRaaS with Veeam

Automating Cloud Connect – Cloud Connect in your DevOps toolchain

Let’s switch to automating all the stuff I talked about previously, since automating is key to delivering functionality in a self-service manner to our tenants. This is where Koen comes in as he’s our DevOps engineer and is responsible for automating the IaaS-platform and publish features in the self-service portal, which is based on vRealize Automation.

Using the Veeam Enterprise Manager’s RESTful API, it’s pretty easy to automate the various Cloud Connect tasks into workflows.

Screen Shot 2015-10-27 at 13.59.12

Using a couple of short demos, he walks us through the steps of automating a couple of Cloud Connect tasks:

Set up endpoints

Generate workflows from endpoints.

Run the workflows to create a tenant.


Combine the api workflows.

Run the wrapper workflow to create a tenant.

Example of an advanced workflow.

Bonus Use Case – Transparant exit strategy

Wait, a bonus use case? Yes! Being able to automate your environment on this level creates a use case for itself: using automation as an enabler for a customer exit strategy.

Let’s look at what an exit strategy actually is:



A customer’s plan of action to move away from the provider if provider cannot deliver quality of service

Embracing and dealing with customers that have a sound exit strategy is one of the key differentiators for a Service Provider, and automation adds to the value you deliver to customers.

In our case, it pushes us to set and meet SLA-goals in Availability, Recoverability and Features to deliver the best service possible and protects against risk of a failed relationship.

We expose a lot of the features in our platform to our self-service portal, so our customers can use these features without us, the service provider, as an intermediary. This really prevents customer lock-in and forces us to deliver the best possible service instead of focussing on financial drivers alone.

What I’m getting at here is that a customer should always have the self-service ability to leave, without us blocking the effort or even knowing about it. Also, leaving our service won’t cost the customer anything on top of the regular cost structure. They also get their data out in an industry standard and platform-agnostic format.

We use the self-service portal, documentation and standard changes/procedures to enable a customer exit strategy, forcing us to really deliver the best possible service to keep customers as happy as possible.

As a side-note, this is exactly what our customers are saying about us:
Our Outsourcing Recommendation Score by Giarte is 100%, which means 100% of our customers would recommend us as an outsourcing service provider. This confirms we work hard to keep our customers happy. Read up on this here and here (both in Dutch, unfortunately).


In this blog post, I recapped our session at VeeamON called Using Cloud Connect in 3 unexpected, awesome ways. I want to leave you with the key take aways for the session:

  • BaaS, DRaaS and IaaS are complementary
  • Requires little investment to add BaaS/DRaaS to IaaS
  • Cloud Connect in v8 is cool; in v9 it’s awesome
  • Upgrade to v9 and implement new features
  • Make sure to automate tasks and expose to tenant
  • Make on boarding as smooth as possible
  • Strive for perfection: Top Notch Quality, Service Level, Features
  • Differentiate yourself on additional services
  • Implement customer exit strategy enablers
  • Implement feature self-service