serverplus'da zaxira nusxalash strategiyasi

E’lon qilingan: 25.07.26

Ulashish

Uchta vosita

serverplus OpenStack asosida qurilgan va bu uchta mustaqil zaxira darajasini beradi: server snapshotlari (Glance obrazlari), tom snapshotlari va bekaplari (Cinder) hamda fayllar, ma'lumotlar bazasi damplari va arxivlar uchun S3 obyekt xotirasi.

Server snapshoti (snapshot → obraz). Tizim diskining to'liq nusxasi. Undan serverning aniq nusxasini tez yoyish mumkin. Yangilanish yoki xavfli o'zgarishdan oldin qulay.
Tom snapshoti va bekapi (Cinder). Tom snapshoti — xuddi shu xotira ichidagi disk-tomning nuqtaviy nusxasi; tom bekapi — tomni obyekt xotirasiga, hisoblash resurslaridan alohida chiqarish.
S3 obyekt xotirasi. Fayl bekaplari, MB damplari va uzoq muddatli arxivlar uchun. Serverlardan alohida yashaydi va ular o'chirilsa ham saqlanadi.

Snapshot hali bekap emas. Server va tom snapshoti asl nusxa bilan bir xil bulut va bir xil loyihada yotadi. Loyiha o'chirilsa yoki buzilsa, ular ham yo'qoladi. Haqiqiy bekap — bu boshqa joydagi nusxa: tomni obyekt xotirasiga bekap qilish va/yoki S3'ga chiqarish.

Server snapshoti

Ishlab turgan serverdan obraz yaratish (nomni sana bilan qo'ygan ma'qul):

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

# list ready images
openstack image list

Bunday obrazdan yangi server yoyish:

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

Muvofiqlik haqida. «Uchayotganda» olingan snapshot diskni bor holicha qayd etadi. Ma'lumotlar bazasi uchun bu nomuvofiq holatni olish xavfi. Snapshotdan oldin xizmatni to'xtatgan yoki buferlarni diskka yozgan (MBBT uchun — mantiqiy damp qilgan), ideal holda esa o'chirilgan serverdan olgan ma'qul.

Tom snapshotlari va bekaplari

Tom snapshoti — tez nuqtaviy nusxa:

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

Tom bekapi — obyekt xotirasiga chiqarish (inkremental bo'lishi mumkin):

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

Tiklash:

# 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

Fayllar va MB damplari S3'da

Fayllar va ma'lumotlar bazasi uchun obyekt xotirasi qulayroq. Panelda («Kirishni boshqarish» bo'limi) S3/EC2 kalitlarini yarating va aws-cli yoki rclone orqali ishlang.

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/

Bakning versiyalashini va hayotiy tsikl (lifecycle) qoidalarini yoqing — eski nusxalar avtomatik o'chirilsin, tasodifan qayta yozilganlari esa tiklanadigan bo'lsin.

3-2-1 strategiyasi

serverplus'ga yaxshi mos keladigan klassik qoida:

Ma'lumotning 3 nusxasi (asl + ikkita bekap).
2 xil saqlash turi (masalan, tom snapshoti + obyekt xotirasidagi bekap).
1 nusxa alohida — hisoblash resurslaridan tashqarida, server o'chirilishidan omon qoladigan S3'da.

Bekaplarni avtomatlashtirish: qayerda ishga tushirish

Bulutning o'zi cron'ingizni ishga tushirmaydi — API'ni jadval bo'yicha chaqirish uchun doim ochiq nimadir kerak. Ikkita amaliy yo'l bor.

A variant. Kichik management-VM + cron

Alohida kichik VM (minimal flavor) openstack CLI va aws-cli bilan. Unga faqat application credentials kerak — tomlarni montaj qilish shart emas, u faqat API va S3'ni boshqaradi.

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

/opt/backup.sh namunasi: inkremental tom bekapi, MB dampi S3'ga va damplar rotatsiyasi.

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

Inkremental tom bekaplari rotatsiyasi — ehtiyotkorlik bilan. Inkrementlar birinchi to'liq bekapga tayanadi; bazaviyni o'chirsangiz — butun zanjir buziladi. Vaqti-vaqti bilan yangi to'liq bekap qiling (--incrementalsiz) va eski zanjirlarni bittalab emas, butunlay o'chiring.

B variant. CI/CD rejalashtiruvchisi (o'z VM'siz)

Agar CI allaqachon bo'lsa, alohida mashina kerak emas — skriptni runner jadval bo'yicha ishga tushiradi, kirish ma'lumotlari esa maskalangan sirlarda yotadi. GitLab uchun namuna (.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"

Jadval CI/CD → Schedules'da beriladi (cron 0 3 * * *). Sirlar — OS_APPLICATION_CREDENTIAL_ID/SECRET, DB_URL, S3-kalitlar — maskalangan o'zgaruvchilar sifatida.

GitHub Actions'da ham xuddi shunday — on: schedule orqali:

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

Balki hech narsani ishga tushirish shart emasdir. serverplus paneliga qarang: agar u yerda snapshot/tom bekaplari uchun o'rnatilgan jadval bo'lsa, avtomatlashtirishni to'g'ridan-to'g'ri interfeysda yoqish mumkin — management-VM'siz va CI'siz.

Tiklashni tekshiring

Hech qachon yoyilmagan bekap — bu bekap emas, umid. Muntazam sinov tiklashini o'tkazing: obrazdan server yoki bekapdan tomni alohida resursda ko'taring va ma'lumotlar butun, ilova ishga tushishiga ishonch hosil qiling.

Xavfsizlik

Alohida kalitlar. Avtomatlashtirish uchun — minimal huquqli application credentials va S3-kalitlar; ularni alohida bekor qilish mumkin.
Shifrlash. Maxfiy damplarni yuklashdan oldin shifrlang; shifrlash kalitini bekaplardan alohida saqlang.
Kirishni ajratish. Bekaplar bakiga kirish — faqat kerak bo'lganlarda; tasodifiy va qasddan o'chirishdan himoyalanish uchun versiyalashni yoqing.

Ko'p beriladigan savollar

Server snapshoti loyiha bilan birga yo'qoldi. Snapshotlar xuddi shu bulutda yashaydi. Loyiha yo'qolishidan himoya uchun tomni obyekt xotirasiga bekap qilish yoki S3'ga chiqarish kerak — bu «tashqariga» nusxa.

Tiklashdan keyin MB buzilgan. «Uchayotganda» olingan snapshot nomuvofiq holatni ushlagan. Mantiqiy damp (pg_dump, mysqldump) ishlating yoki to'xtatilgan MBBT'dan oling.

Nusxalarni qancha saqlash kerak? Ma'lumotga bog'liq. Keng tarqalgan sxema: kunlik 7–14 kun, haftalik 1–2 oy, oylik bir yil — avtomatik rotatsiya bilan.

Tavsiya etamiz