Proxmox VE stał się hiperwizorem pierwszego wyboru dla zespołów IT korzystających z ekonomicznej wirtualizacji — a jego wdrażanie znacznie przyspieszyło po tym, jak zmiany w licencjach VMware wprowadzone przez Broadcom skłoniły organizacje do poszukiwania alternatyw. Na całym świecie wdrożono ponad 1.5 miliona hostów Proxmox, a liczba ta stale rośnie.
Aby zobaczyć, jak to działa w praktyce, możesz dowiedzieć się, jak krok po kroku wykonać kopię zapasową maszyn wirtualnych Proxmox.
Uruchamianie Proxmox w środowisku produkcyjnym i ochrona tego, co na nim działa, to dwa różne problemy. Proxmox Backup Server (PBS) dobrze radzi sobie z podstawowymi zadaniami w małych środowiskach jednoklastrowych. Gdy infrastruktura się rozrośnie – wiele klastrów, mieszane hiperwizory, wymagania dotyczące pamięci masowej w chmurze, obowiązki związane z przestrzeganiem przepisów – luki w natywnym PBS stają się ryzykiem operacyjnym.
W tym przewodniku opisano sposób działania serwera kopii zapasowych Proxmox Backup Server, jego najlepsze wyniki, momenty, w których osiąga on ograniczenia w skali przedsiębiorstwa, a także kwestie, które zespoły IT muszą wziąć pod uwagę przy wyborze strategii tworzenia kopii zapasowych odpowiadającej ich rzeczywistemu środowisku.
Czym jest Proxmox Backup Server?
Proxmox Backup Server to rozwiązanie do tworzenia kopii zapasowych o otwartym kodzie źródłowym, opracowane specjalnie jako uzupełnienie Proxmox VE.
Tworzy kopie zapasowe maszyn wirtualnych i kontenerów działających na hostach Proxmox z wyjątkową wydajnością, wykorzystując przyrostowe podejście oparte na fragmentach, które skraca czas tworzenia kopii zapasowych i ogranicza zużycie pamięci masowej w małych i średnich środowiskach. PBS oferuje wbudowaną deduplikację w magazynie danych, szyfrowanie AES-256 po stronie klienta, podstawowe zarządzanie polityką retencji oraz przejrzysty interfejs webowy do monitorowania zadań tworzenia kopii zapasowych. Dla zespołów korzystających z kilku węzłów Proxmox w pamięci lokalnej lub NFS, PBS stanowi solidny i ekonomiczny punkt wyjścia.
Pytanie nie dotyczy tego, czy PBS jest dobry w tym, co robi, lecz tego, czy to, co robi, jest wystarczające dla twojego środowiska.
Jak działa serwer kopii zapasowych Proxmox
Architektura kopii zapasowych
PBS działa jako oddzielny serwer (lub maszyna wirtualna), z którym węzły Proxmox VE łączą się jako docelowy serwer pamięci masowej. Kopie zapasowe korzystają z narzędzia vzdump wbudowanego w Proxmox VE, które tworzy migawki maszyn wirtualnych i kontenerów LXC i przesyła je strumieniowo do PBS.
- Przechowywanie danych w blokach: dane są dzielone na fragmenty o zmiennej wielkości, poddawane deduplikacji w magazynie danych i przechowywane z weryfikacją integralności SHA-256.
- Przyrostowe kopie zapasowe: Po wykonaniu początkowej pełnej kopii zapasowej przenoszone są tylko zmienione fragmenty, co zmniejsza obciążenie sieci i skraca czas trwania okna tworzenia kopii zapasowej.
- Szyfrowanie: AES-256 z zarządzaniem kluczami po stronie klienta. Dane są szyfrowane przed opuszczeniem hosta Proxmox.
- Przycinanie i przechowywanie: Konfigurowalne harmonogramy kontrolują liczbę dziennych, tygodniowych i miesięcznych kopii zapasowych przechowywanych na maszynę wirtualną lub kontener.
Obsługa pamięci masowej
PBS przechowuje dane kopii zapasowych w magazynach danych – katalogach na dysku lokalnym, instalacjach NFS lub udziałach CIFS. Każdy magazyn danych zarządza własnym magazynem fragmentów, indeksem deduplikacji i katalogiem. PBS nie obsługuje natywnie dostawców pamięci masowej w chmurze, takich jak AWS S3, Azure, Google Cloud czy Wasabi. Tworzenie kopii zapasowych w warstwie chmury za pomocą PBS wymaga ręcznej konfiguracji zewnętrznych narzędzi do synchronizacji poza interfejsem PBS.
Jeśli konfigurujesz pamięć masową, oto szczegółowy przewodnik dotyczący konfigurowania magazynów danych kopii zapasowych Proxmox przy użyciu protokołów NFS, SMB i ZFS.
Możliwości odzyskiwania
PBS obsługuje pełne przywracanie maszyn wirtualnych bezpośrednio przez interfejs Proxmox VE, przywracanie na poziomie plików za pomocą montowania FUSE oraz odzyskiwanie do określonego punktu w czasie z zachowanych migawek. Odzyskiwanie jest niezawodne w środowisku pojedynczego klastra. Odzyskiwanie między lokalizacjami lub między hiperwizorami nie jest natywnie obsługiwane.
Gdzie PBS sprawdza się dobrze
PBS oferuje rzeczywistą wartość w środowiskach, dla których został zaprojektowany:
- Pojedynczy klaster Proxmox z pamięcią masową lokalną lub podłączoną przez NFS
- Małe i średnie zespoły zarządzające mniej niż 50 maszynami wirtualnymi
- Środowiska, w których wszystkie obciążenia są uruchamiane wyłącznie na platformie Proxmox VE
- Zespoły swobodnie radzą sobie z ręcznym zarządzaniem infrastrukturą kopii zapasowych
- Organizacje bez formalnych wymogów audytu zgodności
W tych scenariuszach PBS jest darmowy, technicznie solidny i nie wymaga dodatkowych inwestycji. Nie ma powodu, aby dodatkowo go komplikować, chyba że wymaga tego środowisko.
Gdzie PBS napotyka ograniczenia w skali przedsiębiorstwa
Ograniczenia stają się problemami operacyjnymi w przewidywalnym momencie rozwoju infrastruktury. Oto, gdzie napotykają je zespoły IT:
1. Brak obsługi wielu hiperwizorów
PBS tworzy kopie zapasowe wyłącznie obciążeń Proxmox. Jeśli Twoje środowisko obejmuje VMware , Hyper-V , serwery fizyczne lub obciążenia w chmurze działające równolegle z Proxmox — lub jeśli jesteś w trakcie migracji z VMware do Proxmox — potrzebujesz oddzielnej infrastruktury kopii zapasowych dla każdej platformy. Oznacza to oddzielne konsole, oddzielne procedury odzyskiwania i oddzielne umiejętności Twojego zespołu.
Migracje z VMware do Proxmox trwają zazwyczaj od 6 do 18 miesięcy. W tym czasie zespoły korzystają z obu hypervisorów jednocześnie. PBS tworzy lukę w zapasach dla obciążeń VMware, która wymaga równoległego rozwiązania – podwajając obciążenie administracyjne podczas i tak już złożonej migracji.
2. Brak scentralizowanego zarządzania wieloma lokalizacjami
Każda instancja PBS działa niezależnie. Zespoły IT zarządzające klastrami Proxmox w trzech centrach danych mają trzy oddzielne instancje PBS bez ujednoliconego widoku. Aby odpowiedzieć na podstawowe pytania – która lokalizacja przegapiła okno kopii zapasowej, czy zasady retencji są spójne we wszystkich lokalizacjach, jak wygląda całkowite zużycie pamięci masowej – należy zalogować się do każdej instancji osobno. To nie zapewnia skalowalności i tworzy luki w zgodności w środowiskach rozproszonych.
3. Brak natywnego warstwowania pamięci masowej w chmurze
Strategie tworzenia kopii zapasowych w przedsiębiorstwach, takie jak 3-2-1-1 (trzy kopie, dwa typy nośników, jeden poza siedzibą firmy, jeden niezmienny), wymagają automatycznego przenoszenia danych między warstwami pamięci masowej. PBS dobrze obsługuje pamięć lokalną i NFS, ale nie zapisuje natywnie danych w AWS S3 , Azure, Google Cloud ani Wasabi. Tworzenie kopii zapasowych w warstwach chmury wymaga narzędzi firm trzecich spoza PBS, co zwiększa złożoność operacyjną i ręczne procesy, które mogą prowadzić do błędów ludzkich.
4. Brak niezmiennego magazynu
Niezmienne kopie zapasowe – których danych nie mogą modyfikować ani usuwać nawet administratorzy – stanowią podstawową ochronę przed ransomware i wymóg zgodności dla regulowanych branż. PBS nie obsługuje natywnie niezmiennych pamięci masowych. Dla organizacji z sektora opieki zdrowotnej , usług finansowych i administracji publicznej jest to często przeszkoda w procesie zakupów.
5. Narzędzia zapewniające ograniczoną zgodność
Normy HIPAA, SOC 2, PCI DSS i ISO 27001 wymagają udokumentowanych zasad przechowywania danych, kompleksowych ścieżek audytu i certyfikowanych mechanizmów kontroli bezpieczeństwa. PBS zapewnia podstawowe zarządzanie przechowywaniem danych i szyfrowanie, ale brakuje mu funkcji rejestrowania audytów, raportowania zgodności i certyfikatów bezpieczeństwa, których wymagają od dostawców infrastruktury branże objęte regulacjami.
W dużej mierze wiele zespołów porównuje PBS z narzędziami korporacyjnymi — zobacz porównanie Proxmox, Veeam i Zmanda.
Rozmiar pamięci masowej Proxmox Backup Server według środowiska
Niedoszacowanie rozmiaru pamięci masowej PBS to najczęstszy błąd konfiguracyjny — zwłaszcza w środowiskach, w których liczba maszyn wirtualnych rośnie szybciej niż cykle zakupu pamięci masowej. Użyj poniższej tabeli jako punktu odniesienia:
Dane dotyczące efektywnego wykorzystania pamięci masowej Zmanda Pro zakładają deduplikację po stronie klienta i ciągłe przyrostowe kopie zapasowe — po początkowej pełnej kopii zapasowej przechwytywane są tylko zmienione bloki danych. 90-procentowa redukcja pamięci masowej jest typowa dla wdrożeń korporacyjnych, w których standardowe obrazy systemu operacyjnego są uruchamiane na maszynach wirtualnych.
W przypadku rozmiaru procesora i pamięci RAM na serwerze PBS: minimalna praktyczna specyfikacja to 4 rdzenie i 8 GB pamięci RAM dla środowisk do 20 maszyn wirtualnych. W przypadku 50 lub więcej maszyn wirtualnych z jednoczesnym tworzeniem kopii zapasowych, należy zaplanować od 8 do 16 rdzeni i od 16 do 32 GB pamięci RAM, aby zapobiec kolejkowaniu zadań.
Port domyślny: PBS używa portu 8007 do obsługi interfejsu webowego i API. Proxmox VE używa portu 8006 do obsługi własnego interfejsu zarządzania. Upewnij się, że port 8007 jest otwarty między hostami Proxmox VE a serwerem PBS.
Serwer kopii zapasowych Proxmox kontra Zmanda Pro: porównanie bezpośrednie
Dla zespołów IT oceniających, czy PBS spełnia ich wymagania, czy też uzasadnione jest zastosowanie dedykowanego rozwiązania korporacyjnego :
Punkt decyzyjny dla większości zespołów IT: PBS jest wystarczający, gdy Proxmox jest jedyną platformą, a środowisko pozostaje w obrębie jednej lokalizacji. Po dodaniu innych hypervisorów, zapotrzebowaniu na widoczność wielu lokalizacji, potrzebie kontroli na poziomie zgodności lub chęci korzystania z pamięci masowej w chmurze jako natywnego miejsca docelowego — dedykowane rozwiązanie do tworzenia kopii zapasowych dla przedsiębiorstw wypełnia luki pozostawione przez PBS.
W środowiskach produkcyjnych warto rozważyć korporacyjne rozwiązanie do tworzenia kopii zapasowych Proxmox , które obsługuje centralne zarządzanie, przechowywanie w chmurze i niezmienność.
W jaki sposób Zmanda Pro rozszerza możliwości Proxmox Backup w środowiskach korporacyjnych
Zmanda Pro traktuje Proxmox jako jedną, chronioną platformę w ujednoliconym ekosystemie kopii zapasowych, a nie jako odizolowany produkt z własnym silosem. To praktyczna różnica dla zespołów IT zarządzających infrastrukturą, która obejmuje Proxmox wraz z VMware, serwerami fizycznymi, bazami danych lub Microsoft 365.
- Kopia zapasowa maszyny wirtualnej Proxmox bez agentów
Jedna instalacja agenta na host Proxmox obejmuje wszystkie maszyny wirtualne na tym węźle. Brak agentów na maszynach wirtualnych gości oznacza brak narzutu na konserwację poszczególnych maszyn wirtualnych w miarę skalowania środowiska. Kopie zapasowe wykorzystują natywne interfejsy API Proxmox do tworzenia migawek na poziomie hosta, zapewniając spójność aplikacji. - Ujednolicona konsola dla całej infrastruktury
Ta sama konsola, która zarządza kopiami zapasowymi Proxmox, obejmuje również VMware vSphere, Microsoft Hyper-V, serwery fizyczne Windows i Linux, bazy danych (MySQL, MS SQL, Oracle, MongoDB, MariaDB) i Microsoft 365. Jeden zestaw zasad, jeden przepływ pracy odzyskiwania, jeden pulpit nawigacyjny dla statusu zadania i zużycia pamięci masowej w całym środowisku.
W przypadku organizacji w trakcie migracji z VMware do Proxmox – procesu trwającego zazwyczaj od 6 do 12 miesięcy – eliminuje to problem równoległej infrastruktury tworzenia kopii zapasowych. Obie platformy są objęte równoległą ochroną od pierwszego dnia migracji aż do ostatecznego wycofania z eksploatacji. - Zawsze przyrostowe, z redukcją pamięci masowej nawet o 90%
Po wykonaniu pełnej kopii zapasowej początkowej Zmanda Pro przechwytuje tylko zmienione bloki danych — na zawsze. Deduplikacja po stronie klienta oraz kompresja Zmniejsz zużycie pamięci masowej nawet o 90% w całej infrastrukturze. To główny powód, dla którego całkowity koszt posiadania (TCO) Zmanda Pro jest nawet o 50% niższy w porównaniu z tradycyjnymi rozwiązaniami do tworzenia kopii zapasowych dla przedsiębiorstw.
Klient z listy Fortune 50 obsługujący ponad 100 000 obciążeń, w tym bazy danych o pojemności ponad 25 TB, osiągnął ponad 80% oszczędności na kosztach licencji w porównaniu z poprzednim dostawcą rozwiązań do tworzenia kopii zapasowych. Duży operator franczyzowy w USA, posiadający ponad 2,600 lokalizacji w 44 stanach, zmniejszył zużycie pamięci masowej o 89% (stosunek 10:1), umożliwiając jednocześnie pojedynczemu operatorowi zarządzanie kopiami zapasowymi setek lokalizacji. - Natywne miejsca docelowe przechowywania danych w chmurze
Zmanda Pro zapisuje dane bezpośrednio do AWS S3, Microsoft Azure, Google Cloud Storage, Wasabi, Backblaze B2, dysku lokalnego i NAS/SAN z jednej polityki kopii zapasowych. Replikuj dane do wielu lokalizacji docelowych jednocześnie, aby zapewnić zautomatyzowaną zgodność z zasadą 3-2-1-1 bez ręcznego przenoszenia danych.
Dla organizacji analizujących koszty pamięci masowej w chmurze: Zmanda Cloud Storage (obsługiwana przez Wasabi) kosztuje 20 340 USD rocznie za 250 TB — w porównaniu do 113 052 USD w przypadku Microsoft Azure i 125 946 USD w przypadku AWS S3 przy tej samej skali. Zgodność z zasadą 3-2-1-1 można osiągnąć w mniej niż 15 minut dzięki konfiguracji dwoma kliknięciami. - Niezmienne kopie zapasowe zapewniające ochronę przed oprogramowaniem ransomware i zgodność z przepisami
Zmanda Pro obsługuje blokadę obiektów w pamięci masowej zgodnej z S3 oraz lokalnej pamięci masowej ZFS, dzięki czemu dane kopii zapasowych są niezmienne przez określony czas przechowywania. Nawet administratorzy nie mogą usuwać ani modyfikować chronionych kopii zapasowych w trakcie blokady. Spełnia to wymagania dotyczące odzyskiwania danych po ataku ransomware i spełnienie nakazy HIPAA, SOC 2, PCI DSS i ISO 27001.
Szczegółowy przewodnik po konfiguracji niezmiennej kopii zapasowej znajdziesz tutaj: Zrozumienie niezmiennych kopii zapasowych - Odzyskiwanie: cała maszyna wirtualna, na poziomie plików i w określonym punkcie czasu
Zmanda Pro obsługuje pełne przywracanie maszyn wirtualnych bezpośrednio do Proxmox lub dowolnego innego obsługiwanego hiperwizora, odzyskiwanie na poziomie plików w celu odzyskania konkretnych plików bez przywracania całej maszyny wirtualnej oraz przywracanie do określonego punktu w czasie, aby przywrócić precyzyjny stan sprzed incydentu. Większość odzyskiwań maszyn wirtualnych trwa od 15 do 60 minut.
Typowe przypadki użycia kopii zapasowej Proxmox
1. Migracja z VMware do Proxmox
Organizacje migrujące z VMware w celu obniżenia kosztów licencji potrzebują kopii zapasowych dla obu platform przez cały okres migracji, który zazwyczaj trwa od 6 do 18 miesięcy. PBS nie może objąć VMware. Zmanda Pro obejmuje jednocześnie VMware vSphere i Proxmox VE z tej samej konsoli — podczas migracji maszyn wirtualnych kopie zapasowe pozostają nieprzerwane, bez konieczności ponownego szkolenia personelu ani wdrażania nowych procedur odzyskiwania.
Pełne wskazówki dotyczące planowania migracji: Usługi migracji VMware z Zmanda
2. Wdrożenia w przedsiębiorstwach wielooddziałowych
Zespoły IT zarządzające klastrami Proxmox w wielu centrach danych lub lokalizacjach geograficznych potrzebują scentralizowanego wglądu w stan kopii zapasowych, zużycie pamięci masowej i zgodność z politykami bez konieczności logowania się do każdej instancji PBS osobno. Zmanda Pro zapewnia pojedynczą konsolę zarządzania we wszystkich lokalizacjach, ze spójnym egzekwowaniem polityk i automatyczną replikacją między lokalizacjami w celu zapewnienia redundancji geograficznej.
3. Środowiska zorientowane na zgodność
Organizacje opieki zdrowotnej korzystające z Proxmox do obsługi danych pacjentów, firmy świadczące usługi finansowe z obowiązkami PCI DSS lub SEC oraz agencje rządowe z wymogami izolacji powietrznej – wszystkie te podmioty potrzebują infrastruktury zapasowej, która zadowoli audytorów. Niezmienna pamięć masowa, dzienniki audytu, certyfikaty SOC 2 typu II i ISO 27001 oraz dostępność umowy HIPAA BAA w Zmanda Pro niwelują luki w zgodności, które PBS pozostawia otwarte.
W przypadku wymagań dotyczących opieki zdrowotnej: Chroń dane dotyczące opieki zdrowotnej i zachowaj zgodność z Zmanda Pro
4. Wdrożenia Proxmox w małych i średnich przedsiębiorstwach
Mniejsze zespoły IT, które wdrażają Proxmox ze względu na jego opłacalność, często odkrywają, że PBS wymaga więcej ręcznej administracji, niż ich zespół jest w stanie obsłużyć wraz ze wzrostem liczby maszyn wirtualnych. 15-minutowe wdrożenie, automatyczne planowanie i scentralizowane zarządzanie politykami w Zmanda Pro redukują obciążenie administracyjne bez konieczności posiadania specjalistycznej wiedzy z zakresu infrastruktury kopii zapasowych.
Zobacz przegląd naszych rozwiązań do tworzenia kopii zapasowych dla małych i średnich przedsiębiorstw: Rozwiązania do tworzenia kopii zapasowych dla małych i średnich przedsiębiorstw
Rozpoczęcie korzystania z kopii zapasowej Proxmox dla przedsiębiorstw
Jeśli rozważasz opcje tworzenia kopii zapasowych dla środowiska Proxmox, które rozrosło się poza granice przewidziane dla PBS, zacznij od tego:
- Przeprowadź audyt swojego obecnego środowiska: Ile maszyn wirtualnych i kontenerów jest uruchomionych? Jakie inne platformy istnieją oprócz Proxmox? Jakie są Twoje wymagania dotyczące RTO i RPO?
- Określ swoje wymagania dotyczące zgodności: Czy w Twojej branży wymagane są niezmienne kopie zapasowe, ślady audytu lub określone certyfikaty bezpieczeństwa?
- Określ swoją strategię magazynowania: Czy zależy Ci na środowisku lokalnym, chmurze hybrydowej czy pełnej chmurze? Czy potrzebujesz zgodności 3-2-1-1?
- Przetestuj przed zatwierdzeniem: Każde rozwiązanie do tworzenia kopii zapasowych w przedsiębiorstwie, które warto rozważyć, powinno dać się przetestować w rzeczywistej infrastrukturze. Zmanda Pro oferuje bezpłatny okres próbny, umożliwiający praktyczną ocenę we własnym środowisku.
FAQ
