In the Cloud - Backups, Jobs, Repositories and Security

Cloud Repositories

The cloud repository is a storage location in the cloud where tenants can store their VM data. Tenants can utilize the cloud repository as a target for backup and backup copy jobs and restore data from the cloud repository. The cloud repository is a regular backup repository configured in the SP backup infrastructure.

The SP can expose cloud repository resources to one or several tenants. For each tenant, the SP allocates some storage space on the cloud repository. This storage space is consumed when the tenant runs data protection tasks targeted at the cloud repository. The amount of space allocated to the tenant on the cloud repository is limited by a storage quota.

Source: https://helpcenter.veeam.com/docs/backup/cloud/cloud_connect_repository.html?ver=110 

3-2-1 rule

To build a successful data protection and disaster recovery plan, it is recommended that you follow the 3-2-1 rule:

• 3: You must have at least three copies of your data: the original production data and two backups.
• 2: You must use at least two different types of media to store the copies of your data, for example, local disk and cloud.
• 1: You must keep at least one backup offsite, for example, in the cloud or in a remote site.

Thus, you must have at least two backups and they must be in different locations. If a disaster takes out your production data and local backup, you can still recover from your offsite backup.

Source: https://helpcenter.veeam.com/docs/backup/vsphere/backup_copy.html?ver=110 

Backup Copies

When the backup copying process starts, Veeam Backup & Replication accesses backup files in the source backup repository, retrieves data blocks for a specific machine from the backup file, copies them to the target backup repository, and composes copied blocks into a backup file in the target backup repository. The backup copying process does not affect virtual and physical infrastructure resources, does not require creation of additional VM snapshots or VSS snapshots and does not produce load on machines whose backups are copied.

Source: https://helpcenter.veeam.com/docs/backup/vsphere/about_backup_copy.html?ver=110 

Cloud Backups

In Veeam Backup & Replication, backup is a job-driven process. To back up VMs into a cloud repository, you must configure a backup job and target it to a cloud repository. Veeam Backup & Replication backs up a VM image as a whole: it copies VM data at a block level unlike traditional backup tools that process guest OS files separately. Veeam Backup & Replication retrieves VM data from the source storage, compresses and deduplicates it and writes to the backup repository in Veeam’s proprietary format. 

Veeam Backup & Replication conducts both full and incremental backup. During the first run of a backup job, Veeam Backup & Replication creates a full VM backup (VBK). All subsequent job cycles produce incremental backups: VIB if forward incremental backup is used or VRB if reversed incremental backup is used. The number of increments kept on disk depends on retention policy settings.

Source: https://helpcenter.veeam.com/docs/backup/cloud/cloud_connect_backup.html?ver=110 

Security in the Cloud

Being a multi-tenant storage resource, the cloud repository appears as a logically separate backup repository to every tenant. Data in the cloud repository is segregated and isolated. Every tenant has its own folder on the cloud repository where tenant VM data is stored. Tenants do not know about other tenants who work with the cloud repository, and have no access to their data.

All possible threats can come only from an external resource, and never from within the backups themselves. In other words, if Tenant A does a backup of a VM that was infected by a virus, that virus can never spread to the backups of Tenant B or to the SP's Veeam infrastructure.

Another consideration of backup repository configuration is Veeam's ability to leverage job threads. If several backup repositories point to the same device with multiple possible job threads, such a configuration can create bottlenecks in job processing. Consider the following hypothetical scenario: Veeam Cloud Connect is configured to run the maximum amount of 4 concurrent jobs toward 1 repository. Veeam starts processing a job using 4 threads configured for Repository A, then another backup job starts running, pointing to Repository B with 4 more threads. Veeam "thinks" that the two repositories point to 2 different storage devices and tries to run 2x4 concurrent threads. However, the 2 repositories both point to the same storage device which can handle only 6 concurrently running IO processes. This setup will make 2 threads wait and possibly make all processes to hang. Hence, a bottleneck is created which is lagging all running jobs. If only one repository is created pointing to one storage device, Veeam can handle the thread processing, protecting the storage device from hanging or lagging. 

Because of thread concurrency and because of the logical segregation of data in a repository, it is best practice to create one backup repository per one storage device and NOT per customer. Customers will see the repository as a separate logical entity in their own VBR console or SP console, and will never see the data of other customers.

Source: https://helpcenter.veeam.com/docs/backup/cloud/cloud_connect_repository.html?ver=110 and Veeam Support