Jak skonfigurować VPS jako zdalny cel kopii zapasowych

Czym w rzeczywistości jest zdalny cel kopii zapasowych

Zdalny cel kopii zapasowych to druga maszyna przechowująca kopię danych, której awaria jest niezależna od serwera źródłowego. VPS u innego dostawcy jest najtańszym rozwiązaniem dostępnym dla większości użytkowników. Realne są trzy warianty: Proxmox Backup Server uruchomiony na VPS, repozytorium restic dostępne przez SSH lub S3, albo mirror rsync pobierany przez hosta kopii zapasowych. Wybór zależy od tego, co jest przywracane i jak szybko dane muszą być dostępne. O pozostałych kwestiach decyduje to, kto posiada uprawnienia do usuwania kopii.

Zdalny oznacza inną domenę awarii. Wymaga to innego dostawcy oraz konta, które nie współdzieli danych logowania z kontem zarządzającym serwerem głównym. Drugi serwer w innym regionie tego samego dostawcy przetrwa pożar w jednym budynku. Nie przetrwa jednak przejęcia loginu do panelu sterowania, ponieważ jedno konto kontroluje obie kopie.

Snapshot u dostawcy nie jest taką drugą kopią. Znajduje się on za tym samym hasłem do panelu, więc osoba, która je pozyska, usunie serwer oraz jego snapshoty w jednej sesji. Usługi snapshotów są również rozliczane za gigabajt miesięcznie według stawek znacznie wyższych niż zwykły dysk, co czyni przechowywanie ich przez dziewięćdziesiąt dni kosztownym. Warto przeczytać różnice między snapshotami VPS a kopiami zapasowymi przed poleganiem na którymkolwiek z tych rozwiązań.

Który z trzech wariantów jest odpowiedni

• Proxmox Backup Server (PBS): źródłem jest Proxmox VE (virtual environment), a przywracanym obiektem cała maszyna wirtualna. Kopia wykonywana jest na poziomie obrazu dysku, a zadania weryfikacji ponownie odczytują dane znajdujące się w miejscu docelowym.
• Repozytorium restic: źródłem jest jeden lub kilka hostów Linux, a przywracanym obiektem katalog lub zrzut bazy danych. Szyfrowanie odbywa się po stronie klienta, a narzędzie obsługuje protokoły SSH, S3 oraz własny protokół REST.
• rsync przez SSH, pobierany przez hosta kopii zapasowych: rozwiązanie stosowane, gdy pliki w miejscu docelowym mają być zwykłymi plikami, możliwymi do odczytania za pomocą ls i cat, bez konieczności użycia oprogramowania klienckiego do ich odzyskania.

W przypadku trudności z wyborem należy użyć restic. Narzędzie szyfruje dane przed ich wysłaniem z maszyny i nie wymaga w miejscu docelowym niczego poza kontem SSH oraz przestrzenią dyskową. Konfiguracja kopii zapasowych restic na VPS szczegółowo omawia stronę kliencką, a restic i BorgBackup obok siebie opisuje kwestię wyboru w przypadku korzystania z Borg.

Szacowanie rozmiaru celu: ile kosztuje miesiąc retencji

Deduplikacja sprawia, że liczby są mniejsze, niż można by oczekiwać. Zarówno restic, jak i PBS dzielą pliki na fragmenty o zmiennym rozmiarze i obliczają skrót dla każdego z nich. Każdy unikalny fragment jest przechowywany tylko raz. Drugi backup zbioru danych o rozmiarze 500 GB nie dodaje kolejnych 500 GB. Dodaje jedynie te fragmenty, które uległy zmianie.

Dlatego rozmiar repozytorium zależy od wieku najstarszego snapshotu, a nie od liczby snapshotów. Przyjmijmy 500 GB danych i 5 GB nowych unikalnych danych dziennie. Repozytorium przechowuje wtedy bazowe 500 GB oraz około 5 GB za każdy dzień wstecz, aż do najstarszego snapshotu zachowanego przez politykę retencji.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

