In my previous post, I explained how to complete a seeding operation for a backup copy job in Veeam Cloud Connect. One of the options that can be leveraged with Cloud Connect however is also encryption: people may trust their service providers, but as they are going to send copies of their production workloads off-site, encryption guarantees them complete confidentiality of the data stored at the service provider, that is not able at all to read the content. But how encryption may affect the seeding operation? Let’s find out.
1. Create a local backup file at the tenant side
The first part of the activity is exactly the same as in the previous post, except one thing: the encryption itself. So, while you can safely refer to the previous post for the different steps, one thing is different. During the backup job creation wizard, at the step called Target, select Advanced, and then the tab Storage:
Here you can enable Encyption by selecting the dedicated flag, and set a new password for this backup (or use an existing password). In this way, once the backup file is created, it is already encrypted. In my example, I chose to protect one virtual machine, called DC01. Once the backup is completed the local seed is ready, and the backup file can be found again by looking at the backup properties:
You can see in the upper part of the image that the backup file has the yellow key icon, meaning that the file is effectively encrypted. As I did in the previous post, my next step is to retrieve the VBK and VBM file in the location I got from the properties, and ship this backup to my service provider.
Steps from 2 to 4 are exactly the same as in the previous post, please refer to it to proceed.
2. Map the encrypted backup
Once the backup file is loaded at the service provider and the tenant has rescanned the content of his Cloud Repository, there will be a new backup set, as the rescan operation will indicate:
In fact, in the backups list we have now a new backup set, under Disk (Encrypted):
As a tenant I can create a new Backup Copy job, and when it comes to the step where the target has to be selected, I choose my Cloud Repository, and I also use the option to Map backup:
But, as you see below, there are the two previously loaded backups, not the new (and encrypted) that I uploaded before to the service provider:
The reason is exactly that the backup is encrypted, so before it can be used we need to unlock the backup set, by selecting the option specify password:
Once the encryption password has been successfully applied, the backup is moved under the Cloud backups and can be used as a seed for the backup copy job:
As we have mapped the new backup copy job to the seeded encrypted backup file, the new job also needs to have encryption enabled, otherwise the seed cannot be used:
Once the backup job is configured, we let it run and the first execution will be immediately an incremental run:
I’ve just shown you how to properly seed an encrypted backup. As you have seen during this procedure, the confidentiality of data is always guaranteed, as the provider doesn’t know the encryption password and doesn’t need to know it in order to seed the backup for his customers.
For the third and last part of this series, next time I’ll show you how to seed a replica job.