Backup strategy on serverplus

Three tools

serverplus is built on OpenStack, which gives you three independent backup layers: server snapshots (Glance images), volume snapshots and backups (Cinder) and S3 object storage for files, database dumps and archives.

• Server snapshot (snapshot → image). A full copy of the system disk. From it you quickly deploy an exact copy of the server. Handy before an upgrade or a risky change.
• Volume snapshot and backup (Cinder). A volume snapshot is a point-in-time copy of the volume inside the same storage; a volume backup exports the volume to object storage, separate from compute resources.
• S3 object storage. For file backups, DB dumps and long-term archives. It lives apart from the servers and survives their deletion.

A snapshot is not yet a backup. A server snapshot and a volume snapshot live in the same cloud and the same project as the original. If the project is deleted or damaged, they vanish too. A real backup is a copy elsewhere: a volume backup to object storage and/or an upload to S3.

Server snapshot

Create an image from a running server (add a date to the name):

openstack server image create --name web-2026-07-25 my-server

# list ready images
openstack image list

Deploy a new server from such an image:

openstack server create --image web-2026-07-25 --flavor m1.small --network private --key-name my-key web-restored

About consistency. A live snapshot captures the disk as-is. For databases that risks an inconsistent state. Before a snapshot it is better to stop the service or flush buffers to disk (for a DBMS — take a logical dump), and ideally snapshot a powered-off server.

Volume snapshots and backups

A volume snapshot is a quick point-in-time copy:

openstack volume snapshot create --volume data-vol data-vol-2026-07-25
openstack volume snapshot list

A volume backup exports to object storage (can be incremental):

openstack volume backup create --name data-vol-backup data-vol
openstack volume backup create --name data-vol-inc --incremental data-vol
openstack volume backup list

Restore:

# new volume from a snapshot
openstack volume create --snapshot data-vol-2026-07-25 --size 50 data-vol-new

# restore from a backup
openstack volume backup restore data-vol-backup data-vol-new

Files and DB dumps in S3

For files and databases object storage is more convenient. Create S3/EC2 keys in the panel (the "Access management" section) and use aws-cli or rclone.

aws configure   # access key + secret from the panel

# dump a database and upload to the bucket
pg_dump mydb | gzip > mydb-2026-07-25.sql.gz
aws --endpoint-url <S3 endpoint> s3 cp mydb-2026-07-25.sql.gz s3://backups/db/

# sync a directory
aws --endpoint-url <S3 endpoint> s3 sync /var/www s3://backups/www/

Enable bucket versioning and lifecycle rules so old copies are removed automatically and accidentally overwritten ones can be recovered.

The 3-2-1 strategy

A classic rule that fits serverplus well:

• 3 copies of the data (the original + two backups).
• 2 different storage types (for example a volume snapshot + a backup in object storage).
• 1 copy off-site from the compute resources — in S3, which survives server deletion.

Automating backups: where to run them

The cloud does not run your cron for you — to call the API on a schedule you need something always available. There are two practical paths.

Option A. A small management VM + cron

A separate small VM (minimal flavor) with the openstack CLI and aws-cli. It only needs application credentials — no need to mount volumes, it just orchestrates the API and S3.

# /etc/cron.d/serverplus-backup — daily at 03:00
0 3 * * * root /opt/backup.sh >> /var/log/backup.log 2>&1

Example /opt/backup.sh: an incremental volume backup, a DB dump to S3 and dump rotation.

#!/usr/bin/env bash
set -euo pipefail

export OS_CLOUD=serverplus              # access from clouds.yaml
DATE=$(date +%F)                         # 2026-07-25
S3="aws --endpoint-url https://<S3 endpoint>"
BUCKET=s3://backups
KEEP_DAYS=14

# 1) incremental volume backup to object storage
openstack volume backup create --name "data-vol-$DATE" --incremental data-vol

# 2) database dump and upload to S3
pg_dump mydb | gzip > "/tmp/mydb-$DATE.sql.gz"
$S3 s3 cp "/tmp/mydb-$DATE.sql.gz" "$BUCKET/db/"
rm -f "/tmp/mydb-$DATE.sql.gz"

