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 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.
Multi-factor authentication (MFA) is not supported for object storage repositories.

Important

Only one backup server must interact with an object storage repository. If you want to perform disaster recovery testing, you can add the object storage repository to another backup server. However, on the initial backup server, you must switch the object storage repository to the Maintenance mode. Otherwise, metadata on the object storage can get corrupted or out of sync, and you will not be able to restore data.

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.

Important

Consider the following:

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 to connect to object storage using a gateway server at the Account step of the New Object Repository wizard.

The backup proxy that processes backup data must meet the following requirements:

It must be an on-premises server as close as possible to a backup server.
It must have access to the cloud storage that you use as an object storage repository.

The backup proxy that processes VM data must be as close as possible to a backup server.
A backup server and a gateway server must have internet access to verify that the certificates installed on object storage repositories are valid.

Considerations and Limitations for Direct Backup to Object Storage

Reverse incremental backup method for is not supported.
Synthetic full backup method is not supported.
Compact full backup file option is not supported.
You cannot back up directly to object storage repositories backups created by Veeam Plug-ins for Enterprise Applications.

Limitations for Amazon, Wasabi Cloud Storage 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 AWS Documentation.
S3 compatible storage systems with the eventual data consistency model are not supported.
You cannot add as performance extents one Wasabi bucket as an S3 Compatible Object Storage and another Wasabi bucket as a Wasabi Cloud Object Storage to the same type of tier (either performance tier or capacity tier) of a scale-out backup repository.

Limitations for Microsoft Azure Object Storage

[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 Microsoft Azure Blob storage] Veeam Backup & Replication does not support Azure Germany since Microsoft closed Microsoft Cloud Deutschland.
Veeam Backup & Replication supports the Versioning feature for Microsoft Azure object storage repositories for which immutability is enabled.
[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 Microsoft Docs.
[For Microsoft Azure Blob storage] Veeam Backup & Replication does not support soft delete for blobs.
Veeam Backup & Replication performs operations only on a blob level. You cannot create Azure containers or storage accounts from the backup infrastructure.
Veeam Backup & Replication does not support object-level immutability and default immutability policies assigned to Azure storage accounts. You must set immutability for an Azure container where backed-up objects will reside. For more information, see Microsoft Docs.

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.

Important

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. For more information, see Object Versioning and Bucket Lock.

Limitations for IBM Cloud Object Storage

For IBM Cloud Object Storage on-premise, Veeam Backup & Replication supports versions starting from 3.15.0.44.
Veeam Backup & Replication is supported on all IBM Cloud Object Storage (COS) deployment models. This includes on-premise, public cloud, and hybrid models. For the IBM public cloud, the following storage classes are supported: Standard, Vault, Cold Vault and Smart Tier.
Veeam Backup & Replication does not support Archive and Accelerated Archive storage classes in the IBM public cloud.

Considerations and Limitations for Immutability

[Amazon S3] After you have created an S3 bucket with Object Lock enabled, check that the default retention is disabled.

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. For more information on how to disable retention settings for S3 bucket, see AWS documentation. For more information on how to disable retention settings for Azure container, see Microsoft Docs.

[Azure Blob Storage] Make sure that the Azure Blob storage settings meet the following requirements: when you configure an Azure storage and an Azure container:

When you create a storage, make sure you enable versioning for blobs.
When you create a storage, do NOT enable version-level immutability. By default, this option is enabled and you must disable it. For more information, see Microsoft Docs.
When you create a container, you must enable version-level immutability. For more information, see Microsoft Docs.

[Azure Blob Storage] The default immutability policies are not supported.
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.
[Azure Blob Storage] Do NOT enable immutability for already existing containers in the Azure portal. Otherwise, Veeam Backup & Replication will not be able to process these containers properly and it may result in 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.

Version-level immutability support for Azure storage accounts is not supported.
Immutable data is preserved as described in Block Generation (applicable only to Capacity Tier).