Backup existent și backup testat: diferența se vede la restaurare

Pe scurt: aproape toate companiile au backup. Mult mai puține știu cât durează restaurarea și dacă ea chiar funcționează. Diferența dintre cele două situații se măsoară în zile de activitate oprită și se descoperă, de regulă, în ziua cea mai nepotrivită.

Întrebarea utilă nu este „avem backup”

Întrebarea care contează are trei părți: cât de veche este ultima copie utilizabilă, cât durează până repornim serviciul și cine confirmă că restaurarea a reușit. Un raport verde de la aplicația de backup nu răspunde la niciuna dintre ele. Raportul spune că sarcina a rulat, nu că datele pot fi aduse înapoi într-o formă în care oamenii își reiau lucrul.

Verificarea aceasta nu costă mult și nu durează mult. Motivul pentru care se amână este că nimeni nu vrea să afle răspunsul într-o săptămână aglomerată.

Ce se descoperă abia la prima restaurare reală

• Sarcina rulează, dar sare peste fișiere. Fișierele blocate, erorile de copiere în umbră și avertismentele marcate „warning” se acumulează în jurnale pe care nu le citește nimeni. Sarcina se încheie cu succes parțial și raportul rămâne verde.
• Se salvează serverul, nu și baza de date. O copie la nivel de fișier a unei baze de date deschise produce un fișier care nu pornește. Bazele de date au nevoie de o metodă proprie de salvare, consecventă cu tranzacțiile.
• Toate copiile stau în aceeași rețea. Dacă singura copie este pe un NAS din aceeași clădire, accesibil cu aceleași conturi, un incident de criptare ajunge la ea în același minut cu datele originale.
• Microsoft 365 este presupus salvat de Microsoft. Revenim mai jos la acest punct, pentru că este cea mai frecventă confuzie.
• Lipsesc cheile și parolele. Copia este criptată corect, iar cheia se află în sistemul care tocmai a dispărut sau la un coleg care nu mai lucrează în companie.
• Nu există unde restaura. Nu este echipament liber, licențele sunt legate de hardware-ul vechi, iar achiziția unui server nou are termen de livrare.
• Restaurarea durează mai mult decât suportă activitatea. Volumele mari aduse înapoi dintr-o locație la distanță depind de lățimea de bandă. Calculați durata înainte, nu în timpul incidentului.

RTO și RPO: două numere pe care le stabilește conducerea

RPO este cantitatea de date pe care vă permiteți să o pierdeți, exprimată în timp: distanța până la ultima copie utilizabilă. RTO este timpul în care serviciul trebuie să fie din nou funcțional.

Ambele sunt decizii de afaceri, nu decizii tehnice. Se stabilesc separat pentru fiecare sistem, pentru că nu au aceeași valoare: facturarea oprită o zi costă altceva decât arhiva de proiecte indisponibilă o zi. Odată stabilite, cele două numere dictează arhitectura și bugetul, în ordinea aceasta. Fără ele, orice soluție de backup este o alegere la întâmplare, iar discuția despre preț nu are un reper.

Regula 3-2-1 și ce i s-a adăugat

Cifra	Ce înseamnă în practică
3	Trei copii ale datelor: cea în uz și încă două
2	Pe două tipuri diferite de suport sau la două tehnologii diferite
1	Una în altă locație fizică decât sediul
1	Una offline sau imutabilă, pe care nimeni nu o poate șterge ori modifica în perioada de retenție
0	Zero erori la verificarea restaurării

Primele trei cifre sunt cunoscute și, de obicei, respectate măcar parțial. Ultimele două lipsesc cel mai des, iar ele sunt cele care fac diferența în fața unui atac și în fața unei defecțiuni tăcute.

Cum arată un test de restaurare serios

