What are Cloud Repositories?
A cloud repository is a possible storage location in the cloud of a service provider (SP) where Veeam users (tenants) can store their backed up data. Tenants can utilize the cloud repository as a target for backup and backup copy jobs and restore data from the cloud repository. It is a regular backup repository – but it is configured in the SP backup infrastructure and not on the local infrastructure of the tenant.
A cloud repository is a target for backups which is completely independent from the Veeam user's own infrastructure. The data is sent over through the Internet.
The SP can expose cloud repository resources to one or several tenants – the latter is called multi-tenancy which makes all cloud solutions cheaper than dedicated services. For each tenant, the SP allocates some storage space on the cloud repository. This storage space is consumed when the tenant runs backup tasks targeted at the cloud repository. The amount of space allocated to the tenant on the cloud repository is limited by a storage quota set by the SP, agreed to in the customer contract. You can of course always buy more quota for your data.
The 3-2-1 rule
Veeam’s rule of thumb regarding backups, which has been expanded since its first appearance to cover the new challenges of backup methodology.
To build a successful data protection and disaster recovery plan, it is recommended that you follow the following rules:
- 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.
The additional numbers:
- 1: one of your backups must be either air-gapped, immutable or offsite.
- 0: you must have zero errors when you do a restore test.
You must have at least two backups and they must be in different geographical locations - one must be secured in a way, that no one (not even you) can touch it. Practically, this means if a disaster takes out your production data and local backup, you can still recover from your offsite backup.
Backup Copies to the Cloud vs. Cloud Backups
You have two options to meet the requirements of the 3-2-1 rule: you either set up a backup copy targeted to the cloud or you set up a normal backup targeted to the cloud.
Cloud backups are simple backup jobs working the exact same way as a local backup does, with the only exception that their target is the cloud of the SP. When the backup job runs, a snapshot is made of the whole machine, and then from that snapshot, the backup file is created and sent to the cloud. This has the drawback, that the backup process might interfere with the operation of the source machine. This is called a “stun” – the source machine freezes for a couple of seconds while the snapshot is being made.
Backup copies however work in a different way. They use an already existing backup file of the source machine*, take the blocks from that source backup file and send them as a new backup file into the cloud. This has the added benefit, that the source machine is not touched. So while you make your normal local backup in the evening, out of business hours, you can make your copy during the day.
The recommendation is to use the backup copy method. Especially, because one backup copy of each machine is free of charge, and does not consume a license!
*Backup copies are normally used for VMs and not for physical machines. They can only be utilized for physical machines backed up by Veeam Backup Agents for Window and Linux, IF the agents are managed by Veeam Backup & Replication.
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 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. 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.
We always follow the best practices recommended by our vendors so that we can deliver the fastest and most powerful solutions to our customers.
Leave a Reply