Backup 3-2-1 – Proxmox Backup Server w AZURE

Dobrą praktyką przy tworzeniu kopii zapasowych dla kluczowych danych jest „Zasada 3-2-1”. Zasada ta zaleca tworzenie 3 kopii/replik danych, z których co najmniej 2 kopie powinny być zapisane na różnych nośnikach oraz że 1 kopia powinna być przechowywana w odrębnej lokalizacji, poza miejscem przetwarzaniach danych, w innym geograficznie miejscu.

W związku z tym, że w swoim domowym laboratorium korzystam z klastra Proxmox, a dla zabezpieczania kontenerów i maszyn wirtualnych korzystam z serwera Proxmox Backup Server (dane zabezpieczane w 2 kopiach na dyskach sieciowych) zdecydowałem, że w zdalnej lokalizacji, w chmurze Azure, uruchomię zdalny Proxmox Backup Server i w ten sposób dołożę do mechanizmów zabezpieczeń tą „1” z zasady „3-2-1”.

Nie znalazłem w zasobach Azure gotowego rozwiązania, dlatego też Proxmox Backup Server jest instalowany na wirtualnej maszynie pod systemem Debian 12. Wymagane elementy są dla tego rozwiązania budowane w portalu Azure.

Wdrożenie infrastruktury

1. Utworzenie maszyny wirtualnej vm-pbs2 – Standard B2s (2 vcpus, 4 GiB memory) oraz grupy zasobów rg-pbs2
   a. System Debian 12
   b. Dodatkowy dysk HDD 128GB na kopie – vm-pbs2_DataDisk_0
   c. Zewnętrzny adres IP – vm-pbs2-ip
   d. Dostęp do SSH (port 22) przez klucze RSA – vm-pbs2_key
2. Azure utworzył automatycznie dodatkowe wymagane komponenty sieciowe: Network Security Group – vm-pbs2-nsg, Network Virtual Network – vm-pbs2-vnet oraz kartę sieciową vm-pbs2512

Przygotowanie systemu

sudo apt update

sudo apt upgrade -y

sudo apt install mc htop xfsprogs parted -y

Podłączenie dodatkowego dysku

sudo parted /dev/sdc --script mklabel gpt mkpart xfspart xfs 0% 100%

sudo mkfs.xfs /dev/sdc1

sudo partprobe /dev/sdc1

sudo mkdir /datadrive

sudo mount /dev/sdc1 /datadrive

sudo blkid

/etc/fstab - add
UUID=e2dce0f9-64b8-428f-8b36-4edec71e03b7   /datadrive   xfs   defaults,nofail   1   2

sudo https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg

/etc/apt/sources.list - add
deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription

sudo apt update
sudo apt install proxmox-backup-server

Wymagane było przywrócenie pakietu ifupdown. Pakiet ifupdown2 sygnalizował błąd.

sudo apt install ifupdown

W opcjach sieciowych wymagane było dodanie reguły dla ruchu przychodzącego, odblokowującej ruch port TCP 8007.

Konfiguracja Proxmox Backup Server

Zainstalowane oprogramowanie dostępne jest pod adresem:

https://4.180.157.247:8007

W ramach interfejsu WEB:

1. Dodano 2 magazyny danych – Datastore: azure_backup i azure_backup2 (dla backupów szyfrowanych).
2. Ustawiono harmonogram dla zadań weryfikujących kopie – Verify Jobs
3. Ustawiono harmonogram dla zadań porządkujących magazyny danych – Prune Jobs, Garbage Collect Jobs

Konfiguracja kopii w Proxmox

1. Dodano w sekcji Storage połączenie do zdalnego serwera Proxmox Backup Server – dwa rodzaje azure_pbs i azure_pbs2 (dla kopii szyfrowanych).
2. Ustawiono harmonogramy wykonywania kopii dla kontenerów i wirtualnych maszyn.
3. Uruchomiono testowy backup

Problemy napotkane podczas wdrożenia rozwiązania w Azure

1. Po „sudo apt upgrade” z włączonym repozytorium Proxmox Backup Server niestety system już się nie uruchamiał – problem z bootowaniem i konfiguracją grub.
2. Udało się uruchomić system w wykorzystaniem Serial console i Grub Rescue mode

grub>

ls

ls (hd0,gpt1)/

set prefix=(hd0,gpt1)/boot/grup

set root=(hd0,gpt1)

insmod normal

normal

3. Niestety kolejne polecenia, które powinny przywrócić poprawne ładowanie systemu nie odniosły oczekiwanego rezultatu. System ponownie nie był w stanie się zbootować.

sudo update-grub

