Backup və disaster recovery

Backup və Disaster Recovery

1) Təriflər və məqsədlər

Backup - sonradan bərpa üçün məlumatların/konfiqurasiyaların razılaşdırılmış surəti (təsadüfi silinmələrdən, fayllardan, kriptolokerlərdən, fəlakətlərdən).
DR (Disaster Recovery) - böyük qəzadan (yanğın, bölgə itkisi, kütləvi kompromasiya) sonra SLO işçilərinə infrastruktur/xidmətlərin bərpası prosesi.
RPO (Recovery Point Objective) - maksimum icazə verilən vaxt itkisi (məsələn, 15 dəqiqə).
RTO (Recovery Time Objective) - xidməti bərpa etmək üçün məqsədli vaxt (məsələn, 30 dəqiqə).

Əsas prinsip: replikasiya ≠ backup. Replikasiya səhvləri və bütün nüsxələr üçün şifrələməni tez bir zamanda «ləkələyir». Backup - təcrid olunmuş, yoxlanılmış, potensial dəyişməz surətdir.

2) Məlumatların təsnifatı və kritik səviyyələr

• Tier-0 (həyati): əməliyyat DB, ödənişlər, balans uçotu, sirləri/PKI.
• Tier-1 (kritik): xidmətlərin konfiqləri, növbələr, CI/CD artefaktları, konteyner reyestrləri.
• Tier-2 (vacib): analitika, hesabatlar, ikinci dərəcəli indekslər, log arxivləri.
• Tier-3 (köməkçi): caches, müvəqqəti məlumatlar (yenidənqurma ilə bərpa edilə bilər).

Hər sinif üçün RPO/RTO, saxlama müddəti, dəyişməzlik tələbləri və yerləri təyin edin.

3) Saxlama strategiyaları: qayda 3-2-1-1-0

3 məlumat surəti (prod + 2 ehtiyat).
2 müxtəlif tipli daşıyıcılar/anbarlar.
1 nüsxə offsite (digər region/bulud).
1 immutable/air-gap (WORM/Object Lock/Tape).
0 bərpa yoxlamalarında səhvlər (müntəzəm testlər).

4) Backup növləri

Full - tam surəti. Yavaş/bahalı, lakin bütün strategiyalar üçün əsas.
Incremental - hər hansı bir son arxa ilə fərq. Həcminə görə optimal.
Differential - son full ilə fərq. Daha sürətli bərpa, daha çox yer.
Snapshot - cildin/diskin (EBS/ZFS/LVM) ani qəlibidir. App-consistent snapshot (quiesce) lazımdır.
PITR (Point-in-Time Recovery) - dəqiq vaxt/LSN geri qaytarılması üçün əsas arxa + jurnallar (WAL/binlog).
Obyekt/fayl/şəkillər - xüsusi məlumat növləri (VM-şəkillər, S3-obyektlər, DB-damplər) altında.

5) Backup uyğunluğu

Crash-consistent: qəfil söndürüldükdən sonra olduğu kimi - stateless/jurnallaşdırılan FS üçün uyğundur.
App-consistent: app «dondurur» əməliyyatları (fsfreeze/pre-post scripts) → zəmanətli bütövlük.
BD tutarlılığı: API yedək alətləri (pgBackRest, XtraBackup), hot-backup rejimləri, nəzarət nöqtələrinin dondurulması.

6) Şifrələmə, açarlar və giriş

Bütün nüsxələr üçün at-rest və in-transit şifrələmə.
KMS/HSM-də açarlar, siyasət rotasiyası (90/180 gün), ayrı-ayrılıqda açarlar.
Vəzifələrin ayrılması: Kim yaradır/çıxarır ≠ kim onları deşifrə edə/oxuya bilər.
Şifrələmə açarlarını hədəf nüsxələrlə eyni etimad domenində saxlamayın.

7) Dəyişməz nüsxələr və ransomware qorunması

Object Lock/WORM (Compliance/Governance) retenşn və Legal Hold ilə.
Air-gap: təcrid olunmuş/oflayn saxlama (bant, oflayn bulud/hesab).
«Təxirə salınmış aktivləşdirmə», MFA-Delete, backup-baketlər üçün ayrıca hesab, ictimai girişin qadağan edilməsi.
Quraşdırmadan əvvəl malware/güzəşt göstəricilərini yoxlayın.

8) Tezlik, cədvəl və retenshn

GFS (Grandfather-Father-Son): gündəlik incrementals, həftəlik full/diff, aylıq full uzun saxlama ilə.
RPO artımların tezliyini və WAL/binlog arxivini (məsələn, hər 5-15 dəqiqədə) diktə edir.
Saxlama: kritik - 35-90 gün ≥ + 12-36 ay üçün aylıq (hüquqi tələblər).
Mövsümi zirvələr - ayrı-ayrı nəzarət nöqtələri (aksiyalardan/buraxılışlardan əvvəl).

