Problem ze strategią backup w firmie

Wypisz systemy, bez których firma staje, czyli zwykle pocztę, system sprzedaży albo produkcji, pliki działów i księgowość. Przy każdym dopisz, ile godzin przestoju wytrzyma biznes i z ilu godzin pracy da się zrezygnować, przy czym ustala to zarząd albo dyrektor operacyjny. Bez tych liczb każdy wynik pomiaru będzie wyglądał tak samo dobrze. Listę uznajesz za gotową, kiedy przy każdym systemie stoją liczby i nazwisko osoby, która je zaakceptowała.

Zestaw listę systemów z zadaniami w konsoli backupu i wyłap pozycje, które zostały bez zadania, czyli maszyny dodane po wdrożeniu, udziały sieciowe, dane w chmurze i bazy utrzymywane przez dostawcę aplikacji. Przy każdej dopisz, gdzie fizycznie leży kopia i z jakiego konta jest dostępna, bo to przesądza, co przetrwa pożar i co przetrwa ransomware. Robotę kończysz, kiedy dla każdego systemu z listy wskazujesz konkretne zadanie i konkretne repozytorium.

Odtwarzanie na środowisko produkcyjne kończy się zwykle drugą awarią, bo odtworzony serwer wchodzi w konflikt z oryginałem, przejmuje jego adres albo nazwę i myli użytkowników. Potrzebujesz odciętej sieci, wolnego hosta i przestrzeni dyskowej, a jeśli zapasu nie ma, to jest pierwszy wynik testu i temat na rozmowę o rozbudowie. Ten krok masz za sobą, kiedy możesz uruchomić odtworzoną maszynę bez wpływu na pracę użytkowników.

Weź jeden system z listy i postaw go od zera razem z systemem operacyjnym i aplikacją. Pomiar zaczynasz w chwili decyzji o odtwarzaniu, a kończysz, kiedy ktoś spoza IT zaloguje się i wykona typową operację, przy czym po drodze notujesz każdą czynność, której nie było w planie, bo to ona wydłuża odtwarzanie przy awarii. Wynikiem kroku jest zapisany czas od decyzji do pierwszego poprawnego logowania użytkownika.

Po uruchomieniu maszyny o danych nie wiadomo jeszcze nic. Poproś osobę, która pracuje w nim na co dzień, żeby odnalazła ostatni dokument sprzed kopii, otworzyła załączniki, sprawdziła uprawnienia i powiązanie z sąsiednim systemem. Takie sprawdzenie wyłapuje niespójności, których nie widać z poziomu konsoli backupu. Krok zamyka pisemne potwierdzenie od tej osoby, że na odtworzonych danych da się pracować.

Zamień notatki w procedurę, w której stoi kolejność uruchamiania systemów, adresy repozytoriów, konta i dostęp do nich oraz kontakty do dostawców aplikacji. Zmierzony czas i punkt powrotu zestaw z liczbami z pierwszego kroku, bo z różnicy między nimi wychodzi lista rzeczy do zmiany i podstawa do rozmowy o budżecie. Procedura musi leżeć poza odtwarzanym środowiskiem, na przykład w wersji papierowej albo u dostawcy, i dopiero wtedy krok jest gotowy.

Środowisko się zmienia, więc wynik jednego testu z czasem przestaje opisywać rzeczywistość. Ustal, jak często i który system sprawdzacie oraz kto odpowiada za wykonanie i za zapis wyniku, a osobno wypisz zdarzenia, po których test robi się poza kolejnością, czyli migrację systemu, zmianę dostawcy IT, nową lokalizację i nową aplikację krytyczną. Na koniec najbliższy test powinien mieć datę, właściciela i miejsce, gdzie ląduje protokół.

Raport o stanie kopii zapasowych trafia cyklicznie do osoby odpowiedzialnej za ciągłość działania, a nie tylko do administratora. Zawiera cztery informacje: procent zadań zakończonych powodzeniem, listę zasobów bez ochrony, datę i wynik ostatniego testu odtworzeniowego oraz zmierzony czas przywrócenia. To jedyny sposób, żeby przerwa w wykonywaniu kopii została zauważona poza zespołem technicznym, zanim stanie się problemem.