Considerations and Limitations
This section lists considerations and known limitations for object storage repositories.
General Considerations and Limitations
- Make sure to open required ports to communicate with object storage repositories in advance, as described in Used Ports.
- Object storage gateway appliances that are used to store backup data in filer (CIFS/NFS) or block device mode (iSCSI/FC/SAS) are not supported if the backup data is offloaded to object storage and is no longer stored directly on the appliance.
Such gateway appliances are only supported in the following cases:
- All of the backup data is stored on the appliance altogether (that is, all of the backup chains are stored on the appliance as a whole and not scattered across multiple devices) and only additional copies of the backup data are transported to object storage.
- These appliances emulate a tape system (VTL) as an access protocol for Veeam Backup & Replication.
- Data in object storage bucket/container must be managed solely by Veeam Backup & Replication, including retention and data management. Enabling lifecycle rules is not supported, and may result in backup and restore failures.
- Use one bucket per scale-out backup repository to reduce metadata. Creating folders for multiple scale-out backup repositories within a bucket slows down processing, as metadata operations within the object storage are handled per bucket.
- Object storage systems that offload data to tape devices or any other sequential storage devices are supported only if they are added as an archive tier in a scale-out backup repository.
- If a backup chain contains backup files that are marked as corrupted by Health Check, then such corrupted files, as well as all subsequent files that go after the corrupted one are never offloaded. In such a scenario, offload is only possible starting from the full backup file that succeeds the backup chain with corrupted backups.
- Different object storage repositories mapped to the same cloud folder can be used for storing both the capacity tier backups and the NAS backups.
The same object storage repository (mapped to the same cloud folder) must not be used across multiple Veeam Backup & Replication servers for the same purposes as it leads to unpredictable system behavior and data loss.
For the same reason, two object storage repositories mapped to the same cloud folder must not be added to different scale-out backup repositories within one Veeam Backup & Replication server.
- Within a scale-out backup repository, the mount server of a performance extent will act as a gateway server of the capacity extent if all of the following is true:
- You use SMB share/NFS share/deduplicating storage appliances as performance extents of your scale-out backup repository.
- You have chosen Automatic selection for the gateway server at the Specify Shared Folder Settings step of the New backup repository wizard.
- For the object storage that you use as the capacity extent, you have not selected the Use the following gateway server check box at the Specify Object Storage Account step of the New object storage repository wizard.
Limitations for Amazon and S3 Compatible Object Storage
- Make sure that you add an S3-compatible object storage device fully compatible with the AWS S3 operations and AWS S3 Signature Version 4 standard.
- [For Amazon S3] Only the Standard, Standard-IA and One Zone-IA storage classes are supported. For more information about Amazon S3 storage classes, see this Amazon article.
Limitations for Microsoft Azure Object Storage
- Azure object-level immutability is not supported by Veeam Backup & Replication. In Azure, it is possible to set account-level or container-level immutability policy, these can be overridden by object-level immutability. Veeam Backup & Replication currently does not support these features. Do not enable this feature as this might lead to a significant data loss.
- [For Microsoft Azure Blob storage] Veeam Backup & Replication supports specific types of storage accounts and tiers. For more information, see Microsoft Azure Storage Accounts.
- Currently, Veeam Backup & Replication does not support the Versioning feature for Microsoft Azure object storage. If you plan to use an account with blob versioning enabled, keep in mind this may result in extra costs for storing objects that have been removed by the retention policy.
- [For Microsoft Azure Archive storage] Microsoft Azure has certain limits (quotas) on maximum amount of resources used. The quotas depend on the type of proxies you have selected. If you exhaust a quota, you will be unable to use Microsoft Azure Archive storage. For more information about Microsoft Azure quotas, see this Microsoft article.
- [For Microsoft Azure Archive storage and Azure Blob storage] Soft delete is not supported by Veeam Backup & Replication.
Limitations for Google Cloud Object Storage
Currently, Veeam Backup & Replication does not support the Object Versioning and Bucket Lock features for Google Cloud object storage.
Enabling either any or both of these features on the bucket may result in unpredictable system behavior and data loss, as well as in extra costs for storing objects that have been removed by the retention policy.
Limitations for IBM Cloud Object Storage
- For IBM Cloud Object Storage on-premise, Veeam Backup & Replication supports versions starting from 22.214.171.124.
- Currently, only the Standard storage class is supported for IBM Cloud object storage.
- After you have created an S3 bucket with Object Lock enabled, check that the default retention is disabled. For this, edit Object Lock retention settings as described in AWS documentation.
The default retention may result in an unpredictable system behavior and data loss. However, note that Veeam Backup & Replication will use Compliance object lock mode for each uploaded object. For more information on the retention modes, see AWS documentation.
- Versioning and Object Lock must not be enabled or disabled on buckets that have been added to Veeam Backup & Replication as it may lead to unpredictable system behavior and data loss.
- If you plan to use the immutability feature with the existing S3 bucket containing backups created by 9.5 Update 4, keep in mind that both Versioning and Object Lock must be enabled on the bucket simultaneously and immediately before enabling the immutability feature. Any other approach will lead to backup offload failures and inability to correctly interact with backups in the bucket.
- The immutability feature is applicable to the Capacity Tier and Archive Tier backups. It does not support the NAS backups.
- Immutable data is preserved as described in Block Generation (applicable only to Capacity Tier).