Restic czy BorgBackup: co wybrać do kopii zapasowych?

Restic a BorgBackup – porównanie w jednym akapicie

Restic oraz BorgBackup realizują to samo podstawowe zadanie: tworzenie deduplikowanych, szyfrowanych i przyrostowych kopii zapasowych serwera Linux. O wyborze decyduje miejsce docelowe składowania kopii. Restic natywnie obsługuje S3 oraz inne API pamięci obiektowej, dzięki czemu bucket jest pełnoprawnym celem bez konieczności instalacji dodatkowego oprogramowania po stronie serwera docelowego. Borg wymaga zainstalowania programu borg na maszynie przechowującej repozytorium, ponieważ repozytorium Borg jest obsługiwane przez proces, a nie przez system plików czy API. Jeśli celem jest pamięć obiektowa, wybór jest oczywisty. Jeśli celem jest drugi serwer Linux pod Twoją kontrolą, Borg jest realną alternatywą i często działa szybciej.

Pozostałe różnice są mniej istotne. Oba narzędzia dzielą pliki przy użyciu mechanizmu content-defined chunking, więc w przypadku katalogu o rozmiarze 40 GB, w którym zmieniono 200 MB danych, przesyłane jest około 200 MB. Oba narzędzia szyfrują dane po stronie klienta. Oba pozwalają na zamontowanie migawki za pomocą FUSE (filesystem in userspace), co umożliwia wyodrębnienie pojedynczego pliku. Według stanu na lipiec 2026 roku, Restic znajduje się w wersji 0.19.1, a stabilna seria Borg to 1.4, konkretnie wersja 1.4.5. Wersja Borg 2.0 od lat pozostaje w fazie beta i jest oznaczona wyłącznie do testów, dlatego obecnie należy wdrażać serię 1.4.

Model repozytorium stanowi zasadniczą różnicę

Repozytorium restic to katalog plików: config, keys/, snapshots/, index/ oraz data/ wypełniony plikami typu pack. Do jego odczytu nie potrzeba niczego więcej. Dzięki temu restic może obsługiwać tak wiele backendów. Każdy magazyn danych, który umożliwia operacje put, get, list oraz delete na obiektach typu blob, może przechowywać repozytorium restic. Właśnie dlatego jeden plik binarny obsługuje ścieżki lokalne, SFTP, własny serwer REST, S3, Backblaze B2, Azure, Google Cloud Storage oraz wszystko, co jest dostępne przez rclone.

Repozytorium Borg również składa się z plików na dysku, jednak Borg nigdy nie komunikuje się z nim za pomocą prostego protokołu przesyłania danych. W przypadku repozytorium zdalnego Borg uruchamia borg serve po stronie zdalnej przez SSH i komunikuje się z tym procesem za pomocą własnego protokołu. Strona serwerowa wykonuje rzeczywistą pracę: przechowuje repozytorium, zatwierdza transakcje i odpowiada na zapytania dotyczące indeksu. To wyjaśnia, dlaczego Borg nie posiada backendu S3 i dlaczego projekt nie wprowadził takiej obsługi. Wewnątrz zasobnika (bucket) nie ma procesu, który mógłby zostać uruchomiony.

Ten jeden fakt projektowy determinuje większość praktycznych różnic przedstawionych poniżej.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

Szyfrowanie: jedną z opcji można wyłączyć

Restic jest zawsze szyfrowany. Nie istnieje tryb bez szyfrowania. restic init wymaga podania hasła, na podstawie którego za pomocą scrypt wyprowadzany jest klucz, a każdy zapisywany po tym plik typu pack jest szyfrowany i uwierzytelniany. Utrata hasła oznacza bezpowrotną utratę danych, ponieważ z założenia nie przewidziano ścieżki odzyskiwania.

Borg pozwala na wybór szyfrowania podczas tworzenia repozytorium, a wybór ten jest trwały. borg init --encryption=repokey przechowuje zaszyfrowany klucz wewnątrz repozytorium, więc do przywrócenia danych wystarczy sama fraza hasłowa. --encryption=keyfile przechowuje klucz po stronie klienta w ~/.config/borg/keys/, dzięki czemu osoba, która przejmie całe repozytorium, nie uzyska dostępu do danych. Wymusza to jednak oddzielne tworzenie kopii zapasowej pliku klucza, w przeciwnym razie archiwa staną się nieczytelne. Każdy tryb posiada wariant -blake2, który zamiast HMAC-SHA256 używa do uwierzytelniania algorytmu BLAKE2b, co jest szybsze na sprzęcie bez akceleracji SHA. Istnieje również --encryption=none, co stanowi realną opcję, gdy repozytorium znajduje się na własnym, zaszyfrowanym dysku.

