...

Before restoring resources in OpenStack, it's important to understand the difference between three two primary methods:

...

:

...

...

1. Snapshots

...

1. : These are delta copies of the

...

1. root volumes attached to the VM. Snapshots are not full copies and rely on the original volume for restoration, so they are mostly useful for accident recovery. They're managed through the Cinder service.

...

1. Backups

...

1. : These are point-in-time copies of

...

1. the volumes attached to VMs.

...

1. Backups preserve the data within a volume and can be used to restore the volume to the exact state it was in when backed up. They're ideal for data recovery and are also managed through the Cinder service.

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:

1.  In place restoration: the snapshot or backup replaces an existing instance or volumeresource. This is typically useful when data in the original resource has been corrupted and it is necessary to perform a reset to a past state, as stored in the snapshot or backup.
2. New copy restoration: a new resource of the type, instance or volume, is created with the snapshot or backup as its base. This method is useful to copy or migrate resources as well as to recover from catastrophic failures.

...

...

Restoration of VM

...

snapshots 

Anchor

...

RestoreSnapshots

...

RestoreSnapshots

In-place restoration of VM snapshots can be performed with OpenStack by replacing the underlying root disk of an existing VM with an image. In this way it is not necessary to create a new VM instance, but rather replace an existing one. This can be achieve by running:

openstack server rebuild <instance> --image <image_snapshot>

where

• <instance> : The name or id of the existing VM
• <image_snapshot> : Name or id of the snapshot image of the VM previously created

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 CLI,  using the command

openstack server create --flavor <flavor_name> --image <image_snapshot> --key-name <keyname> --network <network_name> --security-group <security_group_name> <vm_name>

where here the <image_name> is the name or id of the image snapshot. It is worth noting that the image snapshot does not contain information about the flavor, networks or security groups, and therefore these need to be manually provided. Restoring a snapshot onto a flavor of smaller size than the original will result in a failure.

...

The restoration of a volume snapshot can also be done in-place, or by creating a new volume. To restore an existing volume from a snapshot, one needs to use the command

openstack volume revert <snapshot>

...

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> <name><volume_name>

with <snapshot> the name or id of the snapshot to restore, and <name> <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. 

Restoration of

...

VM Backups

Anchor

...

RestoreBackups

...

RestoreBackups

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

...

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.

As above, if the restoration takes place to a new volume, a new instance must be launched with that volume as its root.

Common use cases

These is a list of common configurations of VMs and volumes in the cloud and the recommened procedure to restoring them

Single VM

To The simplest way to restore a single VM , one can simply is to restore the image root volume of the VM , either in-place or as a new VM, following the instructions herefrom 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.

Single VM and attached volume(s)

To restore a single VM and it's attached volumes, one must restore the instance root volume and the all other volumes separately. To restore the instance from an image follow the instructions above, either from snapshots or backups. If restoring the image volumes in place, it is recommended necessary 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 laterthe 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.

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 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

...

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 normalabove, 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.

...

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, VMs and volumes to be restored, and run the script a single time.

...

The multi-step procedure for restoring instances and volumes 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 instances 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.

...