...
Instead of performing an in-place restoration, it is possible to create a new VM using the image snapshot. This is done in the same manner as for creating a new instance, see EWC OpenStack API access - How to create a VM using the Openstack OpenStack CLI, using the command
| Code Block |
|---|
openstack server create --flavor <flavor_name> --image <image_snapshot> --key-name <keyname> --network <network_name> --security-group <security_group_name> <vm_name> |
...
In the case of an in-place restoration, it is necessary to detach the volume first and reattach it after the restoration. Detaching and reattaching the volume to an instance can be done in the same way as for Volume Snapshots.
Common use cases
WIP
Backup automation
...
These is a list of common configurations of VMs and volumes in the cloud and the recommened procedure to restoring them
Single VM
To restore a single VM, one can simply restore the image of the VM, either in-place or as a new VM, following the instructions here.
Single VM and attached volume(s)
To restore a single VM and it's attached volumes, one restore the instance and the volumes separately. To restore the instance from an image follow the instructions above. If restoring the image in place, it is recommended to detach all volumes from it beforehand. Each of the volumes attached can be restored differently, depending on whether they were backed up as a volume snapshot or volume backup. As before, if restoring the volume in-place, remember to detach it from the instance before, and reattach it later.
Single VM and multiple networks and/or security groups
The network configuration and security groups of VMs are not recorded when backing up the instance. If one is interested in restoring this information, and stored these values somehwere, e.g. by following the instructions in EWC - How to create backups from VMs, these can be restored simply by adding them to the VM as
| Code Block |
|---|
openstack server add network <instance> <network>
openstack server add security group <instance> <security_group> |
for each <network> and <security_group> that one wants to restore to the <instance> .
Single VM and SFS
Shared File Services (SFS) cannot be backed up as they are distributed storage solutions that do not live in the same cloud. Thefore one can restore the VM as normal, and then mount the SFS into the new VM. Remember that if restoring the VM in-place, the SFS device must be unmounted before restoring it.
Multiple VMs, volumes, etc
In order to restore multiple VMs at once, with any configuration, one can repeat the steps laid out above multiple times in succession. In case of in-place restorations, make sure to detach all the volumes and stop all the instances that are to be restored.
An alternative to repeating all the steps here multiple times is to use the automation script below, where one can set up a configuration file detailing all the instances, volumes, etc, to be restored, and run the script a single time.
Restore automationAnchor RestoreAutomation RestoreAutomation
| RestoreAutomation | |
| RestoreAutomation |
The multi-step procedure for restoring instances and volumes can been performed in a single step using the script found in the repository
| Warning |
|---|
| TODO: Link to repository |
A simple configuration YAML file detailing the instances and volumes to restore, as well as whether to restore in-place or as a new resource, can be used to run the script. Instructions on how to run the script can be found in the README file in the repository itself.