Un backup verificat este o condiție necesară pentru revenirea din dezastru, dar nu este un plan. Backupul răspunde la o singură întrebare: de unde luăm datele. În dimineața în care sala de servere este sub apă apar imediat alte șase. În ce ordine repornim sistemele. Cine are dreptul să decidă trecerea pe locația secundară. Cât durează, realist. Ce se întâmplă cu comenzile primite în acest interval. Cine vorbește cu clienții. Cine anunță autoritatea.
Un plan de disaster recovery este răspunsul scris la aceste întrebări, formulat înainte, pentru că în timpul incidentului nimeni nu are liniștea necesară ca să îl formuleze. Dacă partea de copii de siguranță nu este încă așezată, regula 3-2-1 este punctul de plecare, iar textul de mai jos presupune că acolo lucrurile funcționează deja.
Diferența dintre a avea datele și a reveni în funcțiune
O restaurare este o operațiune tehnică cu un rezultat măsurabil. Un plan de disaster recovery este un arbore de decizie care acoperă oameni, ordine, dependențe și comunicare, iar cea mai mare parte a lui nu are legătură cu stocarea.
Diferența se vede cel mai clar în ordinea de repornire. Datele pot fi complete și corecte, dar dacă aplicația de gestiune pornește înaintea bazei de date, iar baza de date pornește înaintea serviciului de identitate care autentifică utilizatorii, rezultatul este o serie de reporniri și un timp de indisponibilitate de câteva ori mai mare decât suma operațiunilor. Ordinea nu se deduce în timpul incidentului. Se scrie înainte, plecând de la ce depinde de ce.
RTO și RPO se stabilesc pe sistem, nu pe companie
Cele două valori care structurează un plan sunt RTO, timpul acceptabil până la revenirea în funcțiune, și RPO, volumul de muncă pe care organizația își permite să îl pierdă. Ambele sunt decizii de business, nu decizii tehnice, iar problema apare atunci când sunt stabilite o singură dată, pentru toată infrastructura.
O valoare unică este întotdeauna greșită în două direcții simultan. Pentru arhiva de documente scanate este scump inutil. Pentru sistemul de facturare este prea permisiv.
Merită o socoteală concretă. Un sistem de gestiune care primește în medie 60 de documente pe oră, într-un program de nouă ore, are un RPO de o zi lucrătoare dacă singura copie este cea de noapte. Un incident la ora 17 înseamnă aproximativ 540 de documente reintroduse manual, plus reconcilierea cu partenerii care au primit deja confirmări. Dacă acest volum nu este acceptabil, RPO-ul nu se corectează cu o politică, ci cu jurnalizare mai frecventă și cu costul care vine împreună cu ea.
RTO are o constrângere suplimentară: trebuie să treacă testul aritmeticii. Patru terabytes transferați printr-o legătură de 100 Mbps, adică aproximativ 12,5 MB pe secundă în condiții ideale, cer în jur de 89 de ore doar pentru copiere, fără despachetare, fără pornirea serviciilor și fără verificări. Un RTO de opt ore scris într-un document, alături de o astfel de arhitectură, este o declarație de intenție, nu un obiectiv.
Dependențele pe care nimeni nu le desenează
Aici se pierd majoritatea exercițiilor de failover, iar componentele vinovate sunt aproape mereu aceleași.
DNS. Trecerea traficului pe locația secundară se face, de obicei, prin schimbarea unei înregistrări. Dacă TTL-ul este de 86400 de secunde, o parte din clienți și din rezolvatorii intermediari vor continua să primească adresa veche aproape o zi. Reducerea TTL-ului la 300 de secunde este o operațiune de câteva minute, dar trebuie făcută înainte de incident, nu în timpul lui.
Identitatea. Controlerele de domeniu, serviciul de federare și mecanismul de autentificare cu mai mulți factori sunt dependențe pentru toate celelalte sisteme. Un plan care presupune că administratorii se autentifică pentru a porni recuperarea, în timp ce serviciul care le validează identitatea se află în locația indisponibilă, are o buclă în el.
Licențierea. Serverele de licențe, activarea sistemelor de operare și licențele legate de un identificator hardware nu se mută împreună cu mașinile virtuale. O aplicație restaurată corect care refuză să pornească pentru că nu găsește serverul de licențe produce exact aceeași întrerupere ca una pierdută.
Certificatele. Cheia privată a certificatului folosit de portalul public sau de concentratorul VPN se află, în multe infrastructuri, exclusiv pe mașina pierdută. Merită verificat și dacă certificatul folosit pentru accesul de administrare nu expiră chiar în perioada în care planul ar trebui executat.
La acestea se adaugă două cazuri care apar frecvent: accesul de administrare care trece prin același concentrator VPN aflat în locația afectată, și managerul de parole găzduit pe infrastructura care nu mai răspunde. Ambele se rezolvă simplu, dar numai dacă cineva le identifică înainte.
Cald, pilot light sau rece: ce costă fiecare abordare
Cele trei abordări nu se aleg pentru toată infrastructura, ci pentru fiecare sistem, în funcție de RTO-ul lui.
Rece înseamnă doar datele și procedura. Nu rulează nimic în locația secundară, costul continuu este cel al stocării, iar RTO-ul se măsoară în zile pentru că infrastructura trebuie creată de la zero. Este alegerea corectă pentru arhive și pentru sisteme interne care pot lipsi o săptămână fără consecințe.
Pilot light păstrează pornite doar componentele mici și greu de reconstituit: un controler de domeniu, o replică a bazei de date care primește jurnalele, configurația și imaginile de sistem. Restul se creează în momentul declarării. Cum în orice factură de infrastructură partea de calcul domină, iar aici ea aproape lipsește între incidente, costul continuu rămâne mult mai aproape de varianta rece decât de una duplicată. RTO-ul se măsoară în ore.
Cald înseamnă un mediu funcțional, la capacitate redusă, care primește actualizări continuu și poate prelua traficul în minute. Costul se apropie de cel al unui al doilea mediu de producție, motiv pentru care se justifică pentru unul sau două sisteme, nu pentru toate.
Cine are dreptul să declare dezastrul
Aceasta este partea cel mai des omisă și cea mai costisitoare. Într-o întrerupere reală, primele două ore se consumă frecvent în discuții despre dacă situația este suficient de gravă pentru a trece pe locația secundară, iar discuția are loc pentru că nimeni nu a scris în avans cine decide și pe baza căror criterii.
Un plan utilizabil conține trei lucruri. Criterii observabile, formulate astfel încât răspunsul să fie același indiferent cine le citește: de exemplu, sistemul principal nu răspunde de peste 45 de minute și cauza nu este identificată. O persoană nominalizată cu drept de decizie, plus cel puțin doi înlocuitori, pentru cazul previzibil în care prima persoană este în concediu sau într-un avion. Și o escaladare limitată în timp, care transferă automat autoritatea dacă persoana desemnată nu poate fi contactată în intervalul stabilit.
Merită precizat și cine decide revenirea pe infrastructura principală. Failbackul se face în condiții mai bune, cu timp de pregătire, dar este operațiunea în care se pierd cel mai des datele acumulate în locația secundară.
Runbookuri care funcționează sub presiune
Un runbook nu se scrie pentru autorul lui. Se scrie pentru un coleg obosit, la trei dimineața, care execută procedura pentru prima dată în timp ce mai mulți oameni așteaptă un răspuns.
Ceea ce face diferența: pași numerotați, cu comenzile exacte, nu descrieri de tipul „se restaurează conform procedurii standard”. Rezultatul așteptat după fiecare pas, astfel încât abaterea să fie observabilă imediat. Punctele de decizie marcate explicit, cu ambele ramuri descrise. O estimare de durată pentru fiecare etapă, care este și baza comunicării către restul organizației. Și indicația de unde se obțin credențialele, într-un scenariu în care sistemele obișnuite nu răspund.
Testul de calitate este simplu: procedura este executată de cineva care nu a participat la scrierea ei, fără să întrebe nimic. Dacă apar întrebări, ele indică exact ce lipsește din document.
Exercițiu pe hârtie sau failover real
Cele două formate găsesc categorii diferite de probleme și niciunul nu îl înlocuiește pe celălalt.
Un exercițiu de tip tabletop durează aproximativ 90 de minute, nu afectează producția și scoate la iveală lipsurile de decizie și de comunicare: autoritatea neclară, contactele expirate, presupunerile contradictorii despre ce face fiecare echipă. Este ieftin, deci poate fi făcut trimestrial.
Un failover real găsește lucrurile pe care discuția nu le poate găsi: adresa IP scrisă direct în configurația unei aplicații, regula de firewall care lipsește în locația secundară, certificatul expirat, scriptul care depinde de un share indisponibil. Aceste defecte nu apar niciodată pe hârtie, pentru că nimeni nu știe că există.
Un test real anual, într-o fereastră anunțată, este minimul rezonabil pentru sistemele critice. Dacă organizația nu acordă niciodată o astfel de fereastră, aceasta este în sine o concluzie care merită formulată în scris: planul nu a fost validat și RTO-ul rămâne o estimare.
Comunicarea în timpul unei întreruperi
Comunicarea nu este o activitate paralelă cu recuperarea, ci o parte din ea, iar absența ei generează un al doilea incident, format din apeluri și presiune peste echipa tehnică.
Canalul de comunicare nu trebuie să depindă de infrastructura afectată. Dacă poșta electronică și platforma de colaborare folosesc același serviciu de identitate care nu răspunde, echipa rămâne fără canal exact în momentul în care are nevoie de el. Un grup pe o platformă independentă și o listă de numere de telefon păstrată offline rezolvă problema.
Restul este disciplină: mesaje pregătite din timp pentru scenariile probabile, o cadență fixă de actualizare respectată chiar și când nu există noutăți, o singură sursă de informație pentru a evita versiunile contradictorii, și separarea clară între cine vorbește cu clienții, cine cu angajații și cine cu autoritățile.
Ce cere cadrul de reglementare în România
Pentru companiile aflate sub incidența NIS2, continuitatea activității și recuperarea în caz de dezastru sunt cerințe explicite între măsurile de administrare a riscurilor, iar supravegherea la nivel național este atribuită Directoratului Național de Securitate Cibernetică. Nu se impune o tehnologie anume, se cere existența măsurii și capacitatea de a demonstra că funcționează.
Există și o componentă de raportare, cu termene în trepte pentru incidentele semnificative: o notificare inițială în primele 24 de ore și un raport mai detaliat în 72 de ore. Aceste termene au o consecință practică asupra planului. Cineva trebuie nominalizat pentru raportare, cu datele de contact la îndemână, iar decizia dacă un incident este semnificativ nu poate fi luată pentru prima dată sub presiune.
Documentația exercițiilor, cu date, durate măsurate și probleme identificate, este forma în care aceste cerințe se demonstrează la un audit.
Pasul următor
Cel mai rapid mod de a afla unde vă aflați este să alegeți sistemul cel mai important și să răspundeți în scris la trei întrebări: cine declară dezastrul, de ce depinde acel sistem pentru a porni, și cât durează efectiv repornirea lui în altă locație. Dacă vreuna dintre ele nu are un răspuns scris, aceea este prima lucrare.
Proiectăm și testăm planuri de recuperare în cadrul serviciului de backup și disaster recovery, iar maparea dependențelor și stabilirea obiectivelor pe sistem țin de arhitectura de infrastructură.