Praktyczna zasada: repokey-blake2 dla standardowej kopii zapasowej serwera, keyfile, gdy repozytorium znajduje się w lokalizacji, której nie darzysz pełnym zaufaniem, oraz nigdy none na wynajętej maszynie.

Kompresja i powody, dla których restic wprowadził ją z opóźnieniem

Borg oferuje kompresję od samego początku. Domyślnym ustawieniem jest lz4, wybrane ze względu na szybkość, która pozwala na stosowanie go w każdym przypadku. zstd akceptuje poziomy od 1 do 22, z wartością domyślną 3, natomiast zlib oraz lzma są przeznaczone do scenariuszy, w których priorytetem jest oszczędność miejsca, a nie czas operacji. auto uruchamia heurystykę dla każdego fragmentu danych, dzięki czemu dane już skompresowane nie są przetwarzane ponownie.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

Restic nie posiadał żadnej formy kompresji aż do wprowadzenia formatu repozytorium 2, który wymaga wersji restic 0.14.0 lub nowszej. Format 2 jest obecnie domyślny dla nowych repozytoriów, a kompresję konfiguruje się za pomocą --compression, wybierając wartości auto, off lub max. Stare repozytoria w formacie 1 pozostają nieskompresowane do momentu przeprowadzenia migracji. Jeśli zatem repozytorium restic powstało przed wersją 0.14 i nie zostało zmigrowane, nadal zajmuje pełną przestrzeń dyskową dla plików tekstowych, logów oraz zrzutów baz danych.

Zdalne cele: S3 kontra SSH

W tym miejscu zazwyczaj zapada decyzja o wyborze rozwiązania.

Restic łączący się z S3 wymaga jedynie poświadczeń w środowisku i nie potrzebuje żadnego dodatkowego oprogramowania po stronie serwera. Ten sam schemat działa w przypadku własnego zasobnika (bucket), co jest częstym rozwiązaniem: uruchom MinIO dla API S3 na własnym VPS i skieruj na niego restic.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Borg łączący się ze zdalnym repozytorium wymaga SSH oraz zainstalowanego oprogramowania Borg po stronie zdalnej, przy czym wersja tam zainstalowana musi być kompatybilna z klientem. Stanowi to utrudnienie, jeśli zdalna maszyna nie należy do administratora. Nie jest to jednak problemem, gdy zdalna strona to drugi serwer, którym już zarządzasz. Zapewnia to najsilniejszą ochronę przed oprogramowaniem typu ransomware, jaką oferuje którekolwiek z tych narzędzi: klucz SSH z uprawnieniami tylko do dopisywania (append-only). Wymuś na kluczu uruchomienie borg serve, a klient będzie mógł dodawać archiwa, ale nie będzie mógł ich usuwać. Dzięki temu przejęta maszyna nie będzie w stanie usunąć własnej historii kopii zapasowych.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

Restic posiada odpowiednik tej funkcji tylko w przypadku uruchomienia własnego serwera REST, który wspiera tryb tylko do dopisywania. W przypadku standardowego S3 ten sam efekt uzyskuje się poprzez politykę zasobnika (bucket policy) lub blokadę obiektów (object lock), co jest zadaniem dostawcy, a nie narzędzia restic. Należy również zabezpieczyć sam transport, ponieważ strona SSH wymaga takiej samej uwagi jak każde inne logowanie: zastosuj logowanie SSH wyłącznie przy użyciu kluczy z ograniczonym wpisem w authorized_keys dla konta przeznaczonego do kopii zapasowych.

Szybkość: co oznacza każdy z projektów

Żaden z projektów nie publikuje benchmarków, którym należy ufać w kontekście własnych danych, dlatego należy wyciągać wnioski na podstawie mechanizmów działania.

Borg przez SSH działa szybko na łączach z opóźnieniami, ponieważ strona serwerowa jest inteligentna. Klient zadaje pytanie, zdalny proces borg serve odpowiada na nie na podstawie indeksu repozytorium, a transakcja jest zatwierdzana w jednym miejscu. Wyszukiwanie fragmentów (chunków) nie zamienia się w rundy sieciowe dla każdego małego pliku.

Restic w przypadku pamięci obiektowej nie posiada strony serwerowej, więc musi budować obraz sytuacji na podstawie plików indeksu i plików paczek (pack files), które pobiera przez HTTP. Aby utrzymać liczbę żądań na rozsądnym poziomie, przed wysłaniem pakuje wiele małych fragmentów w większe pliki paczek i przechowuje lokalną pamięć podręczną w ~/.cache/restic, dzięki czemu kolejne uruchomienie nie wymaga ponownego pobierania całego indeksu. Usunięcie tej pamięci podręcznej powoduje, że kolejny backup jest wolny, ponieważ musi zostać ona odbudowana. Na łączach o wysokim opóźnieniu, przy milionach małych plików, restic może wydawać się wolniejszy niż Borg przy tych samych danych.

