Evaluarea soluțiilor de backup din perspectivă de afaceri

Luni dimineața, departamentul financiar nu poate accesa sistemul de facturare. Magazinul online continuă să primească comenzi, dar depozitul nu poate vedea ce stocuri sunt disponibile. Prima întrebare este de obicei dacă există o copie de rezervă. Întrebarea reală este însă cât timp durează să se restabilească funcționarea, ce date s-au pierdut și cine poate confirma acest lucru, pe baza evaluării soluțiilor de backup de date.

Multe companii au un fel de backup: versiuni automate ale unui serviciu cloud, un dispozitiv de stocare extern conectat la un server sau o sarcină de backup gestionată de un specialist IT. Acest lucru nu înseamnă că o situație critică din punct de vedere al afacerii poate fi gestionată. Existența unui backup și restaurarea dovedită sunt două lucruri diferite.

Evaluarea soluțiilor de backup de date începe cu procesul

Valoarea unui sistem de backup nu este determinată de capacitatea de stocare sau de numele furnizorului. Trebuie clarificat mai întâi care procese de afaceri se opresc fără date sau sistem. Într-o companie de producție, acesta poate fi planul de producție, datele mașinilor sau evidența materiilor prime. Într-o companie comercială, procesele de comandă, stoc și facturare. Într-un furnizor de servicii, datele clienților, contractele și documentele de lucru.

Este recomandat să se gândească în lanțuri operaționale, nu în aplicații. Dacă baza de date a magazinului online poate fi restaurată, dar integrarea care transmite comenzile, ERP-ul sau conexiunea cu transportatorul nu, îndeplinirea comenzilor poate necesita în continuare coordonare manuală. În acest caz, restaurarea tehnică înseamnă doar o restaurare parțială a afacerii.

În prima evaluare, trebuie urmărit cum ajunge informația de la comandă la livrare, de la cerința de producție la producție sau de la îndeplinire la facturare. Unde se generează date, între ce sisteme se mișcă și care punct de cădere paralizează munca zilnică? Acest lucru scoate adesea la iveală dependențe care rămân ascunse în funcționarea normală.

Nu toate datele prezintă același risc de afaceri

Abordarea „să salvăm totul la fel de des” poate fi costisitoare și totuși nu oferă protecție adecvată. Pierderea unui arhiv vechi de ani poate fi o problemă serioasă, dar poate să nu oprească funcționarea zilnică. În schimb, câteva ore de date de comandă, producție sau stoc pierdute pot cauza pierderi directe de venituri, îndepliniri incorecte și plângeri ale clienților.

Două întrebări ajută la luarea unei decizii clare. Una dintre ele: cât de multe date recente pot fi pierdute cel mult? Acest lucru este adesea interpretat ca un obiectiv de punct de restaurare. Dacă datele de comandă sunt salvate doar o dată pe zi, o eroare după-amiaza poate însemna o zi întreagă de reconstrucție manuală. Dacă mișcarea datelor este continuă, backup-ul de noapte nu este neapărat proporțional cu riscul.

Cealaltă întrebare: cât timp poate sta procesul respectiv? O cădere a unui sistem de salarizare poate fi suportabilă în anumite perioade, dar în altele poate pune în pericol termenele și obligațiile legale. În cazul unei căderi de câteva ore a unui sistem de depozit, echipa poate continua să lucreze pe hârtie, dar dacă acuratețea stocului este deja incertă, acest lucru poate genera rapid alte erori.

Scopul nu este reducerea riscului la zero. Acest lucru ar însemna costuri disproporționate și complexitate excesivă în aproape toate cazurile. Scopul este un echilibru acceptat la nivel de conducere între consecințele căderii, așteptările de restaurare și efortul de operare.

Backup-ul este backup doar dacă poate fi restaurat

Una dintre cele mai frecvente deficiențe este că se primesc e-mailuri despre rularea cu succes a sarcinilor de backup, dar nimeni nu a testat restaurarea în condiții similare cu cele reale. Un statut verde confirmă că niște date au fost transferate undeva. Nu confirmă automat că datele sunt intacte, complete, accesibile cu permisiunile corespunzătoare și că sistemul necesar poate fi pornit din ele.

Acest lucru este deosebit de complex în cazul bazelor de date, serverelor virtuale, serverelor de fișiere și sistemelor de afaceri integrate. Se poate întâmpla ca baza de date să fie disponibilă, dar configurația aplicației, licențele, certificatele sau setările de integrare să lipsească. Același lucru este valabil și pentru sistemele care funcționează în cloud: disponibilitatea ridicată a serviciului nu protejează neapărat compania de ștergeri eronate, probleme de permisiuni sau criptare rău intenționată.