Kolumna z cenami w dolarach wycenia to repozytorium na 10 dolarów amerykańskich za TB miesięcznie. Jest to wartość przykładowa dla celów obliczeniowych, a nie oferta konkretnego dostawcy, dlatego należy podstawić rzeczywistą cenę za TB planu, który jest rozważany. Tydzień backupów dziennych zajmuje około 535 GB. Pełny rok historii zajmuje 2,325 GB, co kosztuje $23.25 miesięcznie w porównaniu do $5.35 za tydzień. Historia jest tania. Płaci się głównie za kopię bazową.

Deduplikacja nie przynosi korzyści w przypadku danych, które docierają już skompresowane lub zaszyfrowane. Zrzut bazy danych w formacie gzipped zmienia się całkowicie przy każdym uruchomieniu, więc każdy zrzut jest zapisywany jako nowe fragmenty, a repozytorium powiększa się o pełny rozmiar zrzutu każdej nocy. Zrzut należy zapisywać bez kompresji i pozwolić narzędziu do backupu na jej wykonanie, ponieważ restic wspiera skompresowane repozytoria od wersji 0.14, a wersja 0.19 dodała tryby fastest oraz better zstd. Biblioteki zdjęć i wideo słabo poddają się deduplikacji z tego samego powodu, dlatego ich rozmiar należy szacować na podstawie rzeczywistego tempa przyrostu, a nie na podstawie powyższych wierszy.

W tym przypadku kupuje się bezczynną przestrzeń dyskową, a nie moc obliczeniową CPU, co jest sytuacją, w której storage VPS przewyższa zwykły VPS.

Dlaczego przepustowość i czas przywracania danych determinują wybór planu

Dysk jest tani. Kosztowne są pierwsze przesyłanie danych oraz ewentualne ich przywracanie. 500 GB to 4 biliony bitów, więc podzielenie tej wartości przez prędkość łącza wyznacza dolną granicę czasu potrzebnego na pełne przywrócenie danych.

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

Są to wartości teoretyczne dla prędkości łącza, nieuwzględniające narzutu protokołów, należy je więc traktować jako scenariusz optymistyczny. Przy łączu 100 Mbit/s pełne przywrócenie danych wymaga 11.1 godzin, zanim użytkownik uzyska dostęp do plików. W przypadku domowego łącza wysyłkowego o prędkości 40 Mbit/s potrzeba 27.8 godzin. Na porcie 1 Gbit/s to samo przywracanie zajmuje 1.1 godzin. Wiele małych plików jest przetwarzanych wolniej niż wynikałoby to z obliczeń, ponieważ narzut na każdy plik staje się dominujący, gdy pliki mają rozmiar poniżej kilkuset kilobajtów.

Wynikają z tego dwie kwestie. Jeśli cel czasu odzyskiwania (RTO), czyli czas przestoju, który można zaakceptować, wynosi cztery godziny, to przywrócenie 500 GB przez łącze 100 Mbit/s już przekracza ten limit, a tańszy dysk w niczym nie pomoże. Ponadto większość planów VPS limituje transfer wychodzący, więc jedno pełne przywrócenie danych zużywa 0,5 TB miesięcznego limitu hosta kopii zapasowych. Przed wystąpieniem potrzeby odzyskania danych należy sprawdzić ten limit oraz zasady dostawcy dotyczące jego przekroczenia.

Pierwsza kopia zapasowa obejmuje cały zbiór danych i jest najwolniejszym procesem, jaki zostanie wykonany. Należy rozpocząć go w piątek i ograniczyć prędkość, aby nie wysycić łącza źródłowego: restic przyjmuje --limit-upload w KiB na sekundę, a rsync przyjmuje --bwlimit.

Wariant 1: Proxmox Backup Server jako zdalny magazyn danych

PBS sprawdza się, gdy źródłem jest Proxmox VE, a jednostką przywracania maszyna wirtualna. VPS nie może uruchomić obrazu ISO Proxmox, dlatego PBS należy zainstalować na systemie Debian. Wersja 4.2 jest aktualna na sierpień 2026 i bazuje na systemie Debian 13 (trixie).

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Porównaj tę sumę kontrolną z wartością opublikowaną na stronie repozytoriów pakietów Proxmox. Repozytorium apt jest tak godne zaufania, jak klucz, który zweryfikowałeś. Następnie wykonaj /etc/apt/sources.list.d/proxmox.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Przydziel magazynowi danych (datastore) osobny system plików lub wolumen. Pełny magazyn danych wstrzymuje tworzenie kopii zapasowych, a magazyn współdzielący system plików root powoduje awarię całego serwera w momencie zapełnienia.

