Copii de rezervă și recuperare în caz de dezastru

Copii de rezervă și recuperare în caz de dezastru

1) Definiții și obiective

Copie de rezervă - o copie consistentă a datelor/configurațiilor pentru recuperarea ulterioară (de la ștergeri accidentale, bug-uri, cryptolocers, dezastre).
DR (Dezastru Recovery) - procesul de restaurare a infrastructurii/serviciilor pentru SLO-urile care lucrează după un accident major (incendiu, pierderea regiunii, compromis masiv).
RPO (Recovery Point Obiectiv) - pierdere maximă admisibilă de date în timp (de exemplu, 15 minute).
RTO (Recovery Time Obiectiv) - serviciu timp de recuperare țintă (de exemplu, 30 minute).

Principiul cheie: replicarea ≠ backup. Replicarea frotiuri rapid erori și criptare în toate copiile. O copie de rezervă este o copie izolată, verificată, potențial neschimbabilă.

2) Clasificarea datelor și nivelurile critice

• Tier-0 (vital): baze de date tranzactionale, plati, contabilitate bilantiera, secrete/PKI.
• Nivelul 1 (critic): configurații de service, cozi, artefacte CI/CD, registre containere.
• Tier-2 (important): analiză, rapoarte, indici secundari, arhive jurnal.
• Tier-3 (auxiliar): cache, date de timp (pot fi restaurate prin reconstrucție).

Pentru fiecare clasă, definiți RPO/RTO, perioada de păstrare, cerințele de imutabilitate și locația.

3) Strategii de retenție: Regula 3-2-1-1-0

3 copii de date (prod + 2 copii de rezervă).
2 tipuri diferite de medii/stocare.
1 copie offsite (regiune diferită/nor).
1 imuabil/aer-decalaj (WORM/Object Lock/bandă).
0 erori în verificările de recuperare (teste regulate).

4) Tipuri de copii de rezervă

Copyright complet. Lent/scump, dar de bază pentru toate strategiile.
Incremental - diferența cu ultima orice copie de rezervă. Optim în volum.
Diferențial - diferența cu ultimul plin. Recuperare mai rapidă, mai mult spaţiu.
Instantaneu - instantaneu al unui volum/disc (EBS/ZFS/LVM). Avem nevoie de instantanee consistente pentru aplicații (quiesce).
PITR (Point-in-Time Recovery) - backup de bază + jurnale (WAL/binlog) pentru rollback la ora exactă/LSN.
Obiect/fișier/figurativ - pentru anumite tipuri de date (imagini VM, obiecte S3, dumps DB).

5) Consistența backup-urilor

Crash-consistent: ca după o oprire bruscă - potrivit pentru apatrizi/jurnalizate FS.
App-consistent: aplicația „îngheață” operațiunile (fsfreeze/scripturi pre-post) → integritate garantată.
Consistența bazei de date: API a instrumentului de backup (pgBackRest, XtraBackup), moduri de backup la cald, puncte de control de congelare.

6) criptare, chei și acces

În repaus și criptare în tranzit pentru toate copiile.
Chei în KMS/HSM, rotație după politică (90/180 zile), taste separate după mediu.
Separarea sarcinilor: cine creează/elimină copii de rezervă ≠ cine le poate decripta/citi.
Nu păstrați cheile de decriptare în același domeniu de încredere ca și copiile țintă.

7) Copii nemodificabile și protecție ransomware

Object Lock/WORM (Conformitate/Guvernare) cu retenție și Legal Hold.
Aer-decalaj: stocare izolată/offline (alimentare, nor offline/cont).
Politicile de ștergere „activare întârziată”, MFA-Delete, cont separat pentru cupe de rezervă, interzicerea accesului public.
Verificarea pentru malware/indicatori de compromis înainte de montare.

8) Frecvență, program și retenție

GFS (Bunicul-Tatăl-Fiul): creșteri zilnice, săptămânal full/diff, lunar plin cu stocare lungă.
RPO dictează frecvența incrementelor și arhivarea WAL/binlog (de exemplu, la fiecare 5-15 minute).
Depozitare: critică - ≥ 35-90 zile + lunar timp de 12-36 luni (cerințe legale).
Vârfurile sezoniere sunt puncte de control separate (înainte de promoții/lansări).

9) Modele și scenarii DR

Activ-Activ: Ambele regiuni deservesc traficul. RTO minim, colapsul datelor necesită o politică strictă de conflict.
Activ-pasiv (cald/cald): fierbinte - desfășurat și sincronizat (minute RTO), cald - parțial gata (ore RTO).
Rece: stoca copii și Terraform/Ansible/imagini, ridica la cerere (RTO zi +).
DRaaS: orchestrarea furnizorilor de VMs/rețele/adrese într-o altă zonă.

10) Priorități de orchestrare și recuperare Feilover

Prioritate de pornire: rețea/VPN/DNS secrete/KMS baze de date/clustere cozi/cache aplicații perimetrale/CDN analytics.
Automatizare: scripturi/actiuni runbook, profile Terraform/Ansible/Helm/ArgoCD pentru mediul DR.
Date: DB PITR → reindex/replica → cache cald → servicii de lansare cu steaguri de compatibilitate schema.
DNS/GSLB: downgrade TTL în avans, comutați scenariile cu validare.

11) Teste de verificare de backup

Restaurați testele pe un program: eșantionarea N% a backup-urilor, implementarea sandbox, verificări automate schemă/invariante.
Complet DR-burghiu (joc-zi): dezactivarea regiune/AZ, verificarea RTO/RPO pe trafic live (sau umbre de trafic).
Teste de integritate: directoare hash, sume de control, încercarea de a citi toate straturile (full + lanț).
Raport document: timp, pași, anomalii, dimensiunea decalajului de la obiective, corecții.