Testul de restaurare nu trebuie să fie o simulare completă a dezastrului în fiecare săptămână. Dar trebuie verificat regulat cât timp și cu ce rezultat poate fi restaurat un fișier, o bază de date sau un sistem desemnat. Pentru procesele critice, este necesar un test documentat, măsurat în timp. Acest lucru oferă o bază reală pentru evaluarea riscurilor la nivel de conducere.

Cine și în ce ordine restaurează?

În timpul unui incident, pe lângă tehnologie, ordinea responsabilităților este crucială. Dacă un singur administrator de sistem știe din ce backup și în ce ordine trebuie restaurate ERP-ul, serverul de fișiere și integrările, compania se bazează de fapt pe cunoștințele unei singure persoane. Acesta este un risc de continuitate a afacerii, nu doar o problemă de resurse umane.

O bună ordine de restaurare stabilește clar cine decide inițierea procesului, cine gestionează pașii tehnici, cine verifică datele de afaceri și cum sunt informați managerii și clienții afectați. Nu este necesar să se reglementeze excesiv fiecare scenariu, dar în primele ore critice nu este nevoie de improvizație.

Protecție împotriva erorilor și atacurilor

Strategia de backup nu este pregătită doar pentru defecte hardware. Problemele mai frecvente includ ștergerea accidentală, importul de date eronat, o sincronizare defectuoasă sau o modificare efectuată cu permisiuni prea largi. În aceste cazuri, sistemul funcționează, dar starea datelor s-a deteriorat. În astfel de situații, sunt deosebit de valoroase copiile de rezervă păstrate pentru o perioadă adecvată, din mai multe momente.

Ransomware-urile aduc cerințe suplimentare. Dacă atacul criptează datele de producție și atacatorul accesează backup-urile cu aceleași permisiuni, posibilitatea de restaurare poate fi compromisă. De aceea, este justificată separarea backup-urilor, restricționarea accesului și utilizarea unor metode de păstrare care să nu permită suprascrierea sau ștergerea ușoară a backup-urilor deja create pentru o perioadă determinată.

Principiul 3-2-1, des menționat - mai multe copii, medii de stocare diferite, cel puțin o copie separată - este un punct de plecare util. Însă, de unul singur, nu este un plan. Nu spune ce trebuie salvat, cât de des, pentru cât timp, cu ce prioritate și cum se dovedește restaurabilitatea.

Cloud, infrastructură locală sau model hibrid?

Nu există un model potrivit în mod egal pentru toate companiile. Avantajul backup-ului bazat pe cloud poate fi separarea geografică, capacitatea flexibilă și operarea mai simplă. Totuși, în cazul unui volum mare de date sau a unei conexiuni la internet mai lente, timpul de restaurare completă poate deveni o limitare critică. Restaurarea unui server de fișiere de mai multe terabytes nu este același lucru cu restaurarea câtorva documente.

O copie locală poate oferi o restaurare mai rapidă, dar nu protejează adecvat împotriva incendiilor, furtului, întreruperilor de curent sau atacurilor care se răspândesc pe aceeași rețea, dacă nu este separată. Modelul hibrid este adesea practic din acest motiv: capacitate locală pentru restaurări rapide necesare frecvent, iar pentru evenimente mai grave, o copie separată fizic este disponibilă.

La luarea deciziei, lățimea de bandă, volumul de date, structura tehnică a aplicațiilor, cerințele de reglementare și capacitatea internă de operare contează toate. Un serviciu care sună bine nu rezolvă problema dacă compania nu știe ce sisteme protejează și cine verifică rezultatul.

Ce trebuie să vadă un lider în mod regulat?

Starea backup-ului de date nu este suficientă cu o afirmație generală că „totul este în regulă”. Conducerea trebuie să aibă o imagine scurtă și clară despre ce sisteme critice sunt incluse în backup, când a avut loc ultima restaurare verificată cu succes, dacă există sarcini de backup eșuate și în ce domenii nu se îndeplinește timpul de restaurare asumat.

Aceasta nu este microgestionare zilnică. Este o problemă de management, la fel ca precizia stocului, rebuturile de producție sau starea creanțelor. Dacă riscul este cunoscut, se poate lua o decizie dacă este acceptabil, trebuie redus sau dacă trebuie mai întâi rezolvată o dependență fundamentală de procese și sisteme.

Un backup de date bine evaluat nu este în cele din urmă o sarcină IT care rulează în fundal. Este dovada că o companie poate continua să lucreze în mod controlat după o eroare, atac sau greșeală umană. Este recomandat să nu se pună întrebările atunci când depozitul, finanțele sau serviciul clienți așteaptă deja revenirea sistemului.