Seria II: De la infrastructură la proiecte agentice în producție. Episodul 15 din 20.
Observabilitatea arată că portalul are o problemă, dar nu aduce singură datele înapoi. Pentru o firmă mică sau mijlocie, decizia esențială este să finanțeze o recuperare demonstrabilă, nu doar spațiu pentru copii. Un mesaj „backup reușit” confirmă executarea unei operații; nu dovedește că oamenii pot relua lucrul în timpul necesar firmei.
Continuăm portalul B2B fictiv pentru solicitări și documente printr-un scenariu ipotetic: unele fișiere nu se mai deschid, iar procesarea documentelor se oprește. Cauza poate fi o eroare sau o compromitere. Nu atribuim situația unui client și nu presupunem că simpla restaurare rezolvă cauza.
Disponibilitatea și backupul rezolvă probleme diferite
Disponibilitatea ridicată urmărește menținerea serviciului prin componente redundante. Replicarea copiază modificările către altă instanță sau locație. Ajută când o componentă cade, dar poate propaga și ștergerea accidentală ori datele corupte. Nu înlocuiește istoricul recuperabil.
Un snapshot păstrează starea datelor la un moment dat. Dacă depinde de aceeași stocare și de aceleași drepturi administrative, pierderea acestora poate afecta și snapshotul. El poate face parte din strategia de backup, dar nu constituie singur protecție independentă.
Un backup este o copie păstrată pentru restaurare, cu versiuni și reguli de retenție, adică de păstrare. Distincția utilă nu este „local versus cloud”, ci ce incident poate afecta simultan producția și copiile. Două directoare pe același sistem nu acoperă pierderea acelui sistem.
Stabilim pierderea acceptabilă înaintea soluției
RPO, obiectivul punctului de recuperare, exprimă până la ce moment trebuie recuperate datele după întrerupere. Practic, îl discutăm ca interval de date pe care firma acceptă să îl piardă. RTO, obiectivul timpului de recuperare, stabilește durata țintă în care resursa trebuie readusă în funcționare, înaintea unui impact inacceptabil.
Pentru portal propunem, strict ilustrativ, un RPO de 30 de minute și un RTO de patru ore. Dacă incidentul apare la 14:00, iar ultima stare curată recuperabilă este de la 13:40, rămâne un interval potențial pierdut de 20 de minute. Dacă descoperim că doar copia de ieri este utilizabilă, ținta nu este atinsă, indiferent câte operații au fost raportate ca reușite.
Aceste valori nu sunt garanții i8 sau recomandări universale. Responsabilul procesului stabilește impactul, iar echipa tehnică verifică fezabilitatea prin exerciții. Precizăm de când măsurăm întreruperea și includem dependențele și validarea, nu doar transferul fișierelor.
Inventariem ceea ce trebuie recuperat împreună
Portalul are nevoie de baza de date cu solicitări, documentele încărcate, configurație, versiunea aplicației și accesul la serviciile necesare. Registrul copiilor trebuie să arate ce acoperă fiecare mecanism și ce rămâne în afara lui. Codul păstrat separat ajută reconstrucția, dar nu conține automat datele clienților.
Dacă alegem PostgreSQL 18 pentru acest scenariu, recuperarea la un moment ales, numită PITR, poate combina un backup de bază cu arhivele WAL, jurnalul modificărilor bazei de date. Documentația cere continuitatea jurnalelor necesare. Acest mecanism nu recuperează automat fișierele documentelor sau modificările configurației.
Prin urmare, verificăm coerența dintre înregistrări și fișiere: un document indicat în baza restaurată trebuie să existe și să fie lizibil. Pentru un agent integrat ulterior în portal, inventariem și starea lucrărilor. Nu reluăm orbește sarcini care ar putea trimite din nou notificări sau executa alte acțiuni externe.
Protejăm copiile și calea de acces
Propunem copii cu istoric într-un spațiu separat de producție și cel puțin o copie offline sau protejată împotriva modificării. Imuabilitatea blochează modificarea ori ștergerea datelor protejate în condițiile mecanismului ales. Nu înseamnă că informația copiată era corectă sau că toate conturile sunt invulnerabile.
De exemplu, Amazon S3 Object Lock protejează versiuni de obiecte; modul Governance permite ocolirea retenției cu drepturi speciale, spre deosebire de protecția modului Compliance în perioada stabilită. Verificăm configurația efectivă, nu doar eticheta comercială „immutable”.
Separăm drepturile de administrare a copiilor de cele ale aplicației și protejăm cheile de criptare. Criptarea face datele ilizibile fără cheia corespunzătoare, dar pierderea cheii poate împiedica restaurarea. Testăm accesul de urgență autorizat și păstrăm instrucțiunile într-un loc disponibil și când portalul este oprit.
Verificăm și resursele necesare recuperării: spațiu liber, conectivitate, acces la pachetele aplicației și disponibilitatea persoanei care poate aproba intervenția. Un plan care presupune un server de rezervă inexistent nu îndeplinește ținta. În cloud verificăm explicit serviciile și datele acoperite de contract, fără să presupunem că furnizorul protejează orice greșeală a aplicației.
Recuperarea urmează o ordine, nu un impuls
Pentru incidentul ipotetic, propunem următorul traseu, adaptat după diagnostic:
Pas | Responsabil propus | Dovada necesară |
|---|---|---|
Limitarea impactului | Coordonatorul incidentului și administratorul | Operații afectate oprite controlat, zone suspecte izolate |
Investigarea | Responsabilul tehnic, cu specialist la nevoie | Cronologie, jurnale și modificări păstrate cu acces controlat |
Alegerea stării recuperabile | Administratorul datelor | Copii verificate și punct de recuperare justificat |
Refacerea izolată | Echipa tehnică | Mediu curat, aplicație compatibilă și date coerente |
Redeschiderea | Coordonatorul și responsabilul procesului | Teste acceptate și monitorizare activă |
Izolarea și păstrarea dovezilor trebuie coordonate; nu ștergem sistemul suspect înaintea evaluării. Dacă există indicii de compromitere, cerem ajutor specializat, verificăm persistența atacatorului și schimbăm credențialele afectate dintr-un mediu de încredere. Alegem o copie curată justificabilă, nu neapărat cea mai recentă.
NIST SP 800-61 Rev. 3, publicat în aprilie 2025, recomandă verificarea integrității copiilor înainte de utilizare și remedierea cauzelor înaintea revenirii în producție. Îl folosim ca reper tehnic, nu ca afirmație de conformitate juridică a unui IMM românesc.
Restaurarea nu retrage documentele deja divulgate unui atacator. Dacă investigația indică expunerea datelor, coordonatorul tratează separat consecințele și comunicarea, împreună cu persoanele competente. Revenirea interfeței online nu închide automat incidentul.
Testăm procesul, nu doar descărcarea
Propunem un exercițiu inițial și repetarea lui după schimbări importante, apoi o frecvență stabilită după risc. Restaurăm într-un mediu izolat, fără e-mailuri sau acțiuni externe reale. Verificăm autentificarea, separarea organizațiilor, documentele și stările solicitărilor. Măsurăm timpul până la acceptarea funcțiilor esențiale și diferența față de ținte.
Studiul Amvrosiadis și Bhadkamkar, prezentat la USENIX ATC în 2016, a identificat configurarea greșită drept cauza majorității erorilor de backup din setul analizat. Rezultatul privește instalațiile produsului studiat, nu rata de eșec a sistemelor actuale. Este un motiv să verificăm procedura, fără să transformăm cercetarea într-o promisiune comercială.
Fișa finală a portalului conține inventarul, RPO și RTO aprobate, locațiile copiilor, accesul de urgență, ordinea recuperării, responsabilii și rezultatul ultimului exercițiu. Include și modul de informare a utilizatorilor și de reconciliere a solicitărilor primite în perioada întreruperii.
Agenții care dezvoltă portalul pot pregăti scripturi și teste, dar nu primesc implicit dreptul de a șterge copii sau de a redeschide producția. Agenții integrați în aplicație rămân opriți până la verificarea stării lor. Episodul următor tratează API-urile și repetările sigure, pentru a reduce duplicarea acțiunilor la reluare.
Surse
Surse verificate la 16 octombrie 2026:
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, 2010, actualizat la 11 noiembrie 2010, pentru obiectivele și prioritățile recuperării.
- NIST SP 800-61 Rev. 3, aprilie 2025, în special RC.RP-03 și RC.RP-05, pentru integritatea copiilor și revenirea sigură.
- PostgreSQL 18, Continuous Archiving and Point-in-Time Recovery, pentru condițiile și limitele recuperării bazei de date.
- Amazon S3, Locking objects with Object Lock, pentru protecția versiunilor și diferențele dintre modurile de retenție.
- Amvrosiadis și Bhadkamkar, Getting Back Up: Understanding How Enterprise Data Backups Fail, USENIX ATC, iunie 2016, pentru studiul empiric al erorilor de backup.
Vrei să verifici dacă sistemele tale pot fi recuperate în timpul necesar firmei? Discută cu i8 despre backup, teste de restaurare și continuitate.
