Proxmox Backup Server: kopia offsite i retencja

Druga kopia w innej lokalizacji chroni przed awarią serwerowni. To, ile historii uda się z niej odzyskać, zależy jednak od trzech rzeczy: ustawień synchronizacji, retencji i uprawnień. Poniżej pokazujemy, gdzie je sprawdzić w Proxmox Backup Server, i proponujemy kartę odbioru do własnego wdrożenia. Opis dotyczy Proxmox Backup Server 4.x (dokumentacja 4.2, sprawdzona w październiku 2026); w starszych wersjach opcje mogą się różnić. Jeśli dopiero zaczynasz z Proxmox Backup Server, najpierw zajrzyj do artykułu o backupie maszyn wirtualnych w Proxmox Backup Server.

Od jakiego zdarzenia ma chronić druga kopia?

Zacznij od jednego scenariusza: podstawowa serwerownia jest niedostępna, a firma musi odzyskać dane. Potrzebna jest wtedy nie tylko kopia poza tą lokalizacją, ale też droga do jej odczytania. Jeśli logowanie do drugiego serwera zależy od sieci, domeny albo komputera administratora, które właśnie nie działają, odtwarzanie utknie, zanim się zacznie.

Drugi scenariusz to błąd operatora albo przejęte konto. Jeżeli jedna osoba lub jedno zadanie automatyzacji może skasować historię w obu miejscach, odległość między serwerami niczego nie zmienia. Dlatego narysuj nie tylko przepływ danych, ale i dostęp: kto zarządza źródłem, kto celem i gdzie leżą dane dostępowe.

Offsite to kopia poza podstawową lokalizacją, a offline to kopia odłączona od bieżącego dostępu sieciowego. To dwie różne rzeczy: drugi serwer Proxmox Backup Server, który stale jest osiągalny przez sieć, jest offsite, ale nie offline.

CISA w poradniku #StopRansomware zaleca zaszyfrowane kopie offline i regularne próby odzyskiwania. W Proxmox Backup Server taką warstwę można zbudować na taśmach (system ma wbudowaną obsługę taśm), ale offline staje się ona dopiero wtedy, gdy nośnik fizycznie jest odłączony.

Czy synchronizacja zachowa kopię po usunięciu źródła?

Zależy to od opcji remove-vanished w zadaniu synchronizacji (panel datastore, zakładka Sync Jobs). Domyślnie jest wyłączona i działa w obu kierunkach synchronizacji. Po włączeniu zadanie usuwa w celu to, co zniknęło ze źródła, także snapshoty skasowane tam przez prune. Z włączoną opcją historia w drugiej lokalizacji nie może być więc dłuższa niż na serwerze głównym.

Uważaj na zakres. Przy remove-vanished lokalne grupy pasujące do filtra oraz namespace'y z zakresu zadania, których nie ma na źródle, również zostaną usunięte. Datastore docelowy najlepiej zostawić wyłącznie dla synchronizacji.

Jeśli druga lokalizacja ma trzymać dłuższą historię niż serwer główny, zostaw remove-vanished wyłączone, a retencję ustaw osobnym zadaniem prune na serwerze docelowym. Użytkownikowi lub tokenowi synchronizacji nie nadawaj wtedy uprawnienia Datastore.Prune. Dokumentacja wymaga go w zadaniu pull przy remove-vanished (w push analogiczne prawo dotyczy konta używanego na serwerze docelowym), a w części o ochronie przed ransomware Proxmox zaleca ograniczać konto synchronizacji do zapisu, bez prawa kasowania.

Ma znaczenie także kierunek zadania: pull (cel pobiera dane ze źródła) lub push (źródło wysyła je na cel). Przy pull dane dostępowe do źródła przechowuje drugi serwer. Przy push to serwer główny zna dostęp do drugiego, więc jego przejęcie może ujawnić drogę do kopii, w granicach uprawnień użytego tokena.

Sprawdź też zakres zadania: datastore, namespace i filtry grup. Wynik „TASK OK” mówi tylko, że zadanie wykonało swoją pracę, a nie że objęło wszystkie potrzebne dane. Porównaj listę chronionych usług z grupami widocznymi w Content celu i datami ich ostatnich kopii.

Wynik warto zapisać w prostym rejestrze: usługa, grupa backupu, źródło, cel, okres przechowywania i osoba odpowiedzialna. Gdy pojawi się nowa maszyna, od razu widać, czy ma trafić do drugiej lokalizacji.

