Cum testăm în mod regulat backup-urile corporative?

Într-o dimineață de luni, sistemul de gestiune nu pornește. Din cauza unei erori de server, a unei actualizări defectuoase sau a unui ransomware, datele de comandă, stoc și facturare devin inaccesibile. Există o copie de siguranță - spune cineva de la IT. Este liniștitor, dar nu răspunde la întrebarea când se poate relua munca. Întrebarea reală este cum testăm în mod regulat copiile de siguranță ale companiei astfel încât, într-o situație de eroare reală, să se poată restabili cu adevărat activitatea.

În multe organizații, backup-ul este o sarcină tehnică care rulează în fundal. Sistemul îl creează zilnic, furnizorul de stocare confirmă, iar bifa verde apare pe interfața de monitorizare. Între timp, nimeni nu verifică dacă datele pot fi deschise, dacă sunt compatibile și dacă se poate restabili un sistem de afaceri utilizabil din ele. Este aceeași diferență ca atunci când există o descriere a unui proces, dar echipa nu l-a încercat niciodată în condiții reale.

Backup-ul nu devine valoros prin simpla creare a fișierelor. Devine valoros atunci când se poate demonstra că activitatea poate fi restabilită din el.

Testul de backup este de fapt un exercițiu de continuitate a afacerii

Succesul tehnic și succesul de afaceri nu sunt întotdeauna același lucru. Este posibil ca o bază de date să poată fi restabilită, dar magazinul online să nu se conecteze la stocul actual. Este posibil ca conținutul serverului de fișiere să fie disponibil, dar să lipsească permisiunile, astfel încât angajații să nu aibă acces la folderele necesare. De asemenea, se poate întâmpla ca baza de date ERP și documentele atașate să provină din momente diferite, astfel încât sistemul să pornească formal, dar starea comenzilor deschise să fie incertă.

De aceea, scopul testului nu ar trebui formulat ca „a reușit să restabilească backup-ul”. Scopul este mai degrabă acesta: un proces de afaceri desemnat poate funcționa din nou într-un timp acceptabil, cu o pierdere de date acceptabilă.

Într-o companie de comerț, aceasta poate însemna că o comandă primită prin magazinul online este introdusă în sistemul de gestiune, depozitul vede sarcina de comisionare și factura poate fi generată. Într-o companie de producție, că ordinul de producție actual, structura produsului și datele de producție sunt disponibile. Într-o companie de servicii, că contractele, datele clienților și cazurile în curs rămân accesibile.

Mai întâi trebuie clarificat ce este critic

Nu toate sistemele sunt la fel de urgente. O greșeală frecventă este că planul de backup este realizat pe baza elementelor tehnologice: servere, baze de date, mașini virtuale, foldere. Acesta este un punct de plecare necesar, dar nu este suficient pentru deciziile de conducere.

Merită să pornim de la procesele de afaceri. Ce se întâmplă dacă nu se pot primi comenzi? Cât timp poate sta livrarea din depozit? Care sunt consecințele dacă sistemul financiar nu este disponibil o zi întreagă de lucru? În ce sistem există date care nu pot fi recreate manual?

Din aceasta rezultă două valori cheie. Una este obiectivul de timp de restabilire: cât timp trebuie să dureze până când un proces funcționează din nou. Cealaltă este pierderea de date acceptabilă: cât timp de date poate lipsi cel mult. Dacă compania primește comenzi continuu, un backup din noaptea precedentă poate fi tehnic în regulă, dar din punct de vedere al afacerii, reprezintă o pierdere prea mare.

Aceste decizii nu pot fi lăsate exclusiv pe seama IT-ului. Operațiunile știu ce poate fi restabilit și în cât timp. Vânzările, finanțele, logistica sau producția pot spune ce pierdere este acceptabilă. Un plan bun de backup și restabilire se naște din întâlnirea acestor două perspective.

Cum testăm în mod regulat copiile de siguranță ale companiei?

Regularitatea nu înseamnă că în fiecare lună trebuie efectuată aceeași restabilire completă. Frecvența adecvată depinde de caracterul critic al sistemului, de numărul de schimbări și de consecințele de afaceri ale pierderii.

O practică bine funcțională constă din mai multe niveluri. Verificarea automată zilnică examinează dacă sarcinile de backup au fost finalizate, dacă fișierele de backup au fost create și dacă există erori sau modificări neobișnuite ale dimensiunii. Acesta este un semnal rapid, dar nu o dovadă de restabilire.

