Veeam Cloud Connect is a great technology that allows end users running in their premises their Veeam Backup & Replication environment, to add to a local protection also an offsite location where they can store backup copies or replicated virtual machines. As not every customer has a fast internet connection, Veeam Cloud Connect implements multiple data reduction tecniques to improve data transfer, but especially the initial full backup or full replica can be slow and painful for some customers with really small internet connection. That’s why seeding is such an important option in Veeam Cloud Connect: with it, tenants can create a local backup of their VMs and ship it to the service provider using a removable medium. The provider will then load the backup into Veeam Cloud Connect, so that the tenant can start immediately to do incremental backups or replications leveraging the seed.
I’ve seen lately in Veeam forums however that many end users and also some service providers are asking for detailed instructions about the seeding process, so even if Veeam has some knowledge base articles about this, I decided to create some detailed step-by-step posts to help people to successfully leverage seeding.
As there are different scenarios in Veeam Cloud Connect seeding, I decided to split this topic into three different blog posts:
Part 1 – how to seed a regular backup copy job (this post)
Part 2 – how to seed an encrypted backup copy job
Part 3 – how to seed a replication job
1. Create a local backup file at the tenant side
The first step of the process is the creation of a backup file at the tenant side. This file must include a backup of all the virtual machines that the tenant wants to send also to Veeam Cloud Connect. An existing file can be used if it contains already the desired VMs, or a new one can be created. In my example, I’m going to create a new backup copy job so that I can select which VMs I want to sent to Cloud Connect. I can choose between different Backup Copy job types:
I can create a regular VMware backup copy (or Hyper-V if this is what you are running), a vCloud one (to protect a vCloud Director environment by sending virtual machine backups in another location) or even Endpoint, if I’m using my Veeam Backup & Replication environment as the target for my Veeam endpoint backups. In my example, I’m creating a VMware Backup Copy job. I select the virtual machines I want to protect:
and i use a local repository to save the backup copy. I don’t need to setup all the other parameters like retention or GFS, as I will disable the job as soon as the first copy has been completed. I let the job complete, and then I disable the job itself. I don’t need it to run anymore, as the local seed has been created.
Note: be careful if you are using per-vm backup chains. You may want to store the backup copy in a repository without this option enabled, as Cloud Connect doesn’t support per-vm chains in v9.0 (it will soon in 9.5). Per-vm chains can be used if, like in my example, you are actually using one of the VMs that is in the chain.
2. Send the seeding files to the service provider
Once the backup copy job is completed, you can disable the job itself, and start to look at the files. If the per-vm backup files option is enabled on the repository you have used to create the seed, like in my example, there are going to be multiple files that need to be sent to the service provider. The easiest way to identify all the needed files is to open the Backups node, select disk (copy), select the backup copy job you just created, and read its properties:
As you can see in my example, we have three different backup files, one for each selected VM. They are all stored in the E:\Repo\Backup_Copy_Job_seed_for_VCC\ folder, together with the vbm file that describes the content of the files created by this job. These are the four files we need to send to the service provider. How to send them is out of the scope of this article.
3. Upload at the service provider into the tenant resources
Once the files have arrived at the service provider, he can start the upload process. First, a tenant with assigned backup resources should be created for the customer. This is in fact the location where the provider will need to drop the received files. So, inside the Cloud Connect infrastructure, the service provider will verify that the customer has backup resources assigned to him, and that the cloud repository has enough free space for the new backup files. The easiest way to verify these two requirements is to run a report directly from the Cloud Connect console:
The report is telling to the service provider that Tenant1, which is our user, has a total quota of 100GB, with still 66GB of free space. As we have four backup files, for a total of 48 GB, there is enough space in this tenant to upload the seeded files.
The service provider also sees that the cloud repository assigned to Tenant1 is physically stored into repo2, in the E:\Backups\ folder. Using the files option in Veeam Backup & Replication, he browses this position:
Here, the provider can upload the files received from the tenant, after creating a new folder to contain the received files. In my example, I hit here the “New Folder” option and I create a folder named Backup_Copy_Job_seeded_to_VCC. Then, I open the newly created folder and I upload here the received files.
4. Rescan Cloud Connect at the tenant side
Once the files are uploaded, the service provider notifies the tenant that the files are in place. The tenant opens his local Veeam Backup & Replication server, and runs a rescan of the service provider’s cloud repository:
As soon as the rescan is completed, we see that one new backup is added, and in fact a new “imported” backup set shows up. In the Backups -> Disk (Imported) folder the backup named Backup Copy Job seed for VCC shows up, with the 3 virtual machines we sent to the service provider.
5. Create a new backup copy job using the seed
It’s finally time for the tenant to use the seed. In the backup copy job, we create a new job called Backup Copy Job to Cloud Connect and we select the same three VMs used before: dc01, dc02 and sql in my case. We then select the cloud repository as our target, and below the selection box we hit the option Map Backup:
In the following screen, we select the backup chain that we sent before to the service provider:
We complete the backup job wizard, and we let the first run of the job complete. We can compare the local job used for creating the seed with the first execution of the job towards cloud connect to see immediately the advantages of the seeding process:
The local job reported above here would have transferred over internet around 48 GB of data; with the 8 Mbs line available in my lab, this would have been a 14 hrs transfer, if I would have been able to consume the entire bandwidth for the entire time. Many times however, the internet line is mostly needed by services and users of the company, thus the real consumable bandwidth would have been much lower. If we say for example we would have used 50% of it, the upload time would have been 28 hrs.
By leveraging the seed, the first run of the job towards cloud connect is already marked as incremental (see the top part of the report above here), and reading the logs we learn that the total amount of data written in the incremental file is around 4 GB. This is 1/14 of the size of the full backup. Even more, with the addition of the Veeam WAN Accelerator we had to move over internet only 218 MB of data. It took 1h 14m, compared to 14 hrs for the full. And because it was the first run going through the WAN accelerator, around 34 minutes were spent to create disk fingerprints. Next runs will not need that time, so the overall duration could be around 40 minutes per each incremental run.
Now, imagine these numbers with a bigger amount of data, or a smaller bandwidth, and you can see clearly why seeding off-site backups is so important!
In the next part, we’ll see how to seed an encrypted backup.