Стратегия резервного копирования в serverplus

Три инструмента

serverplus построен на OpenStack, и это даёт три независимых уровня резервного копирования: снимки серверов (образы Glance), снимки и бэкапы томов (Cinder) и объектное S3-хранилище для файлов, дампов баз данных и архивов.

• Снимок сервера (snapshot → образ). Полный слепок системного диска. Из него быстро развернуть точную копию сервера. Удобно перед обновлением или рискованным изменением.
• Снимок и бэкап тома (Cinder). Снимок тома — точечная копия диска-тома внутри того же хранилища; бэкап тома — выгрузка тома в объектное хранилище, отдельно от вычислительных ресурсов.
• Объектное S3-хранилище. Для файловых бэкапов, дампов БД и долговременных архивов. Живёт отдельно от серверов и переживает их удаление.

Снимок — это ещё не бэкап. Снимок сервера и снимок тома лежат в том же облаке и том же проекте, что и оригинал. Если проект будет удалён или повреждён, исчезнут и они. Настоящий бэкап — это копия в другом месте: бэкап тома в объектное хранилище и/или выгрузка в S3.

Снимок сервера

Создать образ из работающего сервера (имя лучше делать с датой):

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

# list ready images
openstack image list

Развернуть новый сервер из такого образа:

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

Про консистентность. Снимок «на лету» фиксирует диск как есть. Для баз данных это риск получить несогласованное состояние. Перед снимком лучше остановить сервис или сбросить буферы на диск (для СУБД — сделать логический дамп), а идеально — снимать с выключенного сервера.

Снимки и бэкапы томов

Снимок тома — быстрый точечный слепок:

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

Бэкап тома — выгрузка в объектное хранилище (можно инкрементально):

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

Восстановление:

# 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

Файлы и дампы БД в S3

Для файлов и баз данных удобнее объектное хранилище. Создайте S3/EC2-ключи в панели (раздел «Управление доступом») и работайте через aws-cli или 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/

Включите версионирование бакета и правила жизненного цикла (lifecycle), чтобы старые копии удалялись автоматически, а случайно перезаписанные — восстанавливались.

Стратегия 3-2-1

Классическое правило, которое хорошо ложится на serverplus:

• 3 копии данных (оригинал + два бэкапа).
• 2 разных типа хранения (например, снимок тома + бэкап в объектном хранилище).
• 1 копия отдельно от вычислительных ресурсов — в S3, переживающем удаление сервера.

Автоматизация бэкапов: где запускать

Само облако ваш cron не запускает — чтобы дёргать API по расписанию, нужно что-то постоянно доступное. Есть два практичных пути.

Вариант A. Небольшая management-VM + cron

Отдельная маленькая VM (минимальный flavor) с openstack CLI и aws-cli. Ей нужны только application credentials — тома монтировать не требуется, она лишь оркеструет API и S3.

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

Пример /opt/backup.sh: инкрементальный бэкап тома, дамп БД в S3 и ротация дампов.

#!/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"

Ротация инкрементальных бэкапов тома — аккуратно. Инкременты опираются на первый полный бэкап; удалите базовый — развалится вся цепочка. Периодически делайте новый полный бэкап (без --incremental) и удаляйте старые цепочки целиком.

Вариант B. Планировщик CI/CD (без своей VM)

Если CI уже есть, отдельную машину держать не нужно — скрипт запускает раннер по расписанию, а доступы лежат в маскированных секретах. Пример для 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"

Расписание задаётся в CI/CD → Schedules (cron 0 3 * * *). Секреты — OS_APPLICATION_CREDENTIAL_ID/SECRET, DB_URL, S3-ключи — как masked-переменные.

Аналогично в GitHub Actions — через 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

А может, запускать ничего и не нужно. Загляните в панель serverplus: если там есть встроенное расписание снимков/бэкапов томов, автоматизацию можно включить прямо в интерфейсе — без management-VM и без CI.

Проверяйте восстановление

Бэкап, который ни разу не разворачивали, — это не бэкап, а надежда. Регулярно проводите тестовое восстановление: поднимите сервер из образа или том из бэкапа на отдельном ресурсе и убедитесь, что данные целы и приложение стартует.

Безопасность

• Отдельные ключи. Для автоматизации — application credentials и S3-ключи с минимальными правами; их можно отозвать по отдельности.
• Шифрование. Чувствительные дампы шифруйте перед загрузкой; храните ключ шифрования отдельно от бэкапов.
• Изоляция доступа. Доступ к бакету с бэкапами — только у тех, кому он нужен; включите версионирование, чтобы защититься от случайного и злонамеренного удаления.

Частые вопросы

Снимок сервера пропал вместе с проектом. Снимки живут в том же облаке. Для защиты от потери проекта нужен бэкап тома в объектное хранилище или выгрузка в S3 — это копия «наружу».

База данных после восстановления повреждена. Снимок «на лету» поймал несогласованное состояние. Используйте логический дамп (pg_dump, mysqldump) или снимайте с остановленной СУБД.

Сколько хранить копии? Зависит от данных. Частая схема: ежедневные за 7–14 дней, еженедельные за 1–2 месяца, ежемесячные за год — с автоматической ротацией.