Foreword

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

1. Intance Snapshots (Glance): These capture the entire virtual machine, including the operating system, applications, and configuration. Instance snapshots are useful for cloning VMs, creating templates, or disaster recovery scenarios. They're managed through the Glance service.
2. Volume Snapshots (Cinder): These are delta copies of the block storage volumes. Volume 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.
3. Volume Backups (Cinder): These are point-in-time copies of block storage volumes. Volume 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 managed through the Cinder service.

Choose the appropriate method based on your recovery needs: instance snapshots for full system recovery or replication, volume snapshots for accident prevention and recovery or volume 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 volume. 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.

Restoring VMs and Volumes

Restoration of VM snapshots

In-place restoration of VM snapshots can be performed with OpenStack by replacing the underlying 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 - 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.

Restoration of Volume Snapshots

Restoration of Volume Backups

To restore a backup to a new volume, first you need to detach the volume from the VM:

ssh into your VM

become root

unmount the volume  

sudo umount --verbose <path-to-volume>

1. Then you can restore the backup to the volume with OpenStack (from the machine where you are running Openstack commands):

• Where:
• BACKUP_ID: The ID of the backup to restore
• VOLUME_ID: The ID of the volume to restore to (must be at least as large as the original volume)
• 3. Now, you need to attach the volume again to the VM as explained in `Configuring the extra volume in the instance`.
• Common use cases
• WIP
• Backup automation
• WIP
•