...

Before backing up resources in OpenStack, it's important to understand the difference between three two 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.Volume Snapshots (Cinder): These are delta copies of the block storage volumes. Volume snapshots 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.
2. Volume Backups (Cinder): These are point-in-time copies of block storage the volumes attached to VMs. Volume backups 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.

...

Backup VMs and volumes

...

VM snapshots

Anchor
Snapshots Snapshots

...

To take a snapshot of a instance VM for later recovery or replication, one must create an image based on the current VMtake 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:

openstack server list

And, to create the image snapshot of a running VM with name or id <server> use the commandFirst one needs to find out the volumes attached to the instance, with

openstack server imageshow create --namec <imagevolumes_name>attached <server>

where:

...

with <server>  the name or id of

...

the VM to

...

backup. This will output a list of attached volumes like 

Image Added

Alternatively, one can list all volumes present in the cloud with

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 servervolume stop <server>

and after the snapshot it can be restarted with

openstack server start <server>

...

list

which will also inform about which volumes are mounted on which VMs. For instance

Image Added

Then, to create a snapshot of one of the volumes, do

...

To create a snapshot of a volume

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

...

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.

...

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

VM Backups

Anchor

...

Backups

...

Backups

To The procedure to create a backup of a volume run:VM is almost identical to that of a snapshot. First identify the volumes attached to the VM as before, then back up each of the volumes with

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

Wherewhere:

• --incremental: create an incremental backup (requires a previous full backup)
• --force: create a backup even if the volume is attached
• --name <backup_name>: the name of the new volume backup
• <volume>: the name or id of the volume to be backed up

...

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.

As before, it is also possible to store the instance configuration data for later recovery.

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

...

To backup a single VM, it is recommended to create an image snapshot a snapshot of the root volume of the instanceVM, as shown above. It A full backup is also possible to back up the root disk of the VM as a volume, using either a snapshot or full backup, but not recommendedrecommended 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 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.root volume of the VM as well as 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 instance snapshotsnapshot or backup of the root volume 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 inside the VM. 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 instancesVMs.

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 The recommended way to backup a VM with a SFS is to unmount the SFS before performing the instance 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 instance, volumes, etc>
...
sudo mount <sfs_url> <sfs_mount_point>

...

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 volumes that are attached to multiple instances or any other possible overlapping situationVMs 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 instancesVMs, volumes, etc, to be backed up, and run the script a single time.

...

and add there the command to be executed and the frequency. For example, to create an image snapshot of the root volume of a VM every Saturday at 12pm, the crontab entry will look like

0 12 * * Sat openstack servervolume imagesnapshot create --name <imageforce --volume <volume> <snapshot_name> <server> 

.Note that this job will necessarily fail, since the cron service does not use the environment variables with the OpenStack credentials that are needed to use the OpenStack CLI. Hence, a better solution is to write a shell script that will load the appropriate environment variables and run any operations. Thus, the same example with the correct OS credentials will look like

...

#! /usr/bin/env bash

for var in $(env | sed -n 's/^\(OS.*\)=.*/\1/p'); do unset "$var"; done
export OS_AUTH_URL=https://keystone.cloudferro.com:5000/v3
export OS_INTERFACE=public
export OS_IDENTITY_API_VERSION=3
export OS_USERNAME="<username>"
export OS_REGION_NAME="WAW3-1"
export OS_PROJECT_ID="<project_id>
export OS_PROJECT_NAME="<project_name>"
export OS_PROJECT_DOMAIN_ID="<domain_id>"
export OS_PASSWORD="<password>"
export OS_CLIENT_ID=openstack
export OS_CLIENT_SECRET="<client_secret>"
export OS_PROTOCOL=openid
export OS_IDENTITY_PROVIDER=eumetsat_provider
export OS_AUTH_TYPE=v3oidcpassword
export OS_DISCOVERY_ENDPOINT="https://identity.cloudferro.com/auth/realms/Eumetsat-elasticity/.well-known/openid-configuration"

echo "Stopping server"
openstack server stop  TestVM
echo "Backing up serverVM"
sleep 5
openstack servervolume imagesnapshot create --name TestVM_snapshot --wait TestVM
echo "Restarting server"
openstack server start TestVM

...

force --volume 49f0613f-ef9b-4d91-b963-e958579801ed TestVM_snapshot

To run the backups only once, without repetition, it is possible to set up a conditional statement on the script, such as

...

...
<do some backup>
...

retention_count=5
backups=(`openstack imagevolume snapshot list --propertyvolume image_type=snapshot --property instance_uuid=<instance_<root_volume_id> --sort-column updated_at --sort-ascending -c ID -f value`)
nbackups=${#backups[@]}
echo "Found $nbackups backups of instanceVM"
if [[ $nbackups -gt $retention_count ]]
then
    let "todelete=$nbackups-$retention_count"
    echo "Backup number over the retention count, will delete the oldest $todelete backups"
    for ((i=0;i<todelete;i++)); do
        echo "Deleting imagesnapshot ${backups[$i]}"
        openstack imagevolume snapshot delete ${backups[$i]}
    done;
else
	echo "Backup number equal or under retention count, doing nothing"
fi

...

The multi-step procedure for creating backups of instances and volumes, including the scheduling and repetition of backups, 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 and volumes VMs to back up, as well as the start and frequency of the scheduling, 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.

...