Na dysku lokalnym lub w szybkiej sieci LAN różnica ta niemal znika, a oba narzędzia są ograniczane głównie przez szybkość odczytu i obliczania sum kontrolnych (hashowania) danych źródłowych.

Blokowanie i tworzenie kopii zapasowych wielu maszyn

Borg 1.4 zakłada wyłączną blokadę na repozytorium na czas trwania całej operacji. Zapisywanie do jednego repozytorium przez dwóch klientów jednocześnie nie jest obsługiwane: drugi klient oczekuje, a następnie kończy działanie z błędem przekroczenia czasu blokady. Zalecanym wzorcem jest stosowanie jednego repozytorium na klienta. Oznacza to również, że deduplikacja zachodzi wyłącznie w obrębie repozytorium jednej maszyny, więc dziesięć niemal identycznych serwerów przechowuje dziesięć kopii tego samego systemu bazowego.

Restic umożliwia jednoczesne tworzenie kopii zapasowych przez wielu klientów w jednym repozytorium, ponieważ kopia zapasowa wymaga jedynie blokady współdzielonej, a blokada wyłączna jest wymagana tylko podczas prac konserwacyjnych, takich jak prune. Dziesięć podobnych serwerów wskazujących na jedno repozytorium restic podlega wzajemnej deduplikacji, dzięki czemu drugi i kolejne serwery często przechowują bardzo niewielką ilość danych. Ceną tego rozwiązania jest zwiększony zakres awarii: jedno hasło i jedno repozytorium przechowujące wszystkie dane oznaczają, że utrata hasła powoduje utratę kopii wszystkich dziesięciu maszyn.

Retencja: forget i prune kontra prune i compact

Oba narzędzia rozdzielają decyzję o tym, co zachować, od procesu odzyskiwania miejsca. W obu przypadkach wymagane jest ręczne uruchomienie drugiego etapu.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

Pułapka w obu narzędziach jest identyczna i warto ją jasno określić. W Borg polecenie borg prune usuwa archiwa, ale samo w sobie nie zwalnia miejsca na dysku. Miejsce zostaje odzyskane dopiero po uruchomieniu borg compact, więc zadanie cron, które wykonuje tylko usuwanie bez kompaktowania, pozostawi repozytorium, które stale rośnie, mimo krótkiej listy archiwów. W restic polecenie forget bez --prune usuwa jedynie odniesienia do migawek, a dane pozostają na dysku do momentu wykonania operacji prune.

Po zakończeniu usuwania należy uruchomić restic check. Polecenie to weryfikuje strukturę repozytorium i informuje o ewentualnych uszkodzeniach, co jest znacznie lepszym rozwiązaniem niż wykrycie problemu dopiero podczas przywracania danych.

Przywracanie danych, czyli jedyny test, który ma znaczenie

Oba narzędzia umożliwiają zamontowanie migawki w celu jej przeglądania. Jest to najszybszy sposób na odzyskanie pojedynczego pliku.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

Należy zwrócić uwagę na format ścieżki w borg extract. Ścieżki wewnątrz archiwum są przechowywane bez wiodącego ukośnika, dlatego etc/nginx jest poprawne, a /etc/nginx nie pasuje do niczego i nie wyodrębnia żadnych danych, nie generując przy tym komunikatu o błędzie. Proces wyodrębniania zapisuje pliki w bieżącym katalogu roboczym, dlatego należy najpierw przejść do katalogu tymczasowego, aby uniknąć nadpisania aktualnych plików ich starszymi wersjami.

Przywrócenie danych zakończone bez błędu nie stanowi jeszcze dowodu poprawności, ponieważ aplikacja nadrzędna posiada własne wymagania dotyczące kompletności odzyskiwania: serwer Immich odbudowany z kopii katalogu danych Postgres powróci ze wszystkimi zdjęciami na dysku, ale z pustą osią czasu, co jest dokładnie tym błędem, który wymaga obejścia opisanego w tworzenie kopii zapasowych i przywracanie Immich.

Niezależnie od wybranego narzędzia, harmonogram to tylko połowa sukcesu. Należy regularnie przeprowadzać przywracanie do katalogu tymczasowego, monitorując ten proces w taki sam sposób, jak opisano w pełnym przewodniku przewodnik po tworzeniu kopii zapasowych restic dla VPS z wykorzystaniem timera systemd.

