9 din 10 companii din categoria SMB nu reușesc să își mai reia activitatea în anul care urmează unui dezastru, dacă nu își restabilesc serviciile și reiau operațiunile în mai puțin de 5 zile de la petrecerea evenimentului. Iar între 40% și 60% dintre companiile mici și mijlocii nu-și mai revin niciodată dintr-un dezastru care implică pierderi masive de date.

Datele de mai sus sunt rezultate ale unor studii statistice internaționale, de la care România nu face excepţie. Mai ales că – așa cum arată un studiu Frames – aproape trei sferturi dintre companiile locale nu dețin un plan de continuitate a afacerii. Din păcate, chiar și atunci când își construiesc unul, o fac doar „de formă“, confundând adesea conceptul de Business Continuity cu cel de Disaster Recovery.
Pe undeva, eroarea este scuzabilă, pentru că ariile de acoperire se suprapun: Business Continuity Plan (BCP) sub-include Disaster Recovery Plan (DRP), abordând o problematică extinsă pe care am detaliat-o într-o postare anterioară.
Din această perspectivă, Disaster Recovery Plan poate fi considerat drept componenta „pragmatică“ a BCP, responsabilă cu asigurarea efectivă a reluării activității în intervalul de timp și în condițiile prevăzute, astfel încât impactul asupra activității de business să fie minim.

La nivel general, planul de recuperare în caz de dezastru (DRP) trebuie să includă următoarele etape generice:

• stabilirea categoriilor de riscuri cu frecvență crescută;
• identificarea aplicațiilor critice care pot fi afectate de aceste riscuri;
• evaluarea impactului pe care nefuncționarea aplicațiilor îl poate avea asupra activității companiei;
• identificarea soluțiilor și măsurilor concrete de restaurare și a condițiilor în care trebuie restabilite.

Aparent, lucrurile sunt simple, însă parcurgerea acestor etape și stabilirea unor măsuri eficiente, care să poată fi asamblate într-un plan coerent, necesită experiență și competențe în domeniu. Sunt cerințe pe care puține companii le pot acoperi din resurse interne, mai ales că – pentru ca planul DRP să fie nu doar eficient, ci și financiar accesibil – trebuie găsit un echilibru între costuri și nivelul de disponibilitate optim.

O altă zonă delicată, care solicită apelul la expertiza specialiștilor, este stabilirea obiectivelor-cheie specifice planului de Disaster Recovery:

• Recovery Time Objective (RTO) – reprezintă intervalul de timp admis în care o aplicație poate fi nefuncțională fără să producă pagube semnificative pentru business. De exemplu, anumite aplicații pot să fie inactive timp îndelungat (e-mail, spre exemplu), fără ca acest lucru să aibă consecințe nefaste, în timp ce în cazul altora, chiar și o întrerupere de câteva minute poate cauza pierderi de venituri, frustrarea clienților, ratarea de oportunități (POS-ul unui magazin).
  De aceea, ierarhia RTO trebuie stabilită în funcție de nivelul de criticitate al aplicațiilor și de valoarea și amploarea pagubelor pe care le produce sistarea utilizării acestora. Această ierarhizare se transpune în costuri directe, pentru că, de exemplu, aplicațiile care necesită RTO-uri rapide, de ordinul minutelor, au nevoie de servicii de tip Failover, în timp ce în cazul celor cu RTO-uri de până la 4 ore se pot utiliza servicii de restaurare de tip bare metal.
• Recovery Point Objective (RPO) – se referă la toleranța unei companii la volumul de date pe care și-l poate permite să îl piardă, fără să înregistreze un impact semnificativ asupra business-ului. De exemplu, dacă compania voastră realizează zilnic un back-up incremental, în cazul unui eveniment pierdeți doar datele modificate în ultimele 24 de ore. Ceea ce pentru anumite aplicații ar putea fi acceptabil, în timp ce pentru altele – nu. RPO este exprimat, ca și RTO, în minute și ore și măsoară timpul efectiv din momentul în care survine evenimentul și cel mai recent back-up disponibil. În cazul RPO este important însă și intervalul de timp în care are loc incidentul, pentru că, dacă pentru o aplicație aveți, de exemplu, un RPO de patru ore și evenimentul perturbator se petrece la miezul nopții în weekend, s-ar putea ca efectul să fie insignifiant. Dacă are loc însă în mijlocul săptămânii, la ora 10 dimineața, iar restaurarea completă a aplicației se realizează abia la ora 14, pagubele pot fi substanțiale. Și durata RPO-ul trebuie stabilită în funcție de nivelul de criticitate al aplicațiilor – poate varia de la 24, 12, 8, 4 ore, până la intervale de ordinul minutelor, alegerile decizând tipul soluțiilor folosite. Astfel, pentru un RPO de 8 ore se pot utiliza soluțiile de back-up locale, la cele de 12 ore și peste – serviciile Cloud. Pentru cele de 4 ore, sunt necesare soluții de replicare periodică prin snapshot, în timp ce pentru RPO-urile de ordinul minutelor – replicarea continuă în combinație cu soluții de failover.

Dacă vreți să aveți un plan de Disaster Recovery realist, care să vă acopere cu adevărat nevoile, trebuie să faceți o evaluare RTO/RPO pentru fiecare aplicație în funcție de nivelul ei de criticitate în desfășurarea business-ului vostru. Pornind de aici stabiliți strategia optimă de back-up și măsurile efective de restaurare (responsabili, proceduri specifice, ordinea restabilirii etc.)

Totodată, pentru ca protecția să fie reală, nu uitați că în anumite situații este imperios necesară existența unui site de Disaster Recovery extern dedicat. Pe care fie îl puteți realiza și opera singuri, fie apelați la furnizori de astfel de servicii – care vă oferă găzduire pentru echipamentele voastre în centrele lor sau servicii de restaurare de pe infrastructura lor. (O opțiune de luat în calcul este și Disaster Recovery as-a-Service, ținând însă cont de limitările specifice acestei oferte.)

Dacă nu doriți să verificați pe propria piele pertinența statisticilor amintite în deschidere, strategia de Disaster Recovery nu trebuie să existe doar pe hârtie, ci trebuie să o puteți testa și îmbunătăți prin ajustări succesive. Vă putem îndruma să faceți alegerile corecte, contactaţi-ne!