Proxmox Backup Server — backup i test odtwarzania

W środowiskach, które przejmowaliśmy, powtarzał się ten sam obraz: zadania kopii włączone, w logach wpisy o zakończonym sukcesem, i nikt nigdy nie próbował czegokolwiek przywrócić. Kopia, której nikt nie odtworzył, jest obietnicą, a nie zabezpieczeniem.

Nieudane odtworzenia rzadko wynikają z braku kopii. Problem siedzi w szczegółach: backup obejmował tylko część danych, brakuje nośnika z obrazem instalacyjnym, przywrócenie trwa dłużej, niż firma może czekać, albo nikt nie pamięta, w jakiej kolejności uruchamiać usługi. Tego nie widać, dopóki się nie spróbuje.

Proxmox Backup Server, w skrócie PBS, to osobne narzędzie z tej samej rodziny co Proxmox VE. Instaluje się je na własnym serwerze albo maszynie wirtualnej, a jego zadanie jest jedno: przyjmować, przechowywać i przywracać kopie maszyn wirtualnych oraz danych z hosta.

Po co oddzielny serwer, skoro Proxmox VE sam potrafi zapisywać kopie? Bo kopia leżąca na tym samym hoście chroni tylko przed częścią awarii. Gdy padnie host albo ktoś usunie katalog z kopiami przez pomyłkę, ginie system i kopie jednocześnie.

PBS obsługuje również kopie z hostów spoza Proxmoxa — między innymi z fizycznych serwerów i z innych platform, co przydaje się, gdy część środowiska jeszcze nie została przeniesiona. Całość usługi opisujemy na stronie wirtualizacji serwerów.

PBS zapisuje kopie przyrostowo i usuwa powtórzenia na poziomie fragmentów danych. Druga i kolejna kopia tej samej maszyny zajmuje więc ułamek miejsca pierwszej, a nocne zadanie trwa krócej, bo przesyła tylko zmiany.

Efekt jest taki, że opłaca się trzymać kopie częściej i dłużej. Zamiast jednej kopii tygodniowo można mieć dzienną z retencją miesięczną, bez rozrastania się magazynu w tempie, którego nie da się utrzymać. To zmiana, którą klienci zauważają najszybciej — nie trzeba wybierać między częstotliwością a miejscem.

Minimum to dwa miejsca. Pierwsze blisko środowiska, żeby odtworzenie było szybkie. Drugie poza budynkiem, żeby pożar, zalanie czy kradzież nie zabrały wszystkiego naraz.

Drugie miejsce nie musi oznaczać chmury za duże pieniądze. Wystarczy serwer w innym budynku albo wydzielona przestrzeń u dostawcy. Ważne, żeby kopie nie były dostępne z tego samego konta, na którym pracuje firma — inaczej zaszyfrowanie stacji przez oprogramowanie szantażujące zabiera też kopie. To najczęstszy błąd, jaki widzimy: wszystko zabezpieczone, ale jedno hasło dzieli system i backup. O kopiach poza budynkiem i w chmurze piszemy przy okazji chmury dla firm.

Harmonogram wynika z tego, ile danych firma może stracić. Jeśli dokumenty powstają codziennie, kopia raz w tygodniu oznacza, że po awarii odtwarzasz stan sprzed kilku dni i ręcznie nadrabiasz wszystko, co powstało później.

Retencję ustawia się zwykle tak, żeby mieć dostęp do stanu z ostatnich dni, kilku tygodni i kilku miesięcy. Taki układ wystarcza zarówno do szybkiego cofnięcia błędu, jak i do znalezienia pliku, który zniknął pół roku temu i dopiero teraz okazał się potrzebny.

Warto też rozdzielić kopie od archiwum. Kopie służą do przywracania, archiwum do przechowywania dokumentów przez lata — mieszanie tych dwóch celów w jednym zadaniu kończy się magazynem, którego nikt nie kontroluje.

RPO odpowiada na pytanie, ile danych firma może stracić. RTO — jak długo może nie działać. Obie wartości ustala się z osobą decyzyjną w firmie, nie z administratorem, bo dotyczą decyzji biznesowej, a nie technicznej.

Dopiero z nich wynika, jak często robić kopie i jak szybko musi działać odtworzenie. Bez tych dwóch liczb konfiguracja jest zgadywaniem, a przy pierwszej prawdziwej awarii okazuje się, że parametry dobrano pod wygodę, nie pod potrzeby firmy.

Test robimy w ramach wdrożenia i powtarzamy, gdy zmienia się środowisko. Wygląda to tak:

• wybieramy maszynę i punkt w czasie, z którego chcemy ją odtworzyć,
• przywracamy ją na wydzielonym środowisku, żeby nie kolidowała z wersją pracującą,
• mierzymy, ile trwało przywrócenie i czy system wystartował bez ręcznych poprawek,
• sprawdzamy, czy aplikacja widzi swoje bazy i pliki oraz czy użytkownicy mogą się zalogować,
• zapisujemy wynik: co zadziałało, co wymagało korekty i ile to zajęło.

Ostatni punkt jest najważniejszy. Bez zapisanego wyniku test jest jednorazowym ćwiczeniem, a nie procedurą, do której ktoś wróci przy prawdziwej awarii. Ten sam test robimy przy migracji z VMware na Proxmox, a o składnikach wyceny pisaliśmy w artykule o koszcie wdrożenia Proxmox.

Trzy rzeczy widzimy najczęściej. Pierwsza to kopie wyłącznie na tym samym hoście. Druga — zadania, które po cichu przestały się wykonywać, bo skończyło się miejsce, a alerty nie zostały ustawione. Trzecia to brak rozdzielenia kopii od systemu, o którym pisaliśmy wyżej.

Do tego dochodzi sprzęt: jeśli magazyn kopii pracuje na jednym dysku bez zabezpieczenia, to nie jest backup, tylko drugi punkt awarii. Prosty test, który warto zrobić u siebie: sprawdź, czy potrafisz wskazać, gdzie dokładnie leży kopia sprzed tygodnia i czy ktokolwiek ją kiedykolwiek odtworzył. Jeśli nie wiesz, od czego zacząć, napisz do nas — przejrzymy obecne kopie i powiemy, co wymaga poprawy.