Następnie utwórz konto, z którego będzie korzystać źródło, i nadaj mu token zamiast hasła.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

Sekret tokena wyświetla się tylko raz i nie można go odczytać ponownie, dlatego zapisz go w momencie wyświetlenia. Rola jest równie ważna co sam token. DatastoreBackup może tworzyć i przywracać własne kopie zapasowe, a ponieważ nie posiada uprawnienia Datastore.Prune, token ten nie może usunąć migawki, którą sam zapisał.

Retencja w PBS składa się z dwóch części, a druga z nich jest często pomijana. Prune usuwa migawki. Garbage collection usuwa fragmenty danych (chunks), do których nie odwołuje się żadna istniejąca migawka. Wolne miejsce pojawia się dopiero po wykonaniu garbage collection, a nie po operacji prune.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

Uruchom --dry-run, gdy lista migawek przeznaczonych do usunięcia wygląda poprawnie. Garbage collection działa w dwóch fazach: aktualizuje czas dostępu każdego fragmentu, do którego istnieje odwołanie, a następnie usuwa fragmenty, których czas dostępu jest starszy niż wyznaczony limit (24 godziny i 5 minut przed rozpoczęciem zadania). Ten okres karencji istnieje po to, aby fragment zapisywany przez trwającą kopię zapasową nie został usunięty w trakcie operacji. Zaplanuj zadanie prune codziennie, a garbage collection co tydzień dla danego magazynu danych. Dodaj również zadanie weryfikacji (verify job), aby cel ponownie odczytywał własne fragmenty i zgłaszał uszkodzenia na dysku, zanim wykryje je proces przywracania.

Jeśli źródłem jest inna instancja PBS, serwer zdalny może pobierać dane (pull) zamiast czekać na ich wypchnięcie (push).

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

Uruchom to zadanie synchronizacji na VPS w domyślnym kierunku pobierania. VPS łączy się z domowym magazynem danych, co oznacza, że serwer domowy nie przechowuje żadnych poświadczeń, które mogłyby uzyskać dostęp do kopii zdalnej.

Wariant 2: repozytorium restic przez SSH lub S3

Dystrybucje Debian i Ubuntu oferują pakiety restic, jednak wersje w repozytoriach są starsze niż wydania upstream. Wersja 0.19.1 jest aktualna na sierpień 2026. Należy zainstalować oficjalny plik binarny na hoście źródłowym.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version wyświetla wersję oraz kompilator Go, przy użyciu którego zbudowano narzędzie. Aktualizacje do nowszych wersji wykonuje się poleceniem sudo restic self-update, które działa wyłącznie w przypadku oficjalnych plików binarnych, a nie kopii zainstalowanych przez apt.

Na serwerze VPS przeznaczonym na kopie zapasowe należy utworzyć konto, które nie posiada żadnych innych uprawnień, a następnie skopiować klucz publiczny hosta źródłowego do pliku /home/resticsrv/.ssh/authorized_keys.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

Inicjalizację repozytorium przeprowadza się z poziomu hosta źródłowego przez SFTP.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

Hasło należy przechowywać w miejscu innym niż serwer źródłowy oraz serwer docelowy. Utrata hasła oznacza całkowitą utratę dostępu do repozytorium bez możliwości odzyskania danych. Jest to nieodłączny element szyfrowania po stronie klienta.

Polityka retencji realizowana jest jednym poleceniem, którego druga część odpowiada za zwolnienie miejsca na dysku.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget usuwa migawki. prune usuwa pliki paczek (pack files), do których odwoływały się wyłącznie usunięte migawki, natomiast --prune uruchamia ten proces automatycznie, jeśli faktycznie doszło do usunięcia danych. Bez tego parametru rozmiar repozytorium nie ulegnie zmniejszeniu. restic check weryfikuje strukturę repozytorium, a --read-data-subset=10% ponownie odczytuje i oblicza sumy kontrolne dla jednej dziesiątej plików paczek, co pozwala wykryć uszkodzenia danych na serwerze docelowym bez konieczności odczytu całości. Wariant --read-data-subset=1/10 sprawdza stałą jedną dziesiątą danych, więc zwiększanie tej wartości co tydzień pozwala na sprawdzenie całego repozytorium w ciągu dziesięciu tygodni.