1. Alegeți un sistem, nu un fișier. Restaurarea unui document dovedește că funcționează restaurarea unui document.
2. Restaurați într-un mediu izolat, separat de rețeaua de producție, ca testul să nu poată provoca el însuși o problemă.
3. Porniți aplicația și verificați cu oamenii care o folosesc. Validarea o dau utilizatorii care recunosc datele, nu serviciul care pornește fără eroare.
4. Cronometrați tot. Timpul real curge de la decizie până la serviciu funcțional și include căutarea parolelor, descărcarea datelor și reconfigurarea.
5. Notați ce a lipsit. Un pas nedocumentat, o licență, un certificat expirat, un cont fără drepturi. Lista aceasta este rezultatul cel mai valoros al testului.
6. Repetați periodic, trimestrial pentru sistemele critice și anual pentru restul, precum și după orice schimbare majoră de infrastructură.

Rezultatul se consemnează în scris, cu data, durata măsurată și deficiențele constatate. Un test fără raport nu poate fi arătat nimănui și se uită până la următorul.

Microsoft 365 și responsabilitatea partajată

Microsoft răspunde de disponibilitatea serviciului și de infrastructura care îl susține. Conținutul din Exchange, SharePoint, OneDrive și Teams rămâne responsabilitatea companiei dumneavoastră. Retenția implicită acoperă ștergerea accidentală pe termen scurt și este utilă, dar are limite de timp și nu a fost gândită ca backup.

Situațiile pe care nu le acoperă sunt exact cele costisitoare: un cont compromis care șterge sistematic, o politică de retenție configurată greșit, eliberarea licenței unui angajat care pleacă, o migrare făcută în grabă. Pentru acestea este nevoie de o copie separată, la alt furnizor sau local. Am scris separat despre împărțirea responsabilităților între furnizor și companie în articolul despre cloud privat și cloud public, iar partea de licențiere și administrare o detaliem pe pagina Microsoft 365 și cloud.

Ransomware schimbă cerințele

Atacatorii caută întâi copiile de siguranță, pentru că o companie care poate restaura nu plătește. Din acest motiv, cerințele s-au mutat de la „există o copie” la „există o copie pe care atacatorul nu o poate atinge”.

• Stocare imutabilă sau o copie offline, scoasă din rețea.
• Consolă de backup cu autentificare separată de conturile de domeniu și cu autentificare în doi pași.
• Alerte la ștergeri în masă și la modificarea politicilor de retenție.
• Jurnale păstrate în altă parte decât pe sistemul care le generează.

Dacă firma dumneavoastră intră sub incidența NIS2, continuitatea activității și gestionarea copiilor de rezervă sunt prevăzute explicit printre măsurile de gestionare a riscurilor, iar autoevaluarea anuală le include. Testul de restaurare devine, în acest caz, un document pe care îl aveți de prezentat.

Șase întrebări pentru responsabilul sau furnizorul dumneavoastră IT

1. Când a fost ultima restaurare completă testată și cât a durat, măsurat?
2. Ce sisteme nu sunt în backup în acest moment și de ce?
3. Unde este copia din afara sediului și cine are dreptul să o șteargă?
4. Dacă pierdem azi serverul principal, pe ce echipament restaurăm?
5. Cine primește alertele când o sarcină eșuează și ce se întâmplă în ziua următoare?
6. Avem o procedură scrisă de recuperare, cu pașii, conturile și locul unde se găsesc cheile?

Dacă răspunsul la prima întrebare este că nu s-a testat niciodată o restaurare completă, restul discuției este despre costuri ipotetice.

Ce facem noi și ce rămâne la dumneavoastră

PRO IT proiectează schema de backup pornind de la RTO și RPO stabilite împreună cu dumneavoastră, instalează și administrează soluția, monitorizează sarcinile zilnic, execută teste de restaurare programate cu raport scris și păstrează actualizată procedura de recuperare. Toate acestea fac parte din serviciul de mentenanță IT și suport. Dacă nu știți de unde porniți, auditul IT stabilește ce există acum, ce lipsește și în ce ordine se rezolvă.

Rămân la dumneavoastră deciziile care nu sunt tehnice: cât timp poate sta oprit fiecare sistem, ce buget primește a doua locație și cine are autoritatea să declare incidentul și să pornească restaurarea.

Dacă nu aveți un raport de test de restaurare din ultimele douăsprezece luni, acesta este primul lucru de programat.