Retencja w drugiej lokalizacji potrzebuje własnego uzasadnienia

Proxmox Backup Server oddziela wybór snapshotów do zachowania (prune) od odzyskiwania miejsca (garbage collection). Reguła keep-last liczy kopie, a keep-daily zachowuje po jednej kopii z każdego dnia, w którym backup faktycznie powstał. Dlatego keep-daily 30 oznacza 30 dni z backupem, a nie 30 ostatnich dni kalendarzowych.

O długości historii porozmawiaj z właścicielem danych. Innego zakresu potrzebuje odtworzenie po awarii wykrytej od razu, a innego powrót do dokumentu, którego błędną zmianę zauważono po miesiącu. Zapisz najstarszy potrzebny punkt i częstotliwość punktów między nim a dniem dzisiejszym.

W docelowym datastore otwórz listę kopii danej grupy i porównaj jej znaczniki czasu z tym wymaganiem. Przerwa między dwoma kolejnymi punktami jest brakiem, nawet jeśli łączna liczba snapshotów wygląda prawidłowo. Sprawdź też zadania prune działające na tym samym zakresie, bo drugie z nich może stosować inną politykę.

Po zmianie retencji nie licz na natychmiast wolne miejsce. Prune usuwa snapshoty, ale chunki zwalnia dopiero garbage collection, i to z opóźnieniem: usuwa tylko chunki nieużywane od co najmniej 24 godzin i 5 minut. Decyzję o rozbudowie magazynu oprzyj na trendzie zajętości z kilku cykli backupu i na rzeczywistym przyroście danych. Trend najłatwiej śledzić w monitoringu; jak ustawić go w Zabbixie, opisujemy w artykule o monitoringu wolnego miejsca na dysku.

Kto może zmienić lub usunąć historię?

Rozdziel konta automatyzacji od kont administracyjnych. Uprawnienia znajdziesz w interfejsie w Configuration → Access Control → Permissions. Ustawia się je na ścieżkach, na przykład /datastore/nazwa lub konkretnym namespace, i domyślnie dziedziczą w dół drzewa.

Token API ma własne wpisy ACL, a ich wynik jest ograniczany do uprawnień jego użytkownika. Token nigdy nie zrobi więcej niż użytkownik, ale bez własnego wpisu nie zrobi nic. Do kasowania historii służy Datastore.Prune (wymaga też własności kopii), a Datastore.Modify daje szersze prawo do zmian w zawartości datastore, więc traktuj go równie ostrożnie. Konto, które ma tylko tworzyć kopie, potrzebuje Datastore.Backup.

Zamiast czytać wpisy ACL, wylicz uprawnienia efektywne konta lub tokena. Na serwerze Proxmox Backup Server, jako root:

proxmox-backup-manager user permissions 'sync@pbs!offsite' --path /datastore/offsite

Zrób to dla docelowego namespace i ścieżek nadrzędnych. Sama nazwa konta „backup” niczego nie dowodzi.

Kryterium odbioru jest proste: konto synchronizacji może zapisywać w celu i nie może kasować, a każde konto z prawem kasowania ma właściciela i zapisane uzasadnienie. Zanim zabierzesz cokolwiek produkcyjnej automatyzacji, odtwórz jej działanie na zasobie testowym i sprawdź log.

Dostęp awaryjny opisz tak, aby druga upoważniona osoba mogła go uruchomić bez pomocy niedostępnego administratora. Procedura powinna wskazywać, gdzie leżą dane dostępowe i klucze, ale nie zawierać samych sekretów. Jeśli kopie są szyfrowane po stronie klienta, klucz musi być przechowywany poza podstawową lokalizacją, bo bez niego druga kopia jest bezużyteczna.

Karta odbioru kopii offsite

Poniższa karta to propozycja, którą trzeba dostosować do środowiska. Próby wykonuj w osobnym namespace z danymi testowymi i osobnym zadaniem synchronizacji, żeby nie dotknąć produkcyjnych kopii.

1. Zakres kopii

Porównaj listę chronionych usług i ich grup backupu z Content w celu po zakończonej synchronizacji. Zaliczone, gdy każda wymagana grupa jest obecna i ma oczekiwany punkt.

2. Zachowanie historii

Przygotuj grupę testową z trzema oznaczonymi punktami i zapisz, co według przyjętej polityki powinno zostać w celu. Po zatwierdzeniu scenariusza usuń jeden punkt w testowym źródle, uruchom testową synchronizację i porównaj zawartość celu przed próbą i po niej. Zaliczone, gdy wynik zgadza się z polityką.

