Versions Compared

Old Version 13

changes.mady.by.user Tomas Gonzalo

Saved on

compared with

New Version 14

changes.mady.by.user Tomas Gonzalo

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents

Foreword

OpenStack recognises two types of resources on their clouds:

  1. Instances, which correspond to the servers or VMs. These can be image-backed, if the VM was booted from an image, or volume-backed, if it was booted from a volume. Instances are managed via the OS Glance service.
  2. Volumes, which correspond to storage disks which can be attached to VMs. Root disk are a special case as VMs are booted from them. Volumes are managed by the OS Cinder service.

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

...

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

Restoration of VMs

Instance Snapshots
Anchor

...

RestoreInstanceSnapshots
RestoreInstanceSnapshots

Image-backed instances

Info

All instances on EUMETSAT accounts are volume-backed. If you have an EUMETSAT tenancy see the information on volume-backed instances below.

In-place restoration of VM snapshots that are image-backed 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 achieved 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.

Info
An important consequence of restoring a VM in this manner,  either in-place or not, is that the image snapshot becomes the underlying image of the VM, instead of the original, e.g. Ubuntu or Rocky OS, and therefore the image can no longer be removed from the list of images available in the cloud.

Volume-backed instances

In-place restoration of VM snapshots that are volume-backed cannot be done easily, as the root volumes cannot be detached from the VM while it exists. So full in-place restoration is not possible. The closest alternative is to delete the VM, restore the root disk, and then recreate the VM with the newly restored volume. In order to do that first delete the VM (make sure to store the configuration details first) with

Code Block
openstack server delete <server>

then replace the root disk with one of its snapshots with 

Code Block
openstack volume revert <snapshot>

 and then build a new VM with the volume as it's root, with  

Code Block
openstack server create --volume <volume> --flavor <flavor> <instance_name> --network <network> [--security-group <security_group>]

where <volume>  is the name or id of the volume just created, <instance_name> the name for the new VM, and <flavor>, <network> and <security_group> are the configuration details of the VM. These configuration details, 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 - EUMETSAT - How to create backups from VMs. 

Restoring a volume-backed VM to a new completetly new simply requires creating a new volume out of one of the snapshots, with 

Code Block
openstack volume create --snapshot <snapshot> <volume_name>

and then create a new instance with the volume as its root, as above.

Instance Backups
Anchor
RestoreInstanceBackups
RestoreInstanceBackups

Image-backed instances

Restoring an image-backed instance from a backup follows the same steps as restoring it from a snapshot, since both are stored as images. 

Volume-backed instances

As above, full in-place restoration of volume-backed VMs is not possible, but the closest approach is to delete the VM and then restore the backup of the root volume. This can be done, either to replace an existing volume (with --force ) or onto a new one, with

Code Block
openstack volume backup restore [--force] <backup> <volume>

and afterwards, rebuild the instance as specified above.

Restoration of Volumes

Volume Snapshots
Anchor
RestoreVolumeSnapshots
RestoreVolumeSnapshots

...

Instance Snapshots

Image-backed instances

Volume-backed instances

Instance Backups

Image-backed instances

Volume-backed instances

Restoration of Volumes

...

In-place restoration of volume snapshots can be performed with OpenStack by replacing the root disk of an existing VM with an snapshot.

...

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. 

Code Block
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. 

...

Volume Backups
Anchor
RestoreVolumeBackups
RestoreVolumeBackups

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

...

The simplest way to restore a single VM is to restore the root volume of the VM it 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 instance itself (the root volume if volume-backed) 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 onescopies, specially the root volume of the VM if volume-backed, a new instance must be launched from the new root volume or image,  and then the rest of the volumes must be attached to it.

...