Foreword

OpenStack recognises two types of resources on their clouds:

...

Backing up VMs

Instance Snapshots

Anchor
InstanceSnapshots InstanceSnapshots

There are two methods of taking snapshots of instances, depending on whether they are image-backed or volume-backed. 

Image-backed instances

...

openstack server start <server>

Volume-backed instances

To take a snapshot of a volume-backed instance for later recovery or replication, one must take a snapshot of the root and other attached volumes as well as store the image configuration.  The list of VMs/servers than can be used for the snapshot can be found with:

...

Then, to create a snapshot follow the instructions on how to take a snapshot of a volume below.

One can also store the VM configuration for later recovery, simply by exporting the details of the instance to a file, for example with

openstack server show <sever> > instance-config.txt

Instance Backups

Anchor
InstanceBackups InstanceBackups

Image-backed instances

...

and it is recommended to stop the server before the backup.

Volume-backed instances

Performing a full backup of a volume-backed VM requires backing up the root volume. As before, identify the root volume of the VM, and then perform a full backup, as explained in the instructions below.

Backing up Volumes

Volume Snapshots

Anchor
VolumeSnapshots VolumeSnapshots

To create a snapshot of a volume, root or otherwise, do

...

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

Anchor
VolumeBackups VolumeBackups

The procedure to create a backup of a volume is almost identical to that of a snapshot. First identify the volumes in the cloud as before, then back up each of the volumes with

...

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 in the cloud and the recommened procedure to backing them up

Single VM

To backup a single VM, whether image-backed or volume-backed, it is recommended to create a snapshot of the instance as shown above. A full backup is also recommended for volume-backed instances when the original volume is not guaranteed to be preserved.

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 VM first, including the root disk if the instance is volume-backed, and then perform a snapshot or backup of all other attached volumes separately. 

Single VM and multiple networks and/or security groups

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

...

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

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. The recommended way to backup a VM with a SFS is to unmount the SFS before performing the snapshot or backup of the VM, 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 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 backing up VMs with multiple volumes so as not to lose information. 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 VMs, volumes, etc, to be backed up, and run the script a single time.

Scheduling backups

It is often quite useful to schedule a backup for a specific time in the future, as well as to repeat that scheduled backup regularly, to ensure the preservation of any changes. In order to prepare a scheduled backup, with or without repetition, one can set up a cron  job that will run in the background and perform the necessary operations. A full tutorial on how to use cron is beyond the scope of this page, more details can be found elsewhere, e.g. https://crontab.guru/. Here only a few examples will be shown.

...

Note: some of the syntax above is specific to bash . Add SHELL=/usr/bin/env bash to your crontab  to ensure cron runs using bash , or change the above script for its equivalent in sh .

Backup automation

Anchor
BackupAutomation BackupAutomation

The multi-step procedure for creating backups, including the scheduling and repetition of backups, can been performed in a single step using the script found in the repository

...