Pre-requisite: EWC - OpenStack Command-Line client


Foreword

Before backing up 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.

Before starting make sure you are in the machine where you configured openstack client and you can run openstack commands as described in EWC - OpenStack Command-Line client

When creating backups or snapshots of VMs and volumes, it is highly recommended that the following command are run outside from said VMs and volumes. Doing so from within may cause corrupted backups or snapshots.

Backup VMs and volumes

Instance Snapshots

To take a snapshot of a instance for later recovery or replication, one must create an image based on the current VM.  The list of VMs/servers than can be used for the snapshot can be found with:

openstack server list

And, to create the image snapshot of a running VM with name or id <server> use the command

openstack server image create --name <image_name> <server>

where:

In order to see the list of images, including the recently created snapshot, one can run

openstack image list

and the specific details of the created image can be found

openstack image show <image_name>

It is recommended, though not mandatory, to shut off the server before making a snapshot of it, to make sure all the data has been flushed to disk. This can be done with the command

openstack server stop <server>

and after the snapshot it can be restarted with

openstack server start <server>

Volume Snapshots

To create a snapshot of a volume

openstack volume snapshot create [--force] --volume <volume> <snapshot_name>

with:

To see the list of all snapshots in your cloud, or the snapshots from a specific volume, run

openstack volume snapshot list [--volume <volume>]

and to get the details of a specific snapshot

openstack volume snapshot show <snapshot_name>

It is recommended to detach the volume from the server before making a snapshot, to avoid potential crashes. This can be done with the command

openstack server remove volume <server> <volume>

and it can be reattached after the snapshot with

openstack server add volume <server> <volume>

Note that in order to make a snapshot without detaching the volume the --force  flag must be provided. The snapshot or backup of an attached volume is crash consistent.

Volume Backups

To create a backup of a volume run:

openstack volume backup create [--incremental] [--force] [--name <backup_name>] <volume>

Where:

To list all available backups in your cloud, you can use the following command:

openstack volume backup list

Additionally, you can filter the results with additional options to list backups for a specific volume:

 openstack volume backup list --volume <volume>

It is recommended to detach the volume from the server before backing it up, to avoid potential crashes. This can be done as explained above.  One can force the backup of attached volumes with the --force  option. The snapshot or backup of an attached volume is crash consistent.

Common use cases

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

Single VM

To backup a single VM, it is recommended to create an image snapshot of the instance, as shown above. It is also possible to back up the root disk of the VM as a volume, using either a snapshot or full backup, but not recommended.

Single VM and attached volume(s)

To backup a single VM and it's attached volumes, one must create a snapshot or backup of the instance and the volumes separately. To backup the instance, the recommendation is to create an image, as shown above. For each of the volumes attached, one can create a snapshot or a backup for each of them by following the instructions for volume snapshots or volume backups above.

Single VM and multiple networks and/or security groups

The network configuration and security groups of VMs are not recorded when performing an instance snapshot. If this information needs to be backed up in order to reconfigure the VM after restoration, we recommend storing these values in a file inside the VM. These can be done, e.g. in YAML format, with

openstack server show -f yaml -c addresses -c security_groups <instance> > <file>

From these stored details, the network and security group configuration can be restored. Visit EWC - How to restore backups from VMs to find out more about how to restore instances.

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. CONFIRM THIS. The recommended way to backup a VM with a SFS is to unmount the SFS before performing the instance snapshot, in order to avoid possible corruption, and remounting it afterwards. This can be easily done, with admin privileges, with

sudo umount <sfs_mount_point>
...
<backup instance, volumes, etc>
...
sudo mount <sfs_url> <sfs_mount_point>


Multiple VMs, volumes, etc

In order to backup multiple VMs, with any configuration, one can repeat the steps laid out above multiple times in succession. Attention must be when backuping up volumes that are attached to multiple instances or any other possible overlapping situation. For the sake of safety, it is recommended to detach all the volumes and stop all the instances that are to be backed up.

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 backed up, and run the script a single time.


Scheduling backups

WIP


Backup automation

WIP