Kopia zapasowa, z której nikt nigdy nie przywracał danych, jest wyłącznie założeniem. Sprawdza się ją zwykle w dniu awarii — czyli w najgorszym możliwym momencie.
Odpowiedzi wynikają z potrzeb firmy, nie z możliwości narzędzia. Dopiero potem dobiera się rozwiązanie.
Warto zadać te pytania osobno dla każdego zbioru danych. Baza systemu sprzedażowego, dokumenty na dysku współdzielonym i konfiguracja serwera mają zwykle różne odpowiedzi i nie ma powodu, żeby obejmować je jednym schematem. Część danych da się odtworzyć z innego źródła, część nie istnieje nigdzie indziej.
Jedyny sposób, żeby wiedzieć, że kopia działa. Powinien być cykliczny i obejmować rzeczywiste przywrócenie na środowisko zapasowe, a nie samo sprawdzenie, czy plik istnieje.
Test warto prowadzić z listą kroków w ręku i mierzyć czas każdego z nich. Wynik jest podwójnie użyteczny: potwierdza, że dane da się odzyskać, i daje realny czas przestoju, który można pokazać zarządowi. Zapisany przebieg testu staje się procedurą, z której skorzysta ktoś inny w dniu awarii — najlepiej trzymać go razem z resztą dokumentacji środowiska, poza systemem, którego dotyczy.
Do tej listy dochodzą bazy systemów sprzedażowych i księgowych, które wymagają osobnego podejścia — skopiowanie pliku w trakcie pracy daje kopię uszkodzoną. Opisuje to tekst o kopiach baz danych.
Kopia leżąca obok serwera nie chroni przed pożarem, zalaniem ani zaszyfrowaniem przez złośliwe oprogramowanie. Egzemplarz w innej lokalizacji jest warunkiem, nie ulepszeniem.
Równie istotne jest oddzielenie uprawnień. Jeśli konto obsługujące serwer ma prawo kasować kopie, to atak, który przejmie to konto, obejmie również je. Miejsce docelowe tylko do zapisu albo takie, do którego serwer w ogóle nie sięga, zmienia tu więcej niż zwiększenie częstotliwości.
Brak wiadomości nie oznacza sukcesu. Zadanie powinno zgłaszać zarówno błąd, jak i to, że w ogóle się nie uruchomiło.
W praktyce oznacza to potwierdzenie po każdym wykonaniu i osobny alert, gdy potwierdzenie nie przyszło w spodziewanym oknie czasowym. Taka kontrola należy już do monitoringu, a nie do samego narzędzia kopii — i dlatego bywa pomijana przy wdrożeniu.
Jeśli firma pracuje wyłącznie na usługach w chmurze i nie trzyma danych lokalnie, budowanie własnej infrastruktury kopii zwykle nie ma sensu. Wystarczy świadomie ustawić to, co daje dostawca, i dołożyć niezależny eksport najważniejszych danych na wypadek pomyłki użytkownika. Rozbudowa staje się uzasadniona tam, gdzie stoi własny serwer albo gdzie każda godzina przestoju zatrzymuje sprzedaż.