Some manual backup and restore procedures are required for the vApps that are deployed into the vCloud. Traditional backup tools do not capture the required metadata associated with a vApp, such as owner, network, and organization. This results in recovery and restoration issues. Without this data, recovery must include manual steps and requires configuration attributes to be manually reentered.

Within a vCloud environment, a vApp can be a single virtual machine or group of virtual machines, treated as one object. Backup of vApps on isolated networks must be supported. Identifying inventories of individual organizations becomes challenging based on current methods that enumerate the backup items using vSphere, which uses Universally Unique Identifiers to differentiate objects. vCloud Director uses object identifiers.

For backing up and restoring vApps, VMware recommends the use of VMware vSphere® Storage APIs – Data Protection-based backup technologies. This technology has no agents on guest operating systems, is centralized for improved manageability, and has a reduced dependency on backup windows.

Guest-based backup solutions may not work in a vCloud because not all virtual machines are accessible by network. Also, virtual machines may have identical IP addresses and this can cause problems. Therefore, backups of vCloud vApps require a virtual machine-level approach.

Use the full name and computer name fields to specify realistic names that help describe the virtual machines when deploying virtual machines (as part of a vApp). If this is not done, the generic information in these fields can make it difficult to specify individual virtual machines. vApps and virtual machines that are provisioned by vCloud Director have a large GUID template_name—many virtual machines could appear to be very similar, making it difficult for a user or administrator to identify and ask for a specific virtual machine to be restored.