Jeśli proces zostanie przerwany, kolejne uruchomienie zakończy się błędem repository is already locked exclusively by PID. Po upewnieniu się, że żadna kopia zapasowa nie jest w toku, należy usunąć blokadę poleceniem restic unlock.

W przypadku pamięci obiektowej (object storage) ciąg znaków repozytorium przyjmuje postać s3:https://s3.example.net/web1, a dane uwierzytelniające umieszcza się w AWS_ACCESS_KEY_ID oraz AWS_SECRET_ACCESS_KEY. Pozostałe operacje pozostają identyczne, co pozwala narzędziu restic na komunikację z własną instancją MinIO działającą na tym samym serwerze VPS.

Wariant 3: rsync przez SSH z kluczem typu pull-only

Właściwością bezpieczeństwa tego wariantu jest kierunek połączenia. Serwer VPS z kopiami zapasowymi łączy się ze źródłem i pobiera dane. Źródło nie posiada klucza ani trasy do hosta z kopiami, więc przejęcie źródła nie pozwala na dostęp do kopii zapasowych.

Wygeneruj parę kluczy na serwerze VPS z kopiami, a następnie zainstaluj klucz publiczny na źródle z wymuszonym poleceniem.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync jest dostarczany w pakiecie rsync w lokalizacji /usr/bin/rrsync w systemach Debian 13 oraz Ubuntu 24.04. -ro umożliwia wyłącznie odczyt i implikuje -no-del, dzięki czemu ten klucz nie może zapisywać danych na źródle ani usuwać żadnych plików. restrict wyłącza funkcje SSH, które nie są tutaj wymagane, w tym przekierowanie portów oraz pty, co uniemożliwia użycie klucza do interaktywnego logowania. Ścieżki są wówczas relatywne względem wskazanego katalogu, więc zdalna ścieżka / oznacza /srv na źródle.

Pobieranie danych zachowuje historię za pomocą twardych dowiązań (hardlinks). Niezmienione pliki w nowym drzewie są twardymi dowiązaniami do poprzedniego drzewa, więc zajmują jedynie wpis w katalogu zamiast tworzyć drugą kopię.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

Zmiana nazwy na końcu procesu zapewnia wiarygodność katalogu z datą: nazwa pojawia się dopiero po zakończeniu rsync z kodem wyjścia 0, dzięki czemu przerwany transfer nigdy nie wygląda jak ukończona migawka. Usuwaj stare drzewa jednym poleceniem, zachowując trzydzieści ostatnich.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

Należy mieć świadomość kosztów tego rozwiązania. Twarde dowiązania deduplikują tylko całe pliki, więc zmiana jednego bajta w 4 GB obrazie dysku powoduje skopiowanie całych 4 GB, podczas gdy restic lub PBS zapisałyby tylko zmienione fragmenty. Cel przechowuje również pliki w postaci jawnej, więc każdy użytkownik z uprawnieniami root na serwerze VPS z kopiami może je odczytać.

Szyfrowanie po stronie klienta, aby cel nigdy nie widział tekstu jawnego

Traktuj serwer VPS z kopiami zapasowymi jako maszynę, nad którą nie masz pełnej kontroli. Posiada on dostawcę, a dostawca ten zatrudnia personel i zmaga się z awariami dysków, które opuszczają budynek.

restic szyfruje każdy fragment danych po stronie źródła przed wysłaniem, więc repozytorium składa się z tekstu zaszyfrowanego oraz metadanych dotyczących rozmiarów i czasu. PBS sprawia, że szyfrowanie jest opcjonalne: należy utworzyć klucz, a następnie przekazywać go przy każdym backupie.

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