# 3) rotate S3 dumps: delete older than KEEP_DAYS
CUTOFF=$(date -d "-$KEEP_DAYS days" +%F)
$S3 s3 ls "$BUCKET/db/" | while read -r d tm size name; do
  fdate=$(echo "$name" | grep -oE "[0-9]{4}-[0-9]{2}-[0-9]{2}" || true)
  if [ -n "$fdate" ] && [ "$fdate" \< "$CUTOFF" ]; then
    $S3 s3 rm "$BUCKET/db/$name"
  fi
done

echo "backup done: $DATE"

Rotate incremental volume backups carefully. Increments rely on the first full backup; delete the base and the whole chain falls apart. Periodically take a new full backup (without --incremental) and delete old chains as a whole, not file by file.

Option B. A CI/CD scheduler (no VM of your own)

If you already have CI, you don't need a separate machine — the runner executes the script on a schedule and the credentials live in masked secrets. Example for GitLab (.gitlab-ci.yml):

backup:
  image: registry.example/openstack-aws-cli:latest
  variables:
    OS_AUTH_TYPE: v3applicationcredential
    OS_AUTH_URL: https://identity.serverplus.uz/v3
    OS_REGION_NAME: RegionOne
    OS_IDENTITY_API_VERSION: "3"
    # OS_APPLICATION_CREDENTIAL_ID / _SECRET — masked CI variables
  script:
    - openstack volume backup create --name "data-vol-$(date +%F)" --incremental data-vol
    - pg_dump "$DB_URL" | gzip > db.sql.gz
    - aws --endpoint-url "$S3_ENDPOINT" s3 cp db.sql.gz "s3://backups/db/db-$(date +%F).sql.gz"
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

The schedule is set in CI/CD → Schedules (cron 0 3 * * *). Secrets — OS_APPLICATION_CREDENTIAL_ID/SECRET, DB_URL, S3 keys — as masked variables.

Similarly in GitHub Actions — via on: schedule:

name: backup
on:
  schedule:
    - cron: "0 3 * * *"
jobs:
  backup:
    runs-on: ubuntu-latest
    env:
      OS_AUTH_TYPE: v3applicationcredential
      OS_AUTH_URL: https://identity.serverplus.uz/v3
      OS_REGION_NAME: RegionOne
      OS_IDENTITY_API_VERSION: "3"
      OS_APPLICATION_CREDENTIAL_ID: ${{ secrets.OS_AC_ID }}
      OS_APPLICATION_CREDENTIAL_SECRET: ${{ secrets.OS_AC_SECRET }}
    steps:
      - run: pipx install python-openstackclient
      - run: openstack volume backup create --name "data-vol-$(date +%F)" --incremental data-vol

Maybe you don't need to run anything at all. Check the serverplus panel: if it has a built-in schedule for volume snapshots/backups, you can enable automation right in the UI — without a management VM and without CI.

Test your restores

A backup you have never restored is not a backup, it's hope. Run restore drills regularly: bring up a server from an image or a volume from a backup on a separate resource and make sure the data is intact and the app starts.

Security

• Separate keys. For automation — application credentials and S3 keys with minimal permissions; they can be revoked individually.
• Encryption. Encrypt sensitive dumps before uploading; keep the encryption key separate from the backups.
• Access isolation. Only those who need it get access to the backup bucket; enable versioning to protect against accidental and malicious deletion.

FAQ

A server snapshot disappeared together with the project. Snapshots live in the same cloud. To protect against losing the project you need a volume backup to object storage or an upload to S3 — a copy that goes "outside".

The database is corrupted after a restore. A live snapshot caught an inconsistent state. Use a logical dump (pg_dump, mysqldump) or snapshot a stopped DBMS.

How long to keep copies? It depends on the data. A common scheme: daily for 7–14 days, weekly for 1–2 months, monthly for a year — with automatic rotation.