Următorul nivel este proba regulată de restabilire. În acest caz, într-un mediu de testare separat, se restabilește un sistem sau o bază de date selectată și se verifică utilizabilitatea acesteia. Nu este suficient ca serverul să pornească. Trebuie să vă autentificați, să deschideți datele relevante și să verificați câteva înregistrări importante pentru afaceri: ultima comandă, factură, mișcare de stoc, ordin de producție sau document.

Al treilea nivel este exercițiul de continuitate a afacerii mai complet. Acesta este de obicei efectuat anual, în medii critice chiar mai frecvent. Aici nu este vorba doar de restabilirea unei singure componente, ci de testarea unui lanț de afaceri real. Rezultatul dezvăluie cel mai adesea că o integrare, un certificat, o permisiune, o regulă de rețea sau o dependență de furnizor extern lipsește pentru funcționarea efectivă.

Testul trebuie efectuat într-un mediu separat

Restabilirea unui backup pe un sistem live este riscantă. Poate suprascrie datele recente, poate întrerupe conexiunile sau poate provoca efecte secundare care pun în pericol funcționarea normală. Principiul de bază al testării este, prin urmare, izolarea.

Mediul restabilit nu trebuie să aibă întotdeauna aceeași dimensiune ca infrastructura originală, dar dependențele critice trebuie să fie reprezentate fidel. Dacă aplicația depinde de o bază de date, stocare de fișiere, serviciu de directoare și API extern, testul trebuie să țină cont de acest lucru. În caz contrar, doar dovedim că există un fișier de backup, nu că serviciul poate fi restabilit.

Sistemele integrate merită o atenție specială. Magazinul online, ERP, sistemul de depozit și conexiunea de curierat pot fi fiecare salvate, dar restabilirea stărilor dintre ele este o problemă mai complexă. Dacă o comandă este deja procesată într-un sistem, dar nu apare încă în altul, după restabilire poate apărea o dublă îndeplinire, un stoc incorect sau o situație de facturare neclară.

Să existe dovezi, nu doar amintiri

„Am încercat odată anul trecut” nu este un control. Fiecare test necesită un raport scurt și ușor de găsit: din ce backup s-a făcut restabilirea, când a fost făcut backup-ul, cât a durat restabilirea, ce verificări au fost efectuate, ce nu a funcționat din prima și cine a aprobat rezultatul.

Aceasta nu este o povară administrativă de dragul poverii. După un timp, face vizibile tendințele. Crește timpul de restabilire? A apărut o nouă dependență după o actualizare de sistem? Din diferențele documentate se pot crea sarcini de dezvoltare, se poate desemna un responsabil și se poate stabili un termen limită.

Testele trebuie să aibă un proprietar. IT-ul sau un operator extern poate fi responsabil pentru execuția tehnică, dar acceptarea de afaceri trebuie să fie dată de domeniul care utilizează procesul. Un manager de depozit, de exemplu, recunoaște mult mai rapid că datele de stoc restabilite sunt inutilizabile decât cineva care doar vede că conexiunea la baza de date a reușit.

Cele mai frecvente greșeli în practica de backup

Una dintre problemele tipice este că se face backup în același mediu pe care îl folosește și sistemul original. Un ransomware, o eroare de permisiuni sau o eroare de infrastructură poate afecta astfel și backup-urile. Backup-ul trebuie să fie izolat fizic și logic și protejat împotriva modificărilor sau ștergerilor neautorizate.

Este frecvent și faptul că se gândesc doar la serverul central. Sunt omise documentele gestionate în cloud, exporturile sistemelor SaaS, configurațiile, setările dispozitivelor de rețea, cheile de integrare sau fișierele încărcate asociate aplicațiilor personalizate. Pentru restabilirea unui sistem, de multe ori nu este necesară doar baza de date, ci și toate elementele care înconjoară funcționarea sistemului.

A treia greșeală este ignorarea schimbărilor. După un nou modul de magazin online, o nouă locație, un model de permisiuni modificat sau un proces de depozit reorganizat, vechiul test de backup nu mai oferă neapărat un răspuns real. Planul de backup trebuie legat de gestionarea schimbărilor la fel ca orice alt proces de afaceri critic.

Un backup bine testat nu este un rezultat spectaculos. Nu accelerează direct facturarea și nu reduce administrația de pe o zi pe alta. Totuși, atunci când din cauza unei erori toată lumea pune aceeași întrebare - „când putem lucra din nou?” -, capacitatea de restabilire dovedită nu va fi un detaliu tehnic, ci un spațiu de manevră pentru conducere.