Considerations and Limitations

This section lists considerations and known limitations for object storage repositories.

General

• 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 3.15.0.44.
• 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.

• 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:

1. You use SMB share/NFS share/deduplicating storage appliances as performance extents of your scale-out backup repository.
2. You have chosen Automatic selection for the gateway server at the Specify Shared Folder Settings step of the New backup repository wizard.
3. 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.

Immutability

• When enabling Object Lock on an S3 bucket, use the None option for the object lock configuration mode.

• 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.

Related Topics

• Immutability