Zasadnicze zadania systemu zapewniającego ciągłość biznesową (BC) to łagodzenie lub neutralizowanie skutków awarii, pozwalające na zminimalizowanie jej wpływu na działalność przedsiębiorstwa. Zazwyczaj rozwiązanie takie wykorzystuje funkcje przywracania po awarii - DR (Disaster Recovery) oraz redundantne systemy, zapewniające wysoką dostępność - HA (High Availability). Rozwiązania HA działają w czasie rzeczywistym na realnych danych w taki sposób, że gdy zostanie uszkodzony jeden z elementów, drugi przejmuje jego zadania z minimalnym lub żadnym wpływem na procesy biznesowe. Systemy HA nie chronią przed katastrofą - obniżają tylko prawdopodobieństwo rozległej awarii.

DR z kolei to zestaw procedur i polityk, które właściwie zaimplementowane pozwalają organizacji na odtworzenie danych utraconych w wyniku katastrofy lub rozległej awarii. Ile czasu zabiera takie odtworzenie i do jakiego stopnia te dane będą nieaktualne po przywróceniu, będzie zależeć od takich parametrów, jak RTO (Recovery Time Objectives) i RPO (Recovery Point Objectives), które zostały przyjęte w organizacji. Zadaniem DR nie jest zapewnienie ciągłości działania, ale odtworzenie danych w przypadku ich utraty, niedostępności lub uszkodzenia.

Przy zwiększaniu poziomu niezawodności systemów IT przedsiębiorstw ważną rolę może odgrywać wirtualizacja serwerów. Podczas wdrażania rozwiązań wirtualnych organizacje często zapominają o ich dodatkowych możliwościach, takich jak użycie środowiska wirtualnego jako platformy zapewniającej sprawny backup i odtwarzanie danych po katastrofie - często po niższych kosztach i w sposób mniej skomplikowany niż w przypadku metod tradycyjnych.

Systemy informatyczne i przechowywane w nich dane są narażone na różne zagrożenia: od infekcji złośliwym oprogramowaniem i kradzieży przez zwyczajne błędy ludzkie i awarie sprzętu/oprogramowania po katastrofy naturalne.

Wszystko zaczyna się od polityki

Można wyróżnić cztery etapy budowania strategii ciągłości działania, spójnej dla całej organizacji. Pierwszy to zdefiniowanie jej zasięgu - określenie, które aplikacje będą objęte ochroną. Drugi, to zdefiniowanie, jakie rodzaje ryzyka, zagrażające infrastrukturze, będą przedmiotem ochrony. Etap trzeci to zdefiniowanie precyzyjnych wymagań, dotyczących odtwarzania systemu dla zdefiniowanych rodzajów ryzyka. Po wykonaniu tych kroków można rozpocząć etap czwarty: określanie technicznych elementów potrzebnych do realizacji przyjętej strategii BC.

Zaczynając od aplikacji, można określić wszystko, co jest jej potrzebne do przetrwania awarii: wymaganą infrastrukturę i związane z nią dane. Jeżeli zaczyna się od infrastruktury i przechodzi do pracujących na niej aplikacji, łatwo można przeoczyć, co każda z aplikacji potrzebuje do działania.

Określenie, przed jakim ryzykiem chce się chronić dane, wymaga gruntownej wiedzy. Niezależnie jednak od tego, co się wybierze, najważniejsze, aby w podejmowaniu decyzji uczestniczył zarówno dział IT, jak i specjaliści odpowiedzialni za procesy biznesowe.