Recuperare în caz de dezastru и backup la rece

Scurt rezumat

DR este capacitatea de a restabili funcțiile de afaceri după un dezastru major. Copiile de rezervă la rece - „ultima linie de apărare”: copii neschimbabile/izolate potrivite pentru recuperare în cazul dezenergizării complete a site-ului sau compromisului. Strategia este construită în jurul RTO/RPO, prioritizarea sistemului, exerciții DR anuale și disciplină operațională strictă (cataloage, chei, verificări).

Termeni și obiective

RPO (Recovery Point Obiectiv) - pierdere maximă admisibilă de date (de exemplu ≤ 15 min).
RTO (Obiectivul privind timpul de recuperare) - timp maxim de recuperare admisibil (de exemplu, ≤ 2 ore).
Black-start - recuperare metal gol: hardware/cluster/secrete/date/DNS.
Air-gap - izolarea fizică/logică a copiilor (bandă/cont dezactivat/media offline).
Imutabilitate (WORM) - depozitare imuabilă (bandă/obiect cu blocare/reținere).

Niveluri de disponibilitate DR

Site rece - infrastructura lipsește/înghețată; RTO: ore-zile; cel mai ieftin CAPEX/OPEX.
Site cald - șabloane/imagini/servicii parțial finalizate; Zeci de minute-ore.
Hot Site - replici active; RTO: minute; mai scump și mai complicat.
Hibrid: nucleu → cald/cald, orice altceva → rece (cu prioritate la pornire).

În cazul în care copiile de rezervă sunt indispensabile

Compromis masiv de infestare/domeniu cripto.
Corupția datelor care a mers la toate replicile.
Pierderea regiunii/centrului de date, forță majoră (incendiu, inundații).
Îndepărtarea/sabotarea intenționată din conturile privilegiate.

Topologia copiilor de rezervă la rece

1. Clase media/stocare

Benzi (LTO-8/9): cost redus, decalaj aerian implicit, capacitate mare, acces secvențial.
Discuri offline/NAS: „cazuri sigure”, conectați numai la fereastra de backup/restaurare.
Clasele de obiecte arhivate (Glacier-like): preț redus de stocare, timp de extracție mai mare.

2. Plasare

Alt amplasament/regiune; alt furnizor/cont; chei individuale/administratori.

3. Imutabilitate

Casete WORM/Object Lock (Conformitate/Guvernare) cu retenție și prindere legală.

Politica 3-2-1-1-0 (cu accent pe frig)

3 copii ale datelor (prod + backup local + offsite).
2 medii diferite (disc/bandă/obiect).
1 offsite (alt site/cloud).
1 imuabil (WORM/aer-decalaj).
0 erori de verificare (sumă de control/recuperări periodice ale testelor).

Directoare, metadate și controlul integrității

Catalog de backup: ce, unde, când, versiune, chei, verificați sumele, perioada de păstrare.
Catalog active - Serviciul → dependențe → volume/găleți → prioritate.
Sumele de control și fișierele manifeste: scrieți și restabiliți reconcilierea.
Fișiere canare: restaurare regulată pentru detectarea precoce a problemelor media.

Criptare și chei

Criptare în repaus (bandă/obiect) și în zbor (copiere).
KMS/Vault cu dublu-control, seifuri offline pentru chei master, rotație.
Chei separate pentru vânzări/backup-uri/arhive (minimizarea razei de explozie).
Procesul de acces la cheie documentat în timpul DR (cerințe, roluri, jurnal).

Planul DR Prioritizare și Consecvență

1. Identificare și acces: IdP (zona minimă), Vault/KMS, nucleul rețelei.

2. Planuri de date și de control: etcd K8s, configurații, secrete, registre de imagini, implementa artefacte.

3. Baze de date tranzacție/portofel: jurnale + cele mai recente full/incremental.

4. Gateway-uri de plată/integrare: chei, certificate, IP/DNS.

5. Web/api fronturi: lansarea canarului, conținut static din obiect.

6. Analytics/Raportare: La finalizarea de bază.

1. Infrastructură: rețea, DNS/Anycast, kernel IAM, imagini de bază/cluster.

2. Secretele/certificatele: restaurați Vault/KMS de la rece-backup, distribuiți secretele bootstrap.

3. Planul de control: etcd/Control Plane/registre/depozite.

4. Date: implementați baza de date de la rece-backup + PITR din jurnalele (de RPO).

5. Aplicații: lansarea dependențelor de arbori, încălzirea cache-urilor/CDN.

6. Teste și validare: teste de sănătate, consistență, sume de control.

7. Comutare trafic: DNS/rutare/balansoare (etapizat/canar).

8. Controale post: fără scurgeri/datorii, exploatare forestieră și act DR.

Proceduri de refacere la rece (tipic)

Benzi: inventar, descărcare, fluxuri paralele, harta fișierelor → directoare → sarcini de recuperare; contabilizarea timpilor de căutare și derulare.
Clase de arhivă: cerere de extracție (minutes→hours), montare la stocare la cald, restaurare prin manifest.
Discuri offline: conexiune numai pentru citire, verificări ale sumei de control → copiere.
Practică: o cutie de nisip izolată pentru restaurare, apoi transferați în mediul de producție.

Comunicații și org. structura în DR

Роли: Incident Commander, Tech Lead (Infra), DB Lead, App Lead, Comms, Securitate.
Canale: backup (în afara domeniului corporate), voce/chat, SecureDocs.
Șabloane de mesaje: către clienți/parteneri/autorități de reglementare; frecvența de actualizare; o singură „sursă de adevăr”.
Jurnal de evenimente unificat: cronologie, soluții, proprietari.

