General Limitations

The following limitations apply to all storage systems supported by Veeam Backup & Replication:

• Backup infrastructure
• Backup from Storage Snapshots
• Snapshot Orchestration and Backup from Storage Snapshots with Snapshot Retention
• Veeam Explorer for Storage Snapshots

Backup Infrastructure

Backup infrastructure for storage snapshots has the following limitations.

• CHAP authentication is not supported for storage systems working over iSCSI.
• SAS connections are not supported.
• Veeam Backup & Replication does not display volumes and snapshots with the 'VeeamAUX' prefix in the storage hierarchy. Such volumes are used for service purposes and are filtered out.
• [For Huawei OceanStor] Huawei UltraPath software for storage connection redundancy and load balancing is not supported. It is recommended to use the Microsoft Multipath I/O (MPIO) feature instead.

Backup from Storage Snapshots

Backup from Storage Snapshots has the following limitations.

• Backup from Storage Snapshots does not support vRDM disks. vRDM disks are skipped from processing.
• Backup from Storage Snapshots cannot be used for VMs whose disks are located on VVol datastores.

• Backup from Storage Snapshots cannot be used to back up VM templates.

• For storage systems working over NFS:

• VMs that you plan to back up or replicate must not have VMware vSphere snapshots. VMs with snapshots are skipped from processing.
• If you enable the Enable VMware tools quiescence option in the job settings, Veeam Backup & Replication will not use Backup from Storage Snapshots to process running Microsoft Windows VMs that have VMware Tools installed.

Snapshot Orchestration and Backup from Storage Snapshots with Snapshot Retention

Snapshot jobs (snapshot-only jobs and backup jobs with storage snapshot retention) have the following limitations.

• If you remove or re-add a storage array that is already associated with a snapshot job, Veeam Backup & Replication will restart the retention cycle. You will need to manually remove old snapshots that are no longer needed.
• You cannot configure a job to create storage snapshots on arrays of different storage vendors.
• [For HPE 3PAR Peer Persistence] You can use backup jobs to create a snapshot chain either on a primary or on a secondary storage array, but you cannot configure snapshot creation on both storage arrays at the same time.
• For IBM Spectrum Virtualize:

• When you add IBM Spectrum Virtualize storage systems with HyperSwap function to the backup infrastructure, Veeam Backup & Replication, by default, works with primary storage volumes. If you want to select secondary storage volumes as a data source for backup, use registry keys. For more information, contact Veeam Support Team.
• You can use backup jobs to create a snapshot chain either on a primary or on a secondary storage array, but you cannot configure snapshot creation on both storage arrays at the same time.

• For snapshot-only jobs:

• If a VM added to the job has several disks that reside on the same volume, you cannot exclude specific VM disks from the backup as Veeam Backup & Replication creates snapshots at the volume level.
• Veeam Backup & Replication does not support guest file indexing for snapshot-only jobs.
• You cannot perform backup of VMs residing on a VMware datastore that comprises several LUNs.

Veeam Explorer for Storage Snapshots

Veeam Explorer for Storage Snapshots has the following limitations.

• During restore of VM guest OS files from storage snapshots, data is transferred over LAN through the Network Block Device protocol (NBD). Therefore, restore performance may not be optimal.

• You cannot perform any kind of restore operation (Instant VM Recovery, VM guest OS files restore and application items restore) when a VMware datastore comprises several LUNs.
• Veeam Explorer for Storage Snapshots does not support VMs whose disks are located on VVol datastores.

• You can restore data of a VM whose disks are hosted on different VMware datastores. This is true for storage snapshots created both as snapshot-only jobs and backup jobs with storage snapshot retention. However, if you restore from native storage snapshots or snapshots that were created with earlier versions of Veeam Backup & Replication (up to version 9.5 Update 4), mind the following:

• The restored VM will have only those VM disks that are hosted on the same datastore as the VMX file.
• You will be able to restore VM guest OS files or application items only from those VM disks that are hosted on the same datastore as the VMX file.
• You will not be able to restore VM disks that contain the absolute path in the VMX file.
• [For HPE Nimble and NetApp] You will not be able to perform Instant VM Recovery and restore VM guest OS files to the original location from snapshots on secondary storage arrays.

To overcome these limitations, you must restore from storage snapshots created with the current version of Veeam Backup & Replication (starting from version 9.5 Update 4).

• If you remove or re-add a storage array to the backup infrastructure, you will be able to restore data only from those VM disks that are hosted on the same datastore as the VMX file.
• You cannot restore data of a VM whose disks are hosted on storage systems of different storage vendors.

• Multi-OS file-level restore for encrypted VMs is not supported.

• You cannot restore files directly to the original location from backups of BSD, Mac and Solaris VMs. You cannot restore files directly to the original location from NSS filesystems. Use the Copy to option instead.

• If the original VM is removed from vSphere infrastructure or migrated to another datastore, you will not be able to perform VM guest OS files restore to the original location.
• Starting from VMware vSphere version 6.7, migrating VMs that are powered off with unclean CTK files is not supported. Thus, before attempting a storage vMotion operation, you need to power on at least once the instant recoveries created from storage snapshots where the source VM has CBT enabled. If the VM cannot be powered on, the Veeam quick migration process is still able to run successfully.