Restic czy BorgBackup: co wybrać do kopii zapasowych?

Restic a BorgBackup 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 danych. Restic natywnie obsługuje S3 oraz inne API pamięci obiektowej, dzięki czemu bucket jest pełnoprawnym celem niewymagającym instalacji żadnego oprogramowania po stronie serwera. 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 przesądzony. Jeśli celem jest drugi serwer Linux pod kontrolą administratora, Borg jest realną alternatywą i często działa szybciej.

Pozostałe różnice mają drugorzędne znaczenie. 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 montowanie migawek za pomocą FUSE (filesystem in userspace), co umożliwia wyodrębnienie pojedynczego pliku. Według stanu na lipiec 2026 r. Restic znajduje się w wersji 0.19.1, a stabilna seria Borg to 1.4, konkretnie 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 to kluczowa różnica

Repozytorium restic to katalog plików: config, keys/, snapshots/, index/ oraz data/ wypełniony plikami typu pack. Do odczytu danych nie jest wymagane nic więcej. Dzięki temu restic obsługuje 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 nimi za pomocą prostego protokołu przesyłania danych. W przypadku repozytorium zdalnego, Borg uruchamia borg serve po stronie zdalnej za pośrednictwem SSH i komunikuje się z tym procesem przy użyciu własnego protokołu. Strona serwerowa wykonuje rzeczywistą pracę: przechowuje repozytorium, zatwierdza transakcje i odpowiada na zapytania dotyczące indeksu. To powód, dla którego Borg nie posiada backendu S3 i dlaczego projekt nie dodał takiej funkcjonalności. Wewnątrz zasobnika (bucket) nie ma możliwości uruchomienia procesu.

Ten pojedynczy fakt projektowy generuje większość różnic praktycznych 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 plik paczki jest szyfrowany i uwierzytelniany. Utrata hasła oznacza bezpowrotną utratę danych, ponieważ z założenia nie istnieje ścieżka odzyskiwania.

Borg pozwala na wybór szyfrowania podczas tworzenia repozytorium i jest to wybór trwały. borg init --encryption=repokey przechowuje zaszyfrowany klucz wewnątrz repozytorium, więc do przywrócenia danych wystarczy sama fraza hasła. --encryption=keyfile przechowuje klucz na kliencie 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 wykorzystuje uwierzytelnianie BLAKE2b zamiast HMAC-SHA256, co jest szybsze na sprzęcie bez akceleracji SHA. Dostępny jest również tryb --encryption=none, który 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 miejscu, któremu nie ufasz w pełni, oraz nigdy none na wynajętej maszynie.

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

Borg oferuje kompresję od początku istnienia. Domyślnym algorytmem jest lz4, wybrany 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. zlib oraz lzma są przeznaczone do sytuacji, w których priorytetem jest oszczędność miejsca, a nie czas operacji, natomiast 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

Narzędzie restic nie posiadało ż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 repozytorium restic zostało utworzone przed wersją 0.14 i nie wykonano migracji, pliki tekstowe, logi oraz zrzuty baz danych nadal zajmują pełną przestrzeń dyskową.

Zdalne cele: S3 kontra SSH

W tym miejscu zazwyczaj zapada decyzja.

Restic łączący się z S3 wymaga jedynie poświadczeń w środowisku i nie potrzebuje żadnego oprogramowania uruchomionego po stronie zdalnej. 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 nie 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; wersja po stronie serwera musi być kompatybilna z klientem. Stanowi to utrudnienie, jeśli zdalna infrastruktura nie należy do Ciebie. Nie jest to problemem, gdy zdalna strona to drugi serwer, którym już administrujesz. Zapewnia to najsilniejszą ochronę przed 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 wtedy, gdy uruchomisz jego własny serwer 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. Zabezpiecz również sam transport, ponieważ strona SSH wymaga takiej samej uwagi jak każde inne logowanie: zastosuj logowanie SSH wyłącznie za pomocą kluczy z ograniczonym wpisem w authorized_keys dla konta 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 danych (chunków) nie zamienia się w rundy komunikacji sieciowej 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 pobieranych 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, dopóki nie zostanie ona odbudowana. Na łączach o wysokim opóźnieniu i przy milionach małych plików restic działa wolniej 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 haszowania 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 przez dwóch klientów do jednego repozytorium jednocześnie nie działa: drugi klient oczekuje, a następnie kończy pracę z błędem przekroczenia czasu blokady. Obsługiwany wzorzec to jedno repozytorium na klienta. Oznacza to również, że deduplikacja zachodzi tylko wewnątrz repozytorium jednej maszyny, więc dziesięć niemal identycznych serwerów przechowuje dziesięć kopii tego samego systemu bazowego.