3. Dostęp

Wylicz uprawnienia efektywne kont i tokenów użytych w zadaniach, na obu serwerach, i porównaj je z wymaganym zakresem. Następnie wykonaj próbę operacji dozwolonej i niedozwolonej na zasobie testowym. Zaliczone, gdy dozwolona działa, niedozwolona zostaje odrzucona, a każde konto z prawem kasowania ma właściciela.

4. Wiek dostępnego punktu

Odczytaj w Content celu czas backupu najnowszego użytecznego snapshotu i odejmij go od bieżącego czasu. Zaliczone, gdy wynik w godzinach mieści się w przyjętym limicie.

5. Integralność

Uruchom weryfikację (verify) snapshotów w celu albo sprawdź wynik zaplanowanego zadania weryfikacji. Zaliczone, gdy dla badanych grup kończy się bez błędów.

6. Odzyskanie danych

Odtwórz wybraną próbkę o znanej zawartości z celu, w izolowanym środowisku. Otwórz pliki lub wykonaj uzgodnioną operację aplikacji. Zaliczone, gdy wynik odpowiada próbce, a dostęp nie wymaga sprawnej podstawowej lokalizacji. Zapisz, które zależności tylko zasymulowano. Przebieg takiego testu krok po kroku opisujemy w osobnym poradniku o teście odtwarzania.

Ile danych pozostaje poza drugą lokalizacją?

Załóżmy, że kontrola odbywa się o 12:00, a najnowszy użyteczny punkt w drugiej lokalizacji odzwierciedla stan danych z 08:00. Jego wiek wynosi cztery godziny. Jeśli firma przyjęła RPO (dopuszczalną utratę danych) równe dwóm godzinom, wynik wymaga poprawy, nawet gdy ostatnie zadanie synchronizacji zakończyło się bez błędu. Metodę liczenia RPO i RTO na przykładzie opisujemy w artykule o teście odtwarzania usług w Proxmox Backup Server.

Liczy się czas stanu danych, a nie koniec transmisji: synchronizacja zakończona o 12:05 może przenosić snapshot z 08:00. Dla aplikacji, które wymagają spójności, czas snapshotu to dopiero punkt wyjścia i warto potwierdzić go w logach samej aplikacji. Obie godziny zapisz w tej samej strefie czasowej.

Jeden pomiar pokazuje jeden moment. Powtórz go w zwykłym cyklu pracy oraz po celowej przerwie w łączu, żeby zobaczyć, jak szybko druga kopia nadrabia zaległości.

Krótka i długa historia to dwie osobne decyzje

W opisanym przez nas wdrożeniu dla Proacta S.A. dedykowaną instancję Proxmox Backup Server połączono z archiwizacją na taśmach na potrzeby długoterminowej retencji (opis projektu). Ten przykład nie dotyczy drugiej lokalizacji, ale pokazuje podział, który warto przyjąć także przy offsite: bieżące kopie na Proxmox Backup Server, a długa historia w osobnej warstwie.

Własne rozwiązanie zacznij od trzech ustaleń: jak często powstają kopie, jak długo mają być przechowywane i kto musi mieć dostęp przy odtwarzaniu. Dopiero potem dobieraj magazyn i pojemność. Zakres prac infrastrukturalnych opisujemy w ofercie usług.

Najczęściej zadawane pytania

Czy oznaczenie „protected” przechodzi razem z synchronizowaną kopią?

Nie. Oznaczenie protected ze źródła nie jest przenoszone podczas synchronizacji. Chroni ono snapshot przed usunięciem, więc jeśli konkretny punkt ma być chroniony w celu, ustaw je tam osobno i uwzględnij to w polityce retencji.

Czy jednorazowy test odczytu pliku wystarczy przy backupie aplikacji?

Taki test potwierdza tylko odczyt tej próbki. Dla aplikacji dodaj operację odbiorową, na przykład otwarcie wskazanego dokumentu w odtworzonym systemie, i zapisz wynik oraz użyty punkt. Wynik dotyczy wyłącznie usług, które faktycznie sprawdzono.

Dokumentacja i źródła

Ustalmy zakres drugiej kopii

Chcesz przygotować kopię poza podstawową lokalizacją? Opisz, jakie dane mają być chronione i jak długo potrzebujesz ich historii — porozmawiamy o zakresie prac.

Porozmawiaj o backupie