VPS-iniz üçün ehtiyat nüsxə strategiyası

Yaxşı VPS ehtiyat nüsxə strategiyası üç qatdan ibarətdir: tam bərpa üçün avtomatik server ehtiyat nüsxələri, verilənlər bazaları üçün tətbiq səviyyəsində dump-lar və ikinci məkanda şifrələnmiş xarici nüsxə. Hər riskli dəyişiklikdən əvvəl snapshot əlavə edin və bərpanı müntəzəm yoxlayın, çünki yoxlanmamış ehtiyat nüsxə sadəcə ümiddir.

Bu bələdçi hər qatı Ubuntu 24.04 və Debian 12 üçün əmrlərlə izah edir.

3-2-1 qaydasından başlayın

Klassik qayda hələ də qüvvədədir:

• məlumatlarınızın 3 nüsxəsi (canlı nüsxə üstəgəl iki ehtiyat nüsxə),
• 2 müxtəlif növ yaddaşda və ya sistemdə,
• onlardan 1-i kənarda, başqa məkanda və ya provayderdə.

VPS üçün bu adətən belədir: serverin özü, provayderin ehtiyat nüsxələri və başqa yerdə şifrələnmiş nüsxə.

Nədən qorunduğunuzu bilin

Fərqli risklər fərqli qatlar tələb edir. Məhz buna görə vacib məlumatlar üçün tək bir üsul heç vaxt kifayət etmir.

1-ci qat: provayderin ehtiyat nüsxələri və snapshot-lar

Avtomatik ehtiyat nüsxələr

Wolkra-da hər server üçün gündəlik avtomatik ehtiyat nüsxələri yandıra bilərsiniz. Onlar server qiymətinin 20%-inə başa gəlir və 7 bərpa nöqtəsi saxlayır. Ehtiyat nüsxə bütöv serveri əhatə edir, ona görə də bərpa əməliyyat sistemini, konfiqurasiyanı və məlumatları birlikdə geri qaytarır. Bu, ciddi səhvdən sonra ən sürətli geri dönüş yoludur.

Snapshot-lar

Snapshot-lar istəyə görə çəkilir və hər GB üzrə hesablanır. Onlardan istifadə edin:

• əməliyyat sistemini, verilənlər bazasını və ya tətbiqin böyük versiyasını yeniləməzdən əvvəl;
• firewall və ya şəbəkə ayarları ilə təcrübə etməzdən əvvəl;
• şablon kimi: snapshot-dan yeni serverlər yarada bilərsiniz.

Addımlar üçün ehtiyat nüsxələr və snapshot-lar səhifəsinə və sənədlərə baxın.

Disk səviyyəli nüsxələri ardıcıl edin

İşləyən serverin ehtiyat nüsxəsi elektrik kabelini çəkib çıxarmağa bənzəyir: fayllar fayl sistemi səviyyəsində ardıcıldır, lakin yazma əməliyyatının ortasında olan verilənlər bazasına bərpa lazım ola bilər. Verilənlər bazaları bunun öhdəsindən gəlmək üçün qurulub, amma təmiz dump (2-ci qat) şübhəni aradan qaldırır.

2-ci qat: tətbiq səviyyəsində dump-lar

PostgreSQL

sudo mkdir -p /var/backups/db && sudo chown postgres: /var/backups/db
sudo -u postgres sh -c 'pg_dump -Fc mydb > /var/backups/db/mydb-$(date +%F-%H%M).dump'

-Fc sıxılmış custom formatdır; onu pg_restore ilə bərpa edin.

MariaDB və ya MySQL

sudo sh -c 'mariadb-dump --single-transaction --routines --all-databases | gzip > /var/backups/db/all-$(date +%F-%H%M).sql.gz'

--single-transaction InnoDB cədvəllərini kilidləmədən onların ardıcıl dump-ını verir.

Docker daxilində

docker compose exec -T db pg_dump -U app app | gzip > ~/backups/app-$(date +%F).sql.gz

Cədvəl və təmizləmə

Dump-ı skriptə yerləşdirin və systemd timer və ya cron ilə işə salın, sonra köhnə faylları silin:

find /var/backups/db -type f -mtime +14 -delete

3-cü qat: restic ilə şifrələnmiş xarici nüsxələr

restic ehtiyat nüsxələri şifrələyir, təkrarlanan hissələri aradan qaldırır və müxtəlif hədəflərə göndərir: SFTP ilə başqa serverə və ya istənilən S3-uyğun obyekt yaddaşına.

Quraşdırma

sudo apt install -y restic

Repozitoriya seçin

Nümunələrdə nəzarətinizdə olan backup serverinə SFTP istifadə olunur. S3-uyğun bucket da eyni şəkildə işləyir: s3: repozitoriya URL-ləri və mühit dəyişənlərində giriş məlumatları ilə.

sudo mkdir -p /etc/restic && sudo chmod 700 /etc/restic
openssl rand -base64 32 | sudo tee /etc/restic/password >/dev/null
sudo chmod 600 /etc/restic/password

sudo tee /etc/restic/env >/dev/null <<'EOF'
RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/web-1
RESTIC_PASSWORD_FILE=/etc/restic/password
EOF
sudo chmod 600 /etc/restic/env

root istifadəçisinə backup.example.com serverinə daxil ola bilən SSH açarı lazımdır (bax: SSH açarları). restic parolunu serverdən kənarda da saxlayın. Onsuz ehtiyat nüsxələri heç kim, o cümlədən siz də oxuya bilməyəcək.

İnisializasiya və işə salma

sudo bash -c 'set -a; . /etc/restic/env; restic init'
sudo bash -c 'set -a; . /etc/restic/env; restic backup /etc /var/www /var/backups/db /home --exclude-caches'
sudo bash -c 'set -a; . /etc/restic/env; restic snapshots'

Saxlama müddəti

sudo bash -c 'set -a; . /etc/restic/env; restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune'

Bu, bir həftəlik gündəlik, bir aylıq həftəlik və yarım illik aylıq nüsxələri saxlayır.

systemd timer ilə avtomatlaşdırma

/etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/bin/restic backup /etc /var/www /var/backups/db /home --exclude-caches
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

/etc/systemd/system/restic-backup.timer:

[Unit]
Description=Nightly restic backup

[Timer]
OnCalendar=*-*-* 03:30
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

Verilənlər bazası dump-ını restic-dən əvvəl işə salın, məsələn dump skriptinizi çağıran ExecStartPre= sətri ilə.

Ələ keçirilmiş serverdən qorunma

Hücumçu root hüququ əldə etsə, serverin çata bildiyi ehtiyat nüsxələri silə bilər. Bu riski azaldın:

• alət dəstəklədikdə hədəfdəki backup istifadəçisinə yalnız append-only (yalnız əlavə etmə) hüququ verin (restic-in REST serverində --append-only rejimi var);
• təmizləməni (prune) başqa maşından işə salın;
• ən azı bir nüsxəni serverin giriş məlumatlarının olmadığı yerdə saxlayın.

Nəyin ehtiyat nüsxəsini çıxarmalı

• Konfiqurasiya üçün /etc.
• Tətbiq kodu və yüklənmiş fayllar: /var/www, /srv, /opt və ya tətbiqinizin qovluğu.
• Xam baza faylları deyil, verilənlər bazası dump-ları.
• Vəziyyət saxlayan konteynerlər üçün Docker volume-ları və ya onların dump-ları.
• Şifrələnmiş TLS və tətbiq secret-ləri.
• Serveri necə yenidən quracağınızı izah edən qısa README.

Adətən /var/cache, /tmp, paket keşləri və ya yenidən yüklənə bilən Docker image qatları lazım deyil.

Blok yaddaş volume-ları

Məlumatlarınız blok yaddaş volume-unda saxlanılırsa, volume-u ayırıb yeni serverə qoşmaq olar; bu, server nasazlıqlarında kömək edir. Bununla belə bu, hələ də tək nüsxədir, ona görə də onu digər məlumatlar kimi restic-ə və ya dump-lara daxil edin.

Bərpanı yoxlayın

Cədvəl seçin, məsələn ayda bir dəfə, və bunlardan birini edin:

1. Bütöv server: ehtiyat nüsxədən və ya snapshot-dan yeni server yaradın, test adı ilə işə salın və tətbiqin işlədiyini yoxlayın.
2. Fayllar: müvəqqəti qovluğa bərpa edin və müqayisə edin.

sudo bash -c 'set -a; . /etc/restic/env; restic restore latest --target /tmp/restore-test --include /etc/caddy'
sudo bash -c 'set -a; . /etc/restic/env; restic check'

3. Verilənlər bazası: dump-ı yeni bazaya yükləyin və bir neçə sorğu işlədin.

Saatlıq hesablama ilə bərpa testi üçün bir saatlıq server çox az başa gəlir. Bərpanın nə qədər çəkdiyini qeyd edin: bu, sizin real bərpa müddətinizdir.

Götürüb istifadə edə biləcəyiniz sadə plan

Rəqəmləri nə qədər məlumat itkisinə dözə biləcəyinizə və nə qədər tez bərpa olunmalı olduğunuza görə tənzimləyin. Serverin qalan quraşdırması üçün yeni VPS-də ilk addımlar və Ubuntu serverini necə qorumalı bələdçilərinə baxın.