12) Practică pentru tehnologiile de bază

Baze de date

PostgreSQL: backup de bază + arhivă WAL (PITR), instrumente pgBackRest/Barman; sloturi de replicare, monitorizare 'lsn'.
MySQL/MariaDB: Percona XtraBackup/Enterprise Backup, arhivare binlog.
MongoDB: „mongodump” pentru copie logică + instantaneu pentru seturi mari; Oplog pentru PITR.
Redis: RDB/AOF pentru critică (dacă Redis nu este doar cache), dar mai des - reconstrucție logică de la sursă + instantaneu pentru accidente.
Kafka/Pulsar: metadate de rezervă (ZK/Kraft/BookKeeper), instantanee pe disc, topic/log oglindire.

Kubernetes

etcd instantaneu + Velero pentru resurse/volume (instantanee CSI).
Secrete de rezervă/PKI separat (instantaneu Vault).
Registru separat de imagini: etichete imuabile.

VMs și sisteme de fișiere

ZFS: 'zfs instantaneu' + 'zfs trimite | zstd | trimite-recv' incremente, verificarea 'scrub'.
Instantanee LVM/EBS cu scripturi pre/post (app-consistent).
Magazine de obiecte - Versiuni + Object Lock.

13) Catalogarea și controlul versiunii de backup-uri

Director (catalogare metadate): ce, în cazul în care, atunci când, decât făcut, hash-uri, cheie KMS, proprietar, perioada de păstrare.
Метки/теги: 'env = prod' stage', 'system = db' k8s' vm', 'tier=0|1|2', 'retention=35d|1y'.
Puncte de control de aur: înainte de migrații/DDL/versiuni pe scară largă.

14) Observabilitate și valori

Rata de succes a postului:% succes/eșec, motive.
Timp de backup/restaurare, lățimea ferestrei.
RPO-actual: jurnal de arhivă jurnal (WAL/binlog) p95.
Integritate: proporție de lanțuri testate, erori de reconciliere hash.
Cost: capacitate de stocare pe clase, raport eliminare/comprimare.
Pregătirea DR: frecvența și rezultatul exercițiilor (trecere/eșec).

15) Politici de acces și conformitate

Conturi/proiecte separate pentru stocare de rezervă; accesul în conformitate cu principiul NaC (nu permitem ștergerea/criptarea din conturile de producție).
Jurnalele de acces/modificări (traseu de audit), alerte pentru ștergeri în masă/modificări ale retshn.
Conformitate: GDPR (dreptul de a șterge vs arhive), PCI DSS (criptare, chei, segmentare), autorități locale de reglementare.

16) Anti-modele

„Există o replică, ceea ce înseamnă că nu aveți nevoie de o copie de rezervă”.
Fără decalaj imuabil/aerian: o eroare/malware șterge totul.
Copii de rezervă în același cont/regiune ca prod.
Nu verificați niciodată recuperarea (backup „mort înainte de a verifica”).
Nici o catalogare și controlul versiunii → haos într-un accident.
Chei de criptare partajate pentru toate mediile.
Instantanee fără modul app-consistent pentru baza de date.
Fereastra de rezervă se intersectează cu vârfurile (afectează p99 și SLO).

17) Lista de verificare a implementării (0-60 zile)

0-10 zile

Inventarul sistemelor/datelor, clasele critice.
Setați țintele RPO/RTO pe clase.
Activați full + incremental pentru arhiva Tier-0/1, WAL/binlog.
Postați copii de rezervă: regiune separată/cont + activați criptarea KMS.

11-30 zile

Configurați imuabil (Object Lock/WORM) pentru copii critice.
Introduceți catalogarea, etichetele, raportarea; alerte la eșecuri și reviste lag.
Primul DR-burghiu: restaurarea unui serviciu separat de o copie de rezervă într-un mediu izolat.

31-60 zile

Runbook automatizat: Profile Terraform/Ansible/Helm DR. ing.
Teste regulate de restaurare (săptămână/lună) + scenariu DR trimestrial complet.
Optimizaţi ciclurile de viaţă cost-eliminare/comprimare/stocare.

18) Valorile maturității

Restaurare teste: ≥ 1/săptămână pentru Tier-0 (selectiv), ≥ 1/lună - scenariu complet.
Acoperire imuabilă для Tier-0/1 = 100%.
RPO-real p95 ≤ obiectiv (de exemplu ≤ 15 min).
RTO-real pe DR-exerciții ≤ țintă (de exemplu ≤ 30 min).
Completitudinea directorului = 100% (fiecare copie de rezervă este descrisă și verificată).
Incident-la-restaurare - Timp de la detectare la începutul recuperării.

19) Exemple (fragmente)

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) Comunicații și roluri operaționale

Comandantul incidentului, Comms Lead, Ops Lead, DB Lead, Securitate.
Șabloane de mesaje pentru părțile interesate/autoritățile de reglementare/utilizatori.
Post-mortem cu acțiuni: în cazul în care au pierdut minute, în cazul în care pentru a îmbunătăți automatizarea.

21) Concluzie

O buclă de încredere de backup-uri și DR nu este un „face o copie”, ci un ciclu: clasificarea → obiective RPO/RTO → copii multi-nivel și imuabile → runbooks' automate și → restaurări regulate și exerciții. Aderă la 3-2-1-1-0, replicare separată de backup-uri, criptați și izolați cheile, documentați și verificați. Apoi, chiar și „lebăda neagră” se va transforma într-un proces ușor de gestionat, cu timpi previzibili de nefuncționare și pierderi minime de date.