Wybór narzędzia w zależności od zastosowania

Wybierz restic, gdy celem jest object storage, gdy wymagasz jednego pliku binarnego bez konieczności instalacji oprogramowania po stronie zdalnej, gdy wiele maszyn ma współdzielić deduplikację lub gdy przywracaniem danych może zajmować się inna osoba. Jest to pojedynczy statyczny plik binarny korzystający z adresu URL repozytorium, co pod względem operacyjnym jest rozwiązaniem trudnym do przebicia.

Wybierz Borg, gdy celem jest serwer Linux pod Twoją kontrolą, gdy łącze charakteryzuje się opóźnieniami, a zbiór danych składa się z milionów małych plików, gdy chcesz użyć klucza SSH typu append-only jako zabezpieczenia przed ransomware lub gdy potrzebujesz precyzyjnego dostrojenia kompresji dla każdego zadania. Jest to starsze narzędzie, którego stabilna seria rozwija się powoli, co w przypadku oprogramowania do kopii zapasowych stanowi zaletę.

Oba rozwiązania są poprawne. Błędną odpowiedzią jest ta, której nigdy nie przetestujesz. Jeśli już wykonujesz zrzuty na poziomie aplikacji, zachowaj je: schemat opisany w konfiguracji Nextcloud na Docker z zrzutami bazy danych ma zastosowanie do obu narzędzi, ponieważ plik aktywnej bazy danych skopiowany w losowym momencie nie stanowi poprawnej kopii zapasowej bazy danych.

FAQ

Czy restic czy BorgBackup jest szybszy?

Na dysku lokalnym lub w szybkiej sieci LAN wydajność jest zbliżona, a oba narzędzia są ograniczane przez szybkość odczytu i obliczania sum kontrolnych w źródle. Borg zazwyczaj wygrywa przy połączeniach SSH o wysokim opóźnieniu i dużej liczbie małych plików, ponieważ proces borg serve po stronie zdalnej odpowiada na zapytania o indeks bez konieczności wykonywania pełnego cyklu sieciowego dla każdego fragmentu danych. Restic zazwyczaj wygrywa, gdy celem jest pamięć obiektowa (object storage), której Borg nie obsługuje.

Czy BorgBackup może tworzyć kopie zapasowe w S3 lub Backblaze B2?

Nie bezpośrednio. Repozytorium Borg jest obsługiwane przez proces borg serve za pośrednictwem SSH, a taki proces nie działa wewnątrz bucketa. Użytkownicy obchodzą to ograniczenie, montując pamięć obiektową jako system plików za pomocą rclone, czego projekt Borg nie zaleca, ponieważ przerwanie montowania w trakcie transakcji może uszkodzić repozytorium. Jeśli wymagana jest obsługa pamięci obiektowej, należy użyć narzędzia restic.

Czy mogę używać obu narzędzi do tych samych danych?

Tak, niektórzy użytkownicy tak robią: Borg do drugiego serwera w celu szybkiego przywracania lokalnego, a restic do pamięci obiektowej jako kopia zewnętrzna. Narzędzia te nie współdzielą żadnych zasobów, więc koszt odczytu i haszowania jest ponoszony dwukrotnie, a użytkownik musi bezpiecznie przechowywać dwa hasła. Należy to robić tylko po przetestowaniu procedur przywracania danych dla obu narzędzi.

Co się stanie, jeśli zgubię hasło do repozytorium?

W obu narzędziach dane stają się niemożliwe do odzyskania. Restic wyprowadza klucz z hasła za pomocą algorytmu scrypt i nie ma możliwości obejścia tego zabezpieczenia. Borg w trybie repokey przechowuje zaszyfrowany klucz wewnątrz repozytorium, więc do przywrócenia wystarczy sama fraza hasła, natomiast w trybie keyfile wymagany jest również plik klucza z ~/.config/borg/keys/. Hasło należy przechowywać w menedżerze haseł, który nie znajduje się na serwerze objętym kopią zapasową, a w przypadku korzystania z keyfile, klucz Borg należy wyeksportować za pomocą borg key export.

Czy powinienem czekać na Borg 2.0?

Nie. Według stanu na lipiec 2026 r. Borg 2.0 jest wciąż w fazie beta (wersja 2.0.0b22) i projekt oznacza go wyłącznie do celów testowych. Stabilną serią jest 1.4, obecnie 1.4.5. Należy rozpocząć pracę z wersją 1.4 już teraz. Borg 2 zmienia format repozytorium i dostarcza udokumentowaną ścieżkę aktualizacji, więc rozpoczęcie pracy dzisiaj nie powoduje problemów z migracją w przyszłości.