Wydrukuj klucz papierowy i przechowuj go w bezpiecznym miejscu fizycznym. Dokumentacja Proxmox jasno określa stawkę: bez klucza pliki kopii zapasowych są niedostępne. Nie przechowuj klucza na serwerze docelowym, ponieważ klucz znajdujący się obok tekstu zaszyfrowanego nie zapewnia żadnej ochrony.

Kopie lustrzane rsync nie mają odpowiednika tego mechanizmu. Pliki trafiają na miejsce w postaci plików. Jeśli dane są wrażliwe, należy zaakceptować fakt, że serwer docelowy może je odczytać, albo skorzystać z jednego z dwóch pozostałych rozwiązań.

Zabezpieczenie przed usunięciem kopii zapasowych przez przejęty serwer źródłowy

Atakujący, który przejmuje serwer źródłowy, szuka w następnej kolejności kopii zapasowych, a poświadczenia służące do ich przesyłania znajdują się bezpośrednio na tym urządzeniu. Jeśli te poświadczenia posiadają uprawnienia do usuwania, zostaną one wykorzystane.

PBS rozwiązuje ten problem za pomocą ról. Token posiadający wyłącznie DatastoreBackup może zapisywać nowe migawki i przywracać własne, ale nie może ich usuwać, ponieważ usunięcie migawki wymaga osobnego uprawnienia Datastore.Prune. Należy uruchamiać retencję po stronie PBS, dzięki czemu serwer źródłowy nigdy nie posiada poświadczeń umożliwiających usunięcie jakichkolwiek danych.

Narzędzie restic działające przez SFTP nie posiada takiego podziału, ponieważ klucz SSH używany do zapisu w repozytorium pozwala również na jego usuwanie. Rozwiązaniem jest backend REST. Należy uruchomić rest-server na serwerze VPS z kopiami zapasowymi z flagą --append-only, która pozwala na tworzenie nowych kopii, ale blokuje usuwanie i modyfikację istniejących. Następnie należy wskazać klientowi adres rest:https://backup.example.net:8000/web1, używając RESTIC_REST_USERNAME oraz RESTIC_REST_PASSWORD. Polecenie restic forget --prune wywołane ze źródła zakończy się wówczas niepowodzeniem, co jest pożądanym rezultatem. Retencję należy uruchamiać z drugiego urządzenia, używając odrębnych poświadczeń. Dokumentacja restic zaleca również stosowanie --keep-within zamiast polityk opartych na liczbie kopii w repozytoriach typu append-only. W przeciwnym razie atakujący mógłby zalać repozytorium bezużytecznymi migawkami, wypierając rzeczywiste kopie z okna czasowego --keep-last.

rsync rozwiązuje ten sam problem strukturalnie poprzez pobieranie danych (pull), ponieważ serwer źródłowy nie posiada żadnych poświadczeń dostępu do serwera docelowego.

Jedna zasada dotyczy wszystkich trzech przypadków: poświadczenia umożliwiające usuwanie kopii zapasowych muszą znajdować się na maszynie innej niż ta, która jest archiwizowana.

Zaplanuj ćwiczenia z przywracania danych

Kopia zapasowa, z której nigdy nie przywrócono danych, jest jedynie hipotezą. Zarezerwuj godzinę w każdym kwartale i przetestuj ją.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r brak danych wyjściowych oznacza, że przywrócone drzewo plików jest zgodne z wersją produkcyjną. W przypadku PBS to samo ćwiczenie wykonuje się za pomocą proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/, dodatkowo korzystając z zaplanowanego zadania weryfikacji, które ponownie odczytuje fragmenty danych w lokalizacji docelowej i zgłasza błędy sum kontrolnych.

Ćwiczenie musi dowieść czegoś więcej niż tylko integralności bajtów.

• Przywracaj dane z trzeciej maszyny, a nie ze źródła, ponieważ zakładasz, że źródło przestało istnieć. Oznacza to, że hasło do repozytorium lub klucz PBS muszą być dostępne bez udziału źródła.
• Zmierz czas przywracania i zapisz go, a następnie porównaj z zadeklarowanym RTO. Powyższy wykres przedstawia minimalny czas transferu. Rzeczywisty wynik obejmuje również deszyfrowanie, zapis na dysk oraz czas poświęcony na ustalenie, który snapshot jest wymagany.
• Przywróć dane posiadające stan, na przykład zrzut bazy danych, który następnie załadujesz do instancji testowej. Rozpakowanie pliku tar nie jest dowodem na to, że aplikacja się uruchomi.