lsblk

sudo install-grub /dev/sdb

sudo reboot

4. Ostatecznie instalacja została powtórzona bez upgradu pakietów z repozytorium Proxmox Backup Server

azureuser@vm-pbs2:~$ sudo apt list --upgradable

grub-common/stable 2.06-13+pmx2 amd64 [upgradable from: 2.06-13+deb12u1]

grub-efi-amd64-bin/stable 2.06-13+pmx2 amd64 [upgradable from: 2.06-13+deb12u1]

grub-efi-amd64-signed/stable 1+2.06+13+pmx2 amd64 [upgradable from: 1+2.06+13+deb12u1]

grub-pc-bin/stable 2.06-13+pmx2 amd64 [upgradable from: 2.06-13+deb12u1]

grub2-common/stable 2.06-13+pmx2 amd64 [upgradable from: 2.06-13+deb12u1]

shim-helpers-amd64-signed/stable 1+15.8+1+pmx1 amd64 [upgradable from: 1+15.7+1]

shim-signed-common/stable 1.39+pmx1+15.7-1+pmx1 all [upgradable from: 1.39+15.7-1]

shim-signed/stable 1.39+pmx1+15.7-1+pmx1 amd64 [upgradable from: 1.39+15.7-1]

shim-unsigned/stable 15.8-1+pmx1 amd64 [upgradable from: 15.7-1]

Przypuszczam, że występuje tu jakaś niezgodność pomiędzy środowiskiem Azure i tymi w/w pakietami.

Przy rozpoznawaniu tego problemu, zauważyłem także, że na tej instalacji występuje dziwne zjawisko zamieniania, przy każdym restarcie (reboot wm-pbs2), kolejności dysków sda, sdb i sdc.

Wydajność

Opisane rozwiązanie bardzo sprawnie działa na wybranym rozmiarze serwera Standard B2s (2 vcpus, 4 GiB memory). Producent oprogramowania zaleca minimum 2 cores i 2GB RAM.

Ograniczeniem, które było widoczne to parametry łącza internetowego, które mam w domu: 600Mb/30Mb. Przy tworzeniu kopii, całość dostępnego łącza była wykorzystana. Tylko początkowe kopie realizowały się na zdalny serwer odpowiednio długo, w zależności od rozmiarów. Cały backup trwał kilka godzin. Dzięki funkcji kopii inkrementalnej i deduplikacji czasy realizacji kolejnych backupów są znacząco mniejsze. Pełna kopia przyrostowa wszystkich zasobów Proxmox trwa ok. 30 minut.

Optymalizacja kosztowa

Aby zredukować koszty utrzymania infrastruktury w Azure zgodnie z potrzebami i harmonogramami wykonywanych kopii, serwer vm-pbs2 jest automatycznie włączany i wyłączany (deallocate). Do realizacji tej funkcjonalności wykorzystałem komponenty Azure Logic App. vm-pbs2 automatycznie się włącza codziennie o 3:45, a o 7:45 gdy wszystkie zaplanowane prace są wykonane, Azure dealokuje zasoby vm-pbs2. Sam stop maszyny wirtualnej nie wystarcza, bo dalej zasoby są zarezerwowane. Dopiero funkcja deallocate vm oddaje zasoby (pamięć i moc procesora) do innego wykorzystania w chmurze. W tym przypadku uzyskuje się znaczne zmniejszenie kosztów ponoszonych na wirtualną maszynę. Dla zasobów, które są cały czas przydzielone, takich jak dyski czy adres IP Azure nalicza pełne opłaty.

Poniższy ekran prezentuje koszty ponoszone na wszystkie zasoby w grupie rg-pbs2. Widać obniżenie kosztów naliczanych za vm-pbs2 od momentu uruchomienia automatycznej, codziennej dealokacji. Koszty spadły zgodnie z oczekiwaniem, proporcjonalnie do czasu użycia maszyny wirtualnej (4h na dzień) z 1,08 Euro do 0,18 Euro.

Podział kosztów na zasoby dla tej usługi wygląda następująco:

1. Stały adres IP                         0,11 Euro / dzień
2. Dysk systemowy                    0,18 Euro / dzień
3. Dysk HDD na dane                0,18 Euro / dzień
4. 4h maszyny wirtualnej           0,18 Euro / dzień

Razem                                    0,65 Euro / dzień

 Koszt korzystania z usługi, wynosi około 20 Euro miesięcznie.

Schemat komponentów Azure

Poniżej przedstawiony jest schemat komponentów architektury Azure wykorzystanych do zabezpieczania danych klastra Proxmox w zdalnej lokalizacji.