Po awarii serwera firma potrzebuje dostępu do aplikacji, dokumentów i bieżącej pracy. Raport z nocnego backupu jest ważny, ale dopiero próba odtworzenia pokazuje, czy dostępne są również klucze, potrzebne zasoby i procedura uruchomienia usługi. W środowisku Proxmox Virtual Environment z Proxmox Backup Server warto sprawdzić cały ten ciąg.
Co firma ma odzyskać po awarii?
Zacznij od jednej konkretnej usługi: systemu sprzedażowego, plików działu projektowego albo aplikacji księgowej. Ustal z jej właścicielem, po czym pozna, że może wrócić do pracy. Sam ekran logowania to za mało, jeśli użytkownik nie otworzy dokumentu lub nie wykona podstawowej operacji.
Uzgodnij RPO, czyli dopuszczalne okno utraty danych wyrażone w minutach lub godzinach, oraz RTO — docelowy czas przywrócenia usługi po przerwaniu jej działania. Wpisz oba cele do planu przed próbą. Sposób porównania ich z wynikiem opisujemy poniżej.
Dla przykładowego systemu zamówień kryterium może obejmować odczyt wskazanego zamówienia i zapis rekordu testowego w odizolowanej kopii. Właściciel aplikacji powinien podać oczekiwaną zawartość i rezultat operacji. To przykład do dostosowania, nie opis wdrożenia Symbit.
Integralność kopii i sprawna aplikacja
Proxmox Backup Server sprawdza integralność przechowywanych danych za pomocą verify. W zakładce Content wybranego datastore odszukaj snapshot i odczytaj jego wynik oraz datę weryfikacji. W razie potrzeby uruchom sprawdzenie ikoną V w kolumnie Actions i po zakończeniu przeczytaj log zadania. Błąd wymaga wyjaśnienia przed uznaniem tej kopii za podstawę odtwarzania.
W próbie uwzględnij logowanie użytkownika, dostęp do reprezentatywnych danych i podstawowe działanie aplikacji. Jeżeli potrzebuje ona bazy, serwera nazw lub usługi katalogowej, wpisz te zależności do planu. Właściciel aplikacji powinien wskazać operację, która będzie kryterium powodzenia.
W Verify Jobs skontroluj ustawienia pomijania wcześniej zweryfikowanych snapshotów i okres ponownego sprawdzania. Porównaj je z datą wyniku wybranej kopii: ostatnie uruchomienie zadania mogło jej nie obejmować. Verify nie uruchamia aplikacji ani nie sprawdza jej operacji biznesowych.
Czy odzyskasz dane bez podstawowego serwera?
Kopia poza główną lokalizacją pomaga przygotować się na szerszą awarię. W Proxmox Backup Server służy temu m.in. synchronizacja z inną instancją. Na serwerze docelowym otwórz Content właściwego datastore i namespace, a następnie porównaj grupę oraz czas snapshotu z planem próby. Użyj konta przewidzianego do awaryjnego odtwarzania, aby potwierdzić także jego dostęp.
Jeżeli kopii brakuje, przejrzyj log synchronizacji oraz jej group-filter, zakres namespace i uprawnienia konta. Przy verified-only nowsza, jeszcze niezweryfikowana kopia może zostać pominięta. Odczytaj też ustawienie remove-vanished: może usuwać z celu elementy znikające ze źródła w zakresie zadania. Flaga ochrony snapshotu nie jest synchronizowana; jej stan obejrzyj osobno na celu.
Zdalny serwer stale dostępny przez sieć nadal wymaga ochrony dostępu. W strategii odporności na ransomware uwzględnij kopię offline oraz kopię niedostępną dla zwykłych kont produkcyjnych. Zasada 3-2-1 porządkuje liczbę kopii, rodzaje nośników i lokalizacje. Podczas próby skorzystaj z repozytorium przewidzianego na utratę podstawowego serwera, zamiast sięgać do wygodniejszej kopii lokalnej.
Klucze i instrukcja muszą być dostępne podczas awarii
Przy szyfrowanych kopiach potrzebny jest właściwy klucz i, jeśli go zabezpieczono hasłem, możliwość jego odblokowania. Przechowuj materiał odzyskiwania w kontrolowanym miejscu dostępnym także wtedy, gdy podstawowe środowisko nie działa. Dostęp do niego powinny mieć wyłącznie upoważnione osoby.
Poproś drugą uprawnioną osobę, aby z awaryjnego stanowiska i według instrukcji odszukała repozytorium, wybrała kopię oraz wykonała jej odtworzenie do środowiska testowego. Niech pobierze i odblokuje klucz z miejsca przeznaczonego na sytuację awaryjną, zamiast używać danych zapisanych na podstawowym hoście. Odczyt odzyskanych danych potwierdzi użycie właściwego klucza. Do raportu wpisz wynik i brakujące kroki instrukcji, bez haseł i materiału kluczowego.
Przed większą aktualizacją Proxmox Backup Server zabezpiecz także konfigurację serwera. Instrukcja aktualizacji producenta wskazuje katalog /etc/proxmox-backup. Zachowaj jego kopię w kontrolowanym miejscu poza aktualizowanym serwerem; po skopiowaniu otwórz archiwum i porównaj listę plików ze źródłem.
Próba, która nie zakłóci produkcji
Odtwórz wybraną maszynę pod innym identyfikatorem, na magazynie testowym, z automatycznym uruchomieniem wyłączonym. Przed startem przejrzyj wszystkie karty sieciowe i przypisane mosty; połącz je wyłącznie z wydzieloną siecią testową. Zablokuj na jej granicy ruch do produkcji i internetu, a dopuszczaj tylko uzgodnione zależności. Dzięki temu można uruchomić kopię, wyłączyć w niej zadania wysyłające wiadomości lub integracje finansowe i dopiero potem wykonywać operacje odbiorowe.
Przed dopuszczeniem połączeń sprawdź na testowej maszynie wynik rozwiązywania nazw zależności i porównaj adresy z planem sieci. Podczas operacji odbiorowej przejrzyj log blokad na zaporze oraz log aplikacji: pokażą próby połączeń z pominiętym systemem. Jeśli bazy, DNS lub usługi katalogowej nie odtworzono, oznacz tę zależność jako poza zakresem testu. Odzyskanie pojedynczego pliku jest przydatne, ale nie potwierdza scenariusza utraty hosta.
Co zapisać w wyniku próby
Zapisz identyfikator kopii, datastore i namespace, badaną usługę, warunki próby oraz dowody odbioru. Poniższa checklista jest propozycją organizacji testu, którą można skopiować do protokołu.
- Cel i zakres: wpisz RPO i RTO z jednostkami, niedostępne elementy oraz operację wskazaną przez właściciela aplikacji.
- Kopia i dostęp: odnotuj czas snapshotu, wynik i datę verify oraz konto, z którego wykonano odtwarzanie. Zachowaj log zadania.
- Działanie: zapisz wynik odczytu danych i operacji testowej, oczekiwany rezultat, potwierdzenie właściciela oraz pominięte zależności.
- Pomiar: wpisz T0, T1, punkt odtworzenia danych i źródło jego potwierdzenia. Oblicz czas odzyskania oraz okno utraty danych według metody poniżej.
- Decyzja: oznacz wynik jako zaliczony, niezaliczony albo częściowy; przypisz usterki do osób i terminów ponownej próby.
Jak porównać wynik testu z RPO i RTO?
Dla RTO zapisz T0 — chwilę symulowanego przerwania usługi — oraz T1, gdy właściciel potwierdzi wykonanie uzgodnionej operacji w odzyskanej aplikacji. Czas odzyskania to T1 minus T0. Uwzględnij pozyskanie dostępu, transfer, uruchomienie zależności i odbiór. Czas zakończenia transferu odczytaj z logu odtwarzania jako osobny etap. Porównaj cały wynik, w tej samej jednostce, z uzgodnionym RTO. Jeśli część przygotowań wykonano przed T0, opisz ją jako ograniczenie symulacji.
Dla RPO punktem odniesienia również jest T0. Ustal, do jakiej chwili odtworzone dane są kompletne: porównaj identyfikatory i kolejność zatwierdzonych operacji w kopii z referencyjnym dziennikiem aplikacji lub transakcji zabezpieczonym na potrzeby testu. Ostatni rekord sam w sobie nie dowodzi kompletności — wcześniejsze operacje mogły zostać pominięte. Okno utraty danych oblicz jako T0 minus potwierdzony punkt odtworzenia i porównaj z RPO, np. w minutach. Używaj wspólnej strefy czasu i zsynchronizowanych zegarów.
Przykładowo, przy T0 o 10:00 i potwierdzonej kompletności danych do 9:45 okno wynosi 15 minut. Jeżeli aplikacja nie zapisywała nic od 9:30, wiek ostatniego rekordu nie oznacza automatycznie utraty 30 minut danych. Brak późniejszych zmian trzeba potwierdzić w dzienniku referencyjnym. Gdy nie ma dowodu pozwalającego ustalić kompletność, oznacz wynik RPO jako niepotwierdzony; nie wyliczaj go wyłącznie z godziny backupu. Podane godziny ilustrują metodę, nie są pomiarem Symbit.
Dodaj napotkane przeszkody i osobę odpowiedzialną za każdą poprawkę. Jeżeli brakowało hasła, reguły sieciowej lub opisu uruchomienia bazy, poprawka powinna zakończyć się ponownym sprawdzeniem tego elementu.
Nie przenoś czasu uzyskanego dla małej maszyny testowej na całe środowisko. Wynik opisuje określoną kopię, zasoby i warunki. Gdy zmienia się aplikacja, sposób przechowywania danych lub architektura sieci, warto ponownie sprawdzić odpowiadający temu scenariusz.
FAQ
Czy warto wykonać próbę także ze starszej kopii?
Tak, jeśli scenariusz obejmuje błąd lub usunięcie danych zauważone dopiero po czasie. Wybierz snapshot sprzed znanego momentu zmiany i odtwórz go w środowisku testowym. Porównaj konkretny plik lub rekord z opisem oczekiwanego stanu. Zapisz, jak daleko wstecz można sięgnąć przy obecnej retencji; próba wyłącznie z najnowszej kopii nie odpowie na to pytanie.
Co zrobić, gdy wynik RPO wychodzi niepotwierdzony?
Nie zaokrąglaj go do wieku ostatniego backupu ani nie wpisuj szacunku "na oko". Ustal, czego dokładnie brakuje do potwierdzenia kompletności — najczęściej referencyjnego dziennika aplikacji obejmującego okres wokół T0 albo dostępu do konta, które mogłoby go odczytać. Zapisz w wyniku próby, jaki dowód jest potrzebny i kto ma go dostarczyć do kolejnego testu, zamiast zamykać protokół liczbą, której nikt nie zweryfikował.
Jak często powtarzać test odtworzenia tej samej usługi?
Powtórz próbę po każdej istotnej zmianie: nowej wersji aplikacji, zmianie architektury sieci, migracji bazy albo zmianie sposobu przechowywania danych — wynik z poprzedniej konfiguracji nie potwierdza kolejnej. Niezależnie od zmian ustal też stały cykl, np. kwartalny dla usług krytycznych, żeby procedura i dostęp do materiału odzyskiwania nie zdezaktualizowały się niezauważone między awariami.
Dokumentacja i źródła
Proxmox Backup Server — weryfikacja kopii i utrzymanie.
Proxmox Backup Server — synchronizacja z drugim serwerem.
CISA — zalecenia dotyczące backupu i odtwarzania po ransomware.
Proxmox Backup Server — klucze szyfrowania i odtwarzanie.
Proxmox — przygotowanie do aktualizacji i kopia konfiguracji.
Sprawdź zakres przeglądu backupu
Chcesz ustalić, co powinien obejmować test odtwarzania w Twojej firmie? Opisz najważniejszą usługę i oczekiwany sposób powrotu do pracy — porozmawiajmy o zakresie przeglądu.
Kontakt z Symbit.