DNS, Rețele și trafic

Split-brain-protectie: „DR-mode” steaguri în configurația; feature-flags pentru funcționalitate limitată.
Strategia DNS: TTL scăzut în avans, furnizor independent DNS; pas schimbare A/AAAA/CNAME, încălzire CDN.
Rutare: Anycast/Geo, anunț BGP de la site-ul DR; ACL-urile/firewall-urile sunt reasamblate din IaC.

SLO pentru DR

RPO a atins ≥ 99% din timp (log/increment lag în cadrul obiectivului).
RTO black-start (scenariu complet) ≤ țintă (de exemplu, 4 ore) la teste o dată pe trimestru.
Succesul exercițiilor DR - 100% din sarcinile critice sunt finalizate în fereastră.
Imutabilitate - cota de copii de rezervă cu retenție/blocare = 100%.
Controale de integritate - 100% conform programului; eșec media → bilet de migrație.

Teste și exerciții

Tabel-top: scripturi, roluri, liste de verificare, lista de contacte.
Tehnic: recuperarea selectivă a bazelor de date/fișierelor/secretelor în cutia de nisip cu verificarea sumelor de control și a consistenței.
Negru-start-burghiu: o dată/trimestru (sau o dată/șase luni) - lansarea kernel-ului complet în site-ul DR.
Post-mortem: fapte, blocaje, plan de îmbunătățire (SLO/procese/automatizare).

Automatizări și artefacte

IaC: clustere, rețele, stive - în cod; Ramuri/parametri DR.
Runbooks: componente pe componente (Vault/KMS, etcd, DB, gateway-uri, fronturi).
Pachetul DR: copie offline a docurilor cheie (contacte, scheme, parole de fraze sigure), instrucțiuni de acces fizic.
Canare-restaurare: restaurare zilnică mică și reconciliere sumă de control.
Etichete: "DR-critic", "Numai cald'," Numai la rece "pentru servicii/volume.

Lista de verificare a implementării

• Clasele de date și RPO-urile/RTO-urile lor sunt aliniate cu afacerea; sunt definite prioritățile de recuperare.
• Implementat rece-backup-uri: mass-media, imutabilitate (WORM/Object Lock), offsite/aer-decalaj.
• Cataloage: active, backup-uri, chei; Verificați sumele și controlul versiunii.
• proceduri de pornire neagră: rețele/DNS, IdP/Vault/KMS, plan de control, date, applayer.
• Exerciții: tabelul-top trimestrial; canarul restaurează zilnic; black-start o dată/sfert-șase luni.
• Comunicații și modele de reglementare; canale de comunicare separate.
• SLO/metrici/alerte pentru DR; rapoarte către management.
• Acorduri cu furnizorii (benzi/clase de arhivă/DNS/CDN), SLA confirmat.
• Finanțe: buget media/arhivă, logistică, înlocuire media de timp.

Erori comune

„Există o replică - nu este nevoie de backup” → o eroare logică/ransomware-ul va pleca peste tot.
Nu există imutabilitate/decalaj aerian → un singur vector pentru compromiterea tuturor copiilor.
Lipsa cataloagelor/sumelor de verificare → restabilit „ceva”, dar nu asta.
DNS TTL este prea mare → migrarea traficului de mai multe zile.
Keys/KMS în același domeniu/cont → blocarea accesului într-un incident.
Exercițiile numai „pe hârtie” → RTO/RPO nu sunt confirmate.

iGaming/fintech specific

Portofel/bază de plată: RPO strict (≤ 1-5 minute) și RTO (≤ 15-60 minute); jurnalele unui obiect cu WORM; Funcția DR „read-only balance” pentru o comunicare transparentă.
Furnizori PSP/conținut: pre-agreat DR-IP/domeniu, lista albă, certificate, chei HMAC/mTLS - copii în pachetul DR.
Raportare/autorități de reglementare: șabloane de notificare, arhive neschimbate, integritate dovedibilă, jurnal de activitate.
Vârfuri și evenimente: pregătirea DR este verificată înainte de turnee/promoții majore; restaurarea canarului și încălzirea CDN.

Șabloane Mini Runbook

1. Initializarea clusterului DR, incarcarea cheilor nevandute (dual-control).

2. Restabili stocare de rezervă (rece-copie).

3. Verificarea politicilor, emiterea de secrete bootstrap pentru CI/CD/K8s.

1. Extindeți o instanță goală, restaurați complet de la rece.

2. Încărcați jurnalele WAL (incremente) la momentul țintă.

3. Verificați consistența, activați replicarea, deschideți numai citirea, apoi citiți-scrieți.

1. Reduceți TTL în 24-72 de ore la riscurile planificate (sau mențineți scăzut în mod constant).

2. Comutarea A/AAAA/CNAME prin lista de verificare, monitorizarea erorilor/latenței.

3. Creșterea treptată a traficului (canar 5% → 25% → 100%).

Rezultat

Un DR de încredere bazat pe backup-uri la rece este: copii izolate imuabile, proceduri formalizate de pornire neagră, RPO/RTO clare, exerciții regulate, o strategie DNS/rețea bine gândită și disciplină cheie. Angajați totul la IaC și runbooks, automatizarea verificărilor de integritate și restaurări canare - și veți avea întotdeauna o cale controlată de recuperare chiar și după un scenariu cel mai rău caz.