5. Creating and Managing vApps : 5.4 vApp Deployment Readiness : 5.4.2 vApp Limitations within vCloud : 5.4.2.2. Backup Limitations
   
5.4.2.2. Backup Limitations
Using vCloud APIs for virtual machine backups poses some major limitations for backup of vApps, and the intricate nature of vApp constructs stored in the vCloud Director database requires additional overhead for backups and restores in case of a failure. vApp networks, whether fenced or NAT-routed, are backed by VMware vCloud Networking and Security Manager, making the situation even more complex.
A simpler approach might be to orchestrate vApp backups by using the full clone mechanism at scheduled intervals. An orchestration engine, such as VMware vCenter Orchestratorâ„¢, makes this a reasonable alternative until this capability becomes available through the native APIs or from third-party products or plug-ins.
To help customers and third-party backup vendors implement backup solutions, vCloud Director 5.1 supports snapshots of vApps and virtual machines. Snapshots provide the ability to roll back to an earlier point in time. However, snapshots are intended for use as a temporary resiliency method, not as a permanent backup, disaster recovery, or business continuity process.
One use case for enterprises and service providers is to allow users to take snapshots before they modify their virtual machines and vApps. This feature can be exposed to end users through the vCloud Director portal and through APIs in a custom portal. This can be a value-added feature for the providers, and it additionally benefits customers by reducing the administrator overhead.
Similarly, a third-party vendor can take a snapshot immediately before taking a backup of the vApp and then delete the snapshot after the backup is complete. Customers can schedule backup windows as done in a vSphere environment.
In vCloud Director, virtual machines and vApps can have only one snapshot. Any subsequent creation of snapshots overwrites the previous one. Snapshots are supported on virtual machines and vApps, both in a powered-on or powered-off state. Reverting the snapshot restores the previous state of the virtual machines in which the snapshot was taken. However, it does not restore the network mapping and OVF properties associated with the virtual machines and vApps. While a snapshot is active, the network configuration cannot be modified. An Undeploy operation on vApps preserves the snapshot, but cloning and capturing to the catalog operation does not. Snapshots at the vCenter layer are automatically consolidated.
The following considerations must be addressed by snapshot consumers:
*Storage consumed by snapshots.
*Storage consumed by snapshots in fast-provisioned environments.
*Snapshot management.
*Backup and recovery of vApps and virtual machines with snapshots.
*For a service provider, the costs of snapshots are readily made available to the end customer.
*For an enterprise IT provider, snapshot usage affects future storage needs.