Pre-requisite: EWC - OpenStack Command-Line client |
Before restoring resources in OpenStack, it's important to understand the difference between two primary methods:
Choose the appropriate method based on your recovery needs: snapshots for accident prevention and recovery or backups for full data security and recovery.
Furthermore, there are two different restoration methods, according to whether the restoration replaces an existing resource or not:
| Before starting make sure you are in the machine where you configured openstack client, have the required openstack credentials and you can run openstack commands as described in EWC - OpenStack Command-Line client |
| The restoration of backups or snapshots of VMs must be run outside from said VMs, specially in the case of in-place restoration, as the existing resource is completely replaced. |
| Legacy: previously it was possible to create image snapshots directly of the VMs. This is no longer possible as VMs are now only volume-backed. |
In-place restoration of VM snapshots can be performed with OpenStack by replacing the root disk of an existing VM with an snapshot.
openstack volume revert <snapshot> |
where: <snapshot> : name or id of the snapshot to restore. Since in-place restoration replaces an existing volume, it is necessary to detach the volume from the instance first and reattach it after the restoration. One can detach a volume from an instance with
openstack server remove volume <server> <volume> |
with <server> and <volume> the name or id of the instance or volume, respectively. And it can be reattached after restoration with
openstack server add volume <server> <volume> |
The instance (server) retains the same configuration as before, as only the underlying disk has been replaced by the snapshot.
To restore a volume snapshot to a new volume, a new volume must be created, with the snapshot as the source. This can be done with the command
openstack volume create --snapshot <snapshot> <volume_name> |
with <snapshot> the name or id of the snapshot to restore, and <volume_name> the name of the new volume.
After restoring the snapshot to a new volume, a new instance must be launched with the volume as the root.
openstack server create --volume <volume> --flavor <flavor> <instance_name> |
where <volume> is the name or id of the volume just created, <instance_name> the name for the new VM, and <flavor> the flavor of the instance. The configuration details of the VM, such as flavor, networks, etc, can be chosen at the time of restoration or recovered from a previous backup if there was stored, as detailed in EWC OpenStack API access - How to create backups from VMs.
The restoration of a volume backup can also be done in-place, or by creating a new volume. Irrespective of the method, one can restore a volume backup with the command
openstack volume backup restore [--force] <backup> <volume> |
where:
--force : optional argument to force a restoration of an existing volume.<snapshot> : name or id of the backup to restore<volume> : name or id of the existing volume to replace, or the name of a new volume to createIn 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.
As above, if the restoration takes place to a new volume, a new instance must be launched with that volume as its root.
These is a list of common configurations of VMs and volumes in the cloud and the recommened procedure to restoring them
The simplest way to restore a single VM is to restore the root volume of the VM in-place from a snapshot or backup. To create a copy of the VM, one can restore the snapshot or backup to a new volume, and then launch an instance from that root volume.
To restore a single VM and it's attached volumes, one must restore the root volume and all other volumes separately, either from snapshots or backups. If restoring the volumes in place, it is necessary to detach all volumes from the VM beforehand, and reattach it later. And if restoring the volumes to new ones, specially the root volume of the VM, a new instance must be launched from the new root volume, and then the rest of the volumes must be attached to it.
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 has 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
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> .
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 above, 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 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 VMs and volumes to be restored, and run the script a single time.
The multi-step procedure for restoring VMs can been performed in a single step using the script found in the repository
under the items/openstack_backups directory. A simple configuration YAML file detailing the VMs 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.