Considerations and Limitations
This section lists considerations and known limitations for object storage repositories.
- Make sure to open required ports to communicate with object storage repositories in advance, as described in Used Ports.
- Make sure the S3 Compatible device you are adding supports AWS v4 signature. For more information about authentication requests, see this Amazon article.
- When adding Amazon S3 object storage, 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.
- For Microsoft Azure Blob Storage, Veeam Backup & Replication supports specific types of storage accounts and tiers. For more information, see Microsoft Azure Storage Accounts.
- For IBM Cloud Object Storage on-premise, Veeam Backup & Replication supports versions starting from 184.108.40.206.
- 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.
- 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 inevitable 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.
- When enabling Object Lock on an S3 bucket, use the None option for the object lock configuration mode.
Using Governance or Compliance default retention may result in unpredictable system behavior and data loss.
Note that Veeam Backup & Replication will automatically use Compliance object lock mode for each uploaded object.
For more information, see this Amazon article.
- 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 only to the Capacity Tier backups. It does not support the NAS backups.
- Immutable data is preserved as described in Block Generation.