Najtańszy dysk na świecie nie jest wart nic, dopóki nie przywrócono z niego danych przynajmniej raz.

FAQ

Czy snapshot u dostawcy VPS to kopia zapasowa typu off-site?

Nie. Snapshot dostawcy znajduje się na tym samym koncie, za tym samym panelem logowania i na tej samej fakturze co serwer, z którego pochodzi. Każdy, kto uzyska dostęp do tego konta, może usunąć serwer oraz wszystkie jego snapshoty w jednej sesji. Snapshoty są przydatne do szybkiego przywrócenia stanu przed ryzykowną aktualizacją, ale nie stanowią drugiej lokalizacji. Kopia off-site znajduje się na innym koncie, najlepiej u innego dostawcy, z danymi uwierzytelniającymi, do których maszyna źródłowa nie ma dostępu.

Ile miejsca na dysku potrzeba na miesiąc przechowywania kopii zapasowych?

Należy oszacować rozmiar na podstawie wieku najstarszego snapshotu, a nie liczby snapshotów. Narzędzie z deduplikacją przechowuje każdy unikalny fragment danych tylko raz, więc repozytorium ma rozmiar zbliżony do rozmiaru źródła powiększonego o nowe unikalne dane przyrastające dziennie, pomnożone przez liczbę dni przechowywania. Dla 500 GB danych zmieniających się o 5 GB dziennie, tydzień codziennych kopii to około 535 GB, a pełny rok historii to 2,325 GB. Należy zapewnić zapas miejsca, ponieważ pełny dysk uniemożliwia wykonanie kolejnej kopii, a operacja prune w restic wymaga wolnej przestrzeni do przepakowania plików przed zwolnieniem miejsca.

Czy przejęty serwer może usunąć własne kopie zapasowe off-site?

Tak, chyba że architektura systemu temu zapobiega. W przypadku zwykłego repozytorium SSH lub SFTP klucz służący do zapisu może również usuwać dane. Należy nadać źródłu uprawnienia, które nie pozwalają na usuwanie danych: token API PBS z rolą DatastoreBackup, która nie posiada uprawnienia Datastore.Prune, lub użyć restic z rest-server uruchomionym z flagą --append-only, co blokuje usuwanie i modyfikację istniejących kopii. Model typu pull zapewnia wyższy poziom bezpieczeństwa, ponieważ źródło nie posiada żadnych danych uwierzytelniających do hosta kopii zapasowych. Retencję należy uruchamiać z poziomu hosta kopii zapasowych, a nie źródła.

Czy na serwerze kopii zapasowych VPS uruchomić Proxmox Backup Server czy restic?

Narzędzie należy dobrać do jednostki, która będzie przywracana. Jeśli źródłem jest Proxmox VE i wymagane jest przywrócenie całej maszyny wirtualnej, należy użyć PBS, ponieważ wykonuje on kopie na poziomie obrazu dysku i przywraca maszynę w jednym kroku. Jeśli źródłem jest host Linux i wymagane jest przywrócenie plików oraz zrzutów baz danych, należy użyć restic, który wymaga jedynie konta SSH na celu i szyfruje dane przed wysyłką. Uruchomienie obu rozwiązań jest standardową praktyką: PBS dla hypervisora, restic dla serwerów, które na nim nie działają.

Ile czasu zajmuje przywracanie z kopii zapasowej VPS?

Należy podzielić rozmiar danych przez prędkość łącza, aby uzyskać czas minimalny, a następnie dodać czas potrzebny na deszyfrowanie i zapis. 500 GB przesyłane przez łącze 100 Mbit/s to 11.1 godzin przy pełnej przepustowości, a to samo przywracanie przez port 1 Gbit/s zajmuje 1.1 godzin. Duża liczba małych plików powoduje spowolnienie procesu ze względu na narzut na każdy plik. Należy przeprowadzić testowe przywracanie i zmierzyć czas, ponieważ jest to jedyna wartość, na której można polegać w planie odzyskiwania danych.