Restic pozwala wielu klientom na jednoczesne tworzenie kopii zapasowych w jednym repozytorium, ponieważ kopia zapasowa zakłada blokadę współdzieloną, a wyłączną blokadę wymagają tylko prace konserwacyjne, takie jak prune. Dziesięć podobnych serwerów wskazujących na jedno repozytorium restic deduplikuje dane względem siebie, dzięki czemu drugi i kolejne serwery często przechowują bardzo niewiele danych. Kosztem jest zasięg awarii: jedno hasło i jedno repozytorium zawierające wszystko, więc utrata hasła oznacza utratę danych ze 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, wymagając wykonania drugiego kroku przez użytkownika.

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 odzyskiwane jest dopiero po uruchomieniu borg compact, więc zadanie cron, które wykonuje tylko czyszczenie bez kompaktowania, pozostawia repozytorium, które rośnie w nieskończoność, mimo krótkiej listy archiwów. W restic polecenie forget bez --prune jedynie usuwa odwołania do migawek, a dane pozostają na dysku do momentu wykonania operacji prune.

Po zakończeniu czyszczenia należy uruchomić restic check. Polecenie to weryfikuje strukturę repozytorium i informuje o ewentualnych uszkodzeniach, co jest znacznie bezpieczniejszym rozwiązaniem niż wykrycie problemu dopiero w trakcie 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 najszybsza metoda odzyskania 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ą zapisywane bez wiodącego ukośnika, dlatego etc/nginx jest poprawne, a /etc/nginx nie dopasuje żadnego elementu i nie wypakuje niczego, nie generując przy tym komunikatu o błędzie. Proces ekstrakcji zapisuje dane w bieżącym katalogu roboczym, dlatego należy najpierw przejść do katalogu tymczasowego, aby uniknąć nadpisania aktualnych plików ich starszymi wersjami.

Niezależnie od wybranego narzędzia, harmonogram to tylko połowa sukcesu. Należy regularnie przeprowadzać testowe przywracanie danych do katalogu tymczasowego, korzystając z automatyzacji, tak jak opisano to w pełnym przewodniku tworzenia kopii zapasowych restic dla VPS z użyciem timera systemd.

Które rozwiązanie wybrać do konkretnego zadania

Wybierz restic, gdy celem jest object storage, gdy wymagasz pojedynczego 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 z adresem URL repozytorium, co stanowi trudne do przebicia rozwiązanie pod kątem operacyjnym.

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 jest 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 w Dockerze ze 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 prędkość odczytu i obliczania sum kontrolnych w źródle. Borg zazwyczaj wygrywa w przypadku połączeń SSH o wysokim opóźnieniu przy 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 w ogóle 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 dla 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 w celu wykonania kopii zewnętrznej. Narzędzia te nie współdzielą żadnych zasobów, więc koszt odczytu i haszowania ponosi się dwukrotnie, a ponadto należy bezpiecznie przechowywać dwa hasła. Takie rozwiązanie należy stosować tylko po przetestowaniu procedur przywracania danych w obu narzędziach.

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łowa, 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 klucz Borg należy wyeksportować za pomocą borg key export, jeśli używany jest tryb keyfile.

Czy powinienem czekać na Borg 2.0?

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