Creating Instance from Backup
Backups play a critical role in cloud environments by preserving the state of Instances, including their Volumes, configurations, and application data. They allow Administrators and Users to restore services quickly in the event of accidental deletion, corruption, or infrastructure failure.
In older CloudStack versions, Backups had some key limitations:
• Instances with Backups could not be expunged or assigned to a new Backup Offering.
• Creating a new Instance directly from a Backup was not possible – Backups could only be restored onto the same Instance.
• A backup in one Zone could not be used in another Zone.
These limitations reduced flexibility and often complicated the lifecycle management of Instances with Backups.
The Create new Instance from Backup feature, introduced in Apache CloudStack 4.21 and supported by NAS and Veeam Backup provider plugins, addresses these gaps by allowing Instance creation from Backups and enabling Instances to be safely expunged while retaining Backup usability.
Key Use-Cases
Backup Offering Removal
Allow Backup Offering to be removed from an Instance having Backups, thus allowing the Instance to be assigned a different offering or to be expunged without affecting the Backups’ usability.
Instance Creation from Backups
• Instance metadata is stored within the Backup, and the settings are preserved during Instance creation.
• Cross-Zone Instance creation from Backup (NAS backup provider only).
Removing Backup Offering from Instances
Overview of the Changes
• A Backup Offering can be removed at any time from an Instance.
• Existing Backups remain associated with the previous Backup Offering.
• The Instance can be assigned to a new Backup Offering, and new Backups will be created under the newly assigned offering.
• The Instance can be restored to any of the existing Backups if it contains the same number of Volumes as the Backup.
• The Instance can be safely expunged after the Backup Offering is removed.
Backup Usage Tracking
Previously, Backup Usage was tracked per Instance. With the new behaviour:
• An Instance can contain Backups from multiple Backup Offerings, which may belong to different tiers and billing models.
• Backup Usage can now be tracked per Instance-Backup Offering pair.
• Usage tracking continues even after the Offering is removed from an Instance, until the last Backup belonging to that offering is deleted.
• Usage Tracking also persists after the Instance is expunged, as long as the database entry of the Instance is not purged.
Creating New Instance from a Backup
This feature allows Users to provision a new Instance directly from an existing Instance Backup.
Process flow:
1. User selects a backup.
2. Clicks on the Create new Instance from Backup.
3. Chooses between:
• Using all saved configuration details from Backup metadata.
• Override specific details manually through the Configure Instance option.
4. CloudStack deploys a new Instance, allocates Volumes, restores Backup data, and boots up the Instance.
Instance Metadata
Instance Metadata at the time of Backup creation is stored in the backup_details table and used during the Instance creation.
The metadata includes:
• Template / ISO
• Hypervisor
• Compute Offering
• Volumes Information
• Network Information
• Instance Settings
The metadata is displayed in the Instance Metadata tab within the Backup Details view. Volume details are available in the Details tab.
Configure Instance
The Configure Instance button opens a form similar to the Deploy Instance form, pre-filled with the Instance metadata stored in the Backup.
Users can modify values with certain restrictions:
• The number of Data Volumes must remain unchanged.
• Volume sizes must be greater than or equal to those in the Backup.
If the original Instance was expunged, the new Instance can be created using the same IP and MAC addresses (if they are unused). This can be done by selecting Use IP Addresses from Backup or Fetch From Backup in the Network Selection menu. These options are displayed only if the original Instance is expunged.
Creating New Instance from Backup in Another Zone
Starting with CloudStack 4.22, Backups created in one Zone can be used to create Instances in another Zone within the same CloudStack environment. This is currently supported only with the NAS backup provider.
To enable this:
• Cross-Zone Instance Creation must be enabled on the Backup Repository when adding it or later.
• The Backup Repository must be accessible to the target Zone.
Cross-Zone Backup Replication and Recovery
In a multi-zone CloudStack environment, Administrators can design a resilient Backup architecture by creating a replicated Backup Repository backend across Zones. This enables Instances to be restored or recreated in an alternate Zone during disasters.
A single Backup Repository entry in CloudStack is defined within one Zone, where backup files are initially created and stored. However, the underlying storage backend for that Zone can be a part of a replicated storage setup spanning multiple Zones. Each Zone has its own physical NFS Storage, but all Storages are synchronized and share the same logical repository hostname.
In this design, the hostname must be identical across all Zones, while the underlying IP address can differ per Zone, typically resolved through internal DNS specific to each Zone. The NFS export path must also be the same in all Zones. This ensures that Compute Hosts in every Zone access the repository in a consistent way, enabling seamless Cross-Zone Instance creation and disaster recovery.
This design allows backups to be taken from the source Zone where the Backup Repository is defined, while Disaster Recovery or Cross-Zone Instance creation can transparently use the replicated storage available in other Zones.
Flow Description:
1. The Backup Repository is added to CloudStack using a common DNS hostname (e.g., backup-repo.example.net) and a shared NFS export path to Zone A.
2. Each Zone resolves the same hostname to its local NFS Storage, which exposes the same export path.
3. Backup data written in Zone A is replicated asynchronously to the corresponding NFS Storage in other Zones using the chosen Storage replication mechanism.
4. In the event of a failure in Zone A, CloudStack can access the same logical repository from any other Zone to create new Instances from the replicated Backups on that Zone.
5. Cross-zone Instance creation works seamlessly because all repositories contain identical backup data and share the same hostname and path, and common configuration identity.
Disaster Recovery Guidance
In a multi-Zone deployment, keeping Backup Repository directories synchronised across Zones is essential to ensure reliable Cross-Zone Instance creation and to minimise service disruption in the event of a failure. Because Zones are typically located in different physical sites, the chosen replication mechanism should tolerate higher network latency and avoid synchronous block-level technologies that depend on low-latency links.
Common open-source solutions for directory-level replication include rsync or TrueNAS with ZFS replication for scheduled or incremental synchronisation, and distributed file systems such as GlusterFS or CephFS, which can support asynchronous or near real-time replication.
Alternatively, environments using object storage can rely on S3-compatible solutions, which offer native replication or bucket mirroring between sites. This approach can simplify disaster recovery workflows and decouple the replication layer from NFS-based infrastructure.
The interconnection between Zones must meet baseline requirements for bandwidth, latency, and packet loss to ensure reliable and timely replication. These network characteristics directly impact both RTO (Recovery Time Objective), the time required to restore services after a failure, and RPO (Recovery Point Objective), the maximum acceptable amount of data loss measured in time. A well-designed inter-zone network and a consistent replication strategy help minimise both RTO and RPO, strengthening the overall resilience of the environment.
Conclusion
The new Create Instance from Backup feature, CloudStack enables Instance creation from Backups without dependency on the original Instance. The feature allows safe expunging of VMs while preserving Backups, and introduces more flexible and accurate usage tracking.
In a multiple-zone setup, by replicating Backup Repositories across Zones while maintaining a consistent hostname and export path, CloudStack Administrators can build a unified and resilient disaster recovery architecture.
As a result, Instances can be recreated in any other Zone enabling fast recovery from failures and improving overall business continuity. When combined with a well-defined replication strategy and appropriate inter-zone connectivity, this approach can significantly reduce RTO (Recovery Time Objective) and RPO (Recovery Point Objective), aligning disaster recovery capabilities with operational requirements.
Abhisar is a Software Developer at ShapeBlue and has over 12 experience in the industry. In his personal time, Abhisar likes spending time with his wife and 2-year-old daughter. He also likes listening to and playing music. You can learn more about Abhisar by reading his Meet the Team blog.
