When you backup or restore a vCenter Server environment, take into account these considerations and limitation.

The following considerations apply to file-based backup and restore protocols:

FTP and HTTP are not secure protocols

Backup servers must support minimum of 10 simultaneous connections for each vCenter Server Appliance

You must have write permissions for upload and read permissions for download

Only explicit mode is supported for FTPS

If you use HTTP or HTTPS, you must enable WebDAV on the backup Web server

You can use only FTP, FTPS, HTTP, or HTTPS to transmit data through an HTTP proxy server

You can use IPv4 and IPv6 URLs in file-based backup and restore of a vCenter Server Appliance. Mixed mode of IP versions between the backup server and the vCenter Server Appliance is unsupported.

After a restore, the following configurations revert to the state when the backup was taken.

Virtual machine resource settings

Resource pool hierarchy and setting

Cluster-host membership

DRS configuration and rules

If the configuration changes, the following might change after a restore.

Datastore Cluster configuration

Datastore Cluster membership

Datastore I/O Resource Management (Storage I/O Control) settings

Datastore-Datacenter membership

Host-Datastore membership

If you put a host into standby mode after a backup, the vCenter Server might force the host to exit standby mode when you restore to the backup.

If you use a distributed virtual switch, you are advised to export separately the distributed virtual switch configuration before you restore to a backup. You can import the configuration after the restore. If you omit this consideration, you may lose the changes made to a distributed virtual switch after the backup. For detailed steps, see the VMware knowledge base article at http://kb.vmware.com/kb/2034602.

If you delete libraries or items after a backup, you cannot access or use these libraries or items after the restore. You can only delete such libraries or items. A warning message notifies you that there are missing files or folders in the storage backup.

If you create new items or item files after the backup, the Content Library Service has no record of the new items or files after the restore operation. A warning notifies you that extra folders or files were found on the storage backup.

If you create new libraries after the backup, the Content Library Service has no record of the new libraries after restore. The library content exists on the storage backing, but no warning is displayed. You must manually clean the new libraries.

Restoring vCenter Server from a backup that was taken during in-flight relocation operations in the vCenter Server instance.

After you restore vCenter Server, the vCenter Server view of the virtual machines might be out of sync with the ESXi view of the virtual machines. This is also true if you performed the backup during in-flight operations on vCenter Server. If virtual machines disappear after you restore vCenter Server, you can refer to the following cases.

a

The missing virtual machine is located on the destination ESXi host and is registered with the destination ESXi host, but it is either an orphan or not in the vCenter Server inventory. You must manually add the virtual machine to the vCenter Server inventory.

b

The missing virtual machine is located on the destination ESXi host, but it is not registered with the destination ESXi host and it is not in the vCenter Server inventory. You must manually register the virtual machine to the ESXi host and add the virtual machine back to the vCenter Server inventory.

c

The missing virtual machine is located on the destination ESXi host, but it is not registered with the destination ESXi host. In the vCenter Server instance, the missing virtual machine is marked as orphaned. You must remove the virtual machine from the vCenter Server inventory and add it again.

Restoring vCenter Server from a backup that has an out-of-date linked clone virtual machine layout.

If you create a linked clone virtual machine after the backup and you restore vCenter Server from the old backup, then after the restore, the vCenter Server does not know about the new linked clone virtual machine until vCenter Server discovers the new linked clone virtual machine. If you remove all existing virtual machines before the new linked clone virtual machine is discovered, then the removal of existing virtual machines corrupts the new linked clone due to missing disks. In order to avoid this, you must wait until all linked clone virtual machines are discovered by the vCenter Server before you remove virtual machines.

Restoring vCenter Server from a backup that was taken during virtual machine registration.

If you are registering a virtual machine during the backup and you restore vCenter Server from the old backup, then after the restore, the virtual machine is marked as orphaned in the vCenter Server instance. You must manually add the virtual machine to the vCenter Server inventory.

Restoring vCenter Server from a backup might cause it to rollback to older version for the vSphere HA cluster state (HostList, ClusterConfiguration, VM protection state) while the hosts in the cluster have the latest version for the cluster state. You need to make sure the vSphere HA cluster state stays the same during restore and backup operations. Otherwise, the following problems might occur.

If hosts are added or removed to or from the vSphere HA cluster after backup and before vCenter Server restore, virtual machines could potentially failover to hosts not being managed by the vCenter Server but are still part of the HA cluster.

Protection state for new virtual machines is not updated on the vSphere HA agents on the hosts that are part of the vSphere HA cluster. As a result, virtual machines are not protected or unprotected.

New cluster configuration state is not updated on the vSphere HA agents on the hosts that are part of the vSphere HA cluster.

Restoring vCenter Server requires vCenter HA to be reconfigured.

Restoring vCenter Server from a backup can lead to the following inconsistencies related to storage policies, storage providers, and virtual machines.

Registered storage providers after backup are lost.

Unregistered storage providers after backup re-appear and might show different provider status.

Changes, such as create, delete, or update, performed on storage policies after backup are lost.

Changes, such as create, delete, or update, performed on storage policy components after backup are lost.

Default policy configuration changes for datastores performed after backup are lost.

Changes in the storage policy association of the virtual machine and its disks, and in their policy compliance might occur.

Restoring vCenter Server from a backup might cause inconsistencies in the Virtual SAN. For information on how to check Virtual SAN health, see Administering VMware Virtual SAN.

Restoring vCenter Server from a backup might result in missing security patches. You must apply them again after the restore is complete. For information on patching the vCenter Server Appliance, see vSphere Upgrade.