9) DR modelləri və ssenariləri

Active-Active: Hər iki bölgə trafikə xidmət edir. Minimum RTO, məlumatların dağılması ciddi münaqişə siyasəti tələb edir.
Active-Passive (isti/isti): isti - yerləşdirilmiş və sinxronlaşdırılmış (RTO dəqiqə), isti - qismən hazır (RTO saat).
Cold: nüsxələri və Terraform/Ansible/şəkilləri saxlayın, sorğu ilə qaldırın (RTO + gün).
DRaaS: digər zonada VM/şəbəkə/ünvanların provayder orkestrasiyası.

10) Feylover orkestri və bərpa prioritetləri

Başlanğıc prioriteti: şəbəkə/VPN/DNS → sirləri/KMS → baza/klasterlər → növbələr/önbellek → proqramlar → perimetri/CDN → analitika.
Avtomatlaşdırma: scriptlər/Runbook-fəaliyyət, Terraform/Ansible/Helm/DR-mühit üçün ArgoCD profilləri.
Məlumat: DB PITR → reindex/replica → warm-cache → sxemlərin uyğunluq bayraqları ilə xidmətlərin başlaması.
DNS/GSLB: əvvəlcədən TTL aşağı, validasiya ilə keçid ssenariləri.

11) Bərpa testləri (backup verification)

Cədvəl üzrə bərpa testləri: N% backup seçimi, qum qutusunda yerləşdirmə, sxemlərin/invariantların avtomatik yoxlanılması.
Tam DR-drill (game-day): regionun/AZ-ın bağlanması, canlı trafikdə (və ya kölgə trafikində) RTO/RPO-nun yoxlanılması.
Bütövlük testləri: hash kataloqları, nəzarət məbləğləri, bütün layları oxumağa cəhd (full + chain).
Dock hesabatı: vaxt, addımlar, anomaliyalar, hədəflərdən boşluğun ölçüsü, düzəlişlər.

12) Əsas texnologiyalar üçün təcrübə

Verilənlər bazası

PostgreSQL: base backup + WAL arxivi (PITR), pgBackRest/Barman alətləri; slots replikasiya, nəzarət 'lsn'.
MySQL/MariaDB: Percona XtraBackup/Enterprise Backup, binlog arxivləşdirilməsi.
MongoDB: 'mongodump' məntiqi nüsxə üçün + böyük dəstlər üçün snapshot; PITR üçün Oplog.
Redis: Kritik üçün RDB/AOF (Redis yalnız önbellək deyilsə), lakin daha tez-tez - mənbədən məntiqi yenidənqurma + qəzalar üçün snapshot.
Kafka/Pulsar: meta məlumatların arxası (ZK/Kraft/BookKeeper), disklərin snapshotları, top/log güzgüsü.

Kubernetes

etcd snapshot + Velero üçün resurslar/cildlər (CSI snapshots).
Secrets Backup/PKI ayrıca (Vault snapshot).
Ayrı görüntü reyestri: artefaktların saxlanması polisi (immutable tags).

VM və fayl sistemləri

ZFS: 'zfs snapshot' + 'zfs send | zstd | send-recv' increments, yoxlama 'scrub'.
LVM/EBS snapshots ilə pre/post scripts (app-consistent).
Obyekt anbarları: + Object Lock versiyaları.

13) Kataloqlaşdırma və backup versiyalarına nəzarət

Kataloq (meta məlumat kataloqu): nə, harada, nə zaman, nə, hash, KMS açarı, sahibi, saxlama müddəti.
Метки/теги: `env=prod|stage`, `system=db|k8s|vm`, `tier=0|1|2`, `retention=35d|1y`.
«Qızıl» nəzarət nöqtələri (Gold) :/DDL/miqyaslı buraxılışlardan əvvəl.

14) Müşahidə və metrika

Tapşırıqların müvəffəqiyyəti:% uğurlu/uğursuz, səbəbləri.
backup/bərpa vaxtı, pəncərə eni.
RPO-faktiki: jurnal arxivləri lag (WAL/binlog) p95.
Bütövlük: sübut edilmiş zəncirlərin payı, hash yoxlama səhvləri.
Qiymət: siniflər üzrə saxlama həcmi, deduplikasiya/sıxılma əmsalı.
DR hazırlığı: təlimlərin tezliyi və nəticəsi (pass/fail).

15) Giriş siyasəti və uyğunluq

Backup saxlama üçün ayrı hesablar/layihələr; NaC prinsipi ilə giriş (prod-hesablardan silinməyə/şifrələməyə imkan vermirik).
Giriş/dəyişiklik qeydləri (audit trail), kütləvi silinmə/dəyişiklik riskləri geri çevrilir.
Standartlara uyğunluq: GDPR (silinmə hüququ vs arxivlər), PCI DSS (şifrələmə, açarlar, seqmentasiya), lokal tənzimləyicilər.

16) Anti-nümunələr

«Replika var - o zaman backup lazım deyil».
No immutable/air-gap: bir səhv/zərərli hər şeyi silir.
Prod ilə eyni hesab/bölgədə backaps.
Heç bir bərpa yoxlamaq (backup «yoxlanılmadan ölü»).
No kataloqlaşdırma və nəzarət versiyası → qəza zamanı xaos.
Bütün mühit üçün ümumi şifrələmə açarları.
DB üçün app-consistent rejimi olmadan snapshots.
Arxa pəncərə zirvələrlə kəsişir (p99 və SLO-ya təsir edir).

17) Giriş çek siyahısı (0-60 gün)

0-10 gün

Sistemlərin/məlumatların inventarlaşdırılması, kritik siniflər.
RPO/RTO hədəflərini siniflərə təyin edin.
Tier-0/1 üçün full + incremental aktiv, WAL/binlog arxivi.
Arxa planları dağıtın: ayrı bir region/hesab + KMS şifrələməsini aktivləşdirin.

11-30 gün

Kritik nüsxələr üçün immutable (Object Lock/WORM) konfiqurasiya.
Kataloqlaşdırma, tags, hesabat daxil edin; uğursuzluqlar və lag jurnalları üçün alertlər.
İlk DR-drill: təcrid olunmuş mühitdə backup ayrı xidmət bərpa.

31-60 gün

Runbook avtomatlaşdırma: Terraform/Ansible/Helm DR profilləri.
Müntəzəm bərpa testləri (həftə/ay) + rüblük tam DR ssenari.
Qiymətləri optimallaşdırın: depolama dövrlərinin deuplikasiyası/sıxılması/ömrü.

18) Yetkinlik metrikası

Bərpa testləri: ≥ üçün Tier-0 1/həftə (seçici), ≥ 1/ay - tam ssenari.
Immutable coverage для Tier-0/1 = 100%.
RPO faktiki p95 hədəf ≤ (məsələn, ≤ 15 dəq).
Hədəf ≤ DR təlimlərində RTO-faktiki (məsələn, ≤ 30 dəq).
Kataloq-komplitlik = 100% (hər bir arxa plan təsvir və yoxlanılmışdır).
Incident-to-restore: bərpa başlamaq üçün aşkar vaxt.

19) Nümunələr (snippetlər)

bash base backup once a day pgbackrest --stanza = prod --type = full backup archive WAL every 5 minutes pgbackrest --stanza = prod archive-push restore to time pgbackrest --stanza = prod restore --type = time --target =" 2025-11-03 14:00:00 + 02"

bash xtrabackup --backup --target-dir=/backup/full-2025-11-01 xtrabackup --backup --incremental-basedir=/backup/full-2025-11-01 --target-dir=/backup/inc-2025-11-02 xtrabackup --prepare --apply-log-only --target-dir=/backup/full-2025-11-01 xtrabackup --prepare --target-dir=/backup/full-2025-11-01 --incremental-dir=/backup/inc-2025-11-02

yaml apiVersion: velero. io/v1 kind: Backup metadata: { name: prod-daily }
spec:
includedNamespaces: ["prod-"]
ttl: 720h storageLocation: s3-immutable

json
{
"Rules": [{
"ID": "prod-immutable",
"Status": "Enabled",
"NoncurrentVersionExpiration": { "NoncurrentDays": 365 }
}]
}

20) Rabitə və əməliyyat rolları

Incident Commander, Comms Lead, Ops Lead, DB Lead, Security.
Stakholders/tənzimləyicilər/istifadəçilər üçün mesaj şablonları.
Post-mortem hərəkətləri ilə: harada dəqiqələri itirmək, harada avtomatlaşdırma yaxşılaşdırılması.

21) Nəticə

Arxa və DR etibarlı konturu «nüsxə etmək» deyil, bir dövrdür: təsnifat → RPO/RTO hədəfləri → çox səviyyəli və immutable nüsxələr → avtomatlaşdırılmış runbook və → müntəzəm bərpa və təlimlər. 3-2-1-1-0 yapışın, replikasiyanı arxalardan ayırın, açarları şifrələyin və təcrid edin, sənədləşdirin və yoxlayın. Sonra hətta «qara qu quşu» proqnozlaşdırıla bilən fasilə müddəti və minimum məlumat itkisi ilə idarə olunan prosesə çevriləcəkdir.