Restic czy BorgBackup: co uruchomić?

Restic a BorgBackup w jednym akapicie

Restic i BorgBackup wykonują to samo podstawowe zadanie: deduplikowane, szyfrowane i przyrostowe kopie zapasowe serwera Linux. O wyborze decyduje miejsce docelowe kopii zapasowej. Restic natywnie obsługuje S3 i inne interfejsy API magazynów obiektowych, dlatego bucket jest pełnoprawnym miejscem docelowym i po stronie zdalnej nie trzeba nic instalować. Borg wymaga zainstalowania programu borg na komputerze, na którym znajduje się repozytorium, ponieważ repozytorium Borg jest udostępniane przez proces, a nie przez system plików ani interfejs API. Jeśli miejscem docelowym jest magazyn obiektowy, wybór jest oczywisty. Jeśli jest nim drugi kontrolowany serwer Linux, można użyć Borg, który często działa szybciej.

Pozostałe różnice mają mniejsze znaczenie. Oba programy dzielą pliki na fragmenty wyznaczane na podstawie zawartości, dlatego przesłanie katalogu o rozmiarze 40 GB, w którym zmieniło się 200 MB, obejmuje w przybliżeniu 200 MB. Oba programy szyfrują dane po stronie klienta. Oba umożliwiają zamontowanie migawki za pomocą FUSE (system plików w przestrzeni użytkownika), dzięki czemu można skopiować pojedynczy plik. W lipcu 2026 wersja Restic to 0.19.1, a stabilna seria Borg to 1.4, obecnie w wersji 1.4.5. Borg 2.0 od lat znajduje się w fazie beta i nadal jest oznaczony wyłącznie jako wersja testowa, dlatego obecnie należy wdrażać wersję 1.4.

Model repozytorium jest kluczową różnicą

Repozytorium restic jest katalogiem plików: config, keys/, snapshots/, index/ i data/, zawierającym pliki pakietów. Do jego odczytu nie jest potrzebne nic więcej. Dlatego restic może obsługiwać tak wiele backendów. Każdy magazyn, który umożliwia zapisywanie, pobieranie, wyświetlanie listy i usuwanie obiektów binarnych, może przechowywać repozytorium restic. Dzięki temu jeden plik binarny obsługuje ścieżki lokalne, SFTP, własny serwer REST, S3, Backblaze B2, Azure, Google Cloud Storage oraz wszystkie lokalizacje dostępne przez rclone.

Repozytorium Borg również składa się z plików na dysku, ale Borg nigdy nie komunikuje się z nim za pośrednictwem prostego transportu. W przypadku repozytorium zdalnego Borg uruchamia po drugiej stronie, przez SSH, borg serve i komunikuje się z tym procesem za pomocą własnego protokołu. Po stronie serwera wykonywane są rzeczywiste operacje: przechowywane jest repozytorium, stosowana jest transakcja i udzielane są odpowiedzi na zapytania dotyczące indeksu. Dlatego Borg nie ma backendu S3 i projekt go nie dodał. W zasobniku nie ma procesu, który można uruchomić.

Ten pojedynczy fakt konstrukcyjny powoduje większość opisanych poniżej różnic praktycznych.

# 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: jedno z rozwiązań można wyłączyć

Restic zawsze szyfruje dane. Nie ma trybu nieszyfrowanego. restic init żąda podania hasła, wyprowadza z niego klucz za pomocą scrypt, a każdy zapisany później plik pakietu jest szyfrowany i uwierzytelniany. Utrata hasła oznacza utratę danych, ponieważ z założenia nie ma mechanizmu ich odzyskiwania.

W Borg szyfrowanie wybiera się podczas tworzenia repozytorium. Tego wyboru nie można później zmienić. borg init --encryption=repokey przechowuje zaszyfrowany klucz w repozytorium, dlatego do odtworzenia wystarcza sama fraza hasła. --encryption=keyfile przechowuje klucz po stronie klienta w ~/.config/borg/keys/, dlatego osoba, która ukradnie całe repozytorium, nadal nie uzyska dostępu do danych. Należy więc utworzyć osobną kopię zapasową tego pliku klucza, ponieważ bez niego archiwów nie można odczytać. Każdy tryb ma wariant -blake2, który uwierzytelnia dane za pomocą BLAKE2b zamiast HMAC-SHA256. Jest to szybsze na sprzęcie bez akceleracji SHA. Dostępny jest również --encryption=none. Jest to właściwy wybór, gdy repozytorium znajduje się na zaszyfrowanym dysku należącym do użytkownika.

Praktyczna zasada: repokey-blake2 w przypadku standardowej kopii zapasowej serwera, keyfile, gdy repozytorium znajduje się w lokalizacji, której nie można w pełni ufać, oraz nigdy none na wynajętej maszynie.

Kompresja i powód, dla którego restic wprowadził ją późno

Borg obsługuje kompresję od początku. Domyślnie używany jest lz4, ponieważ jest wystarczająco szybki, aby pozostawić go włączonego dla wszystkich danych. zstd obsługuje poziomy od 1 do 22, a domyślnie używany jest poziom 3. zlib i lzma są przeznaczone do sytuacji, w których rozmiar danych jest ważniejszy niż czas wykonania. auto stosuje heurystykę dla każdego fragmentu, dzięki czemu dane już skompresowane nie są kompresowane ponownie.

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

Restic nie obsługiwał kompresji aż do formatu repozytorium 2, który wymaga restic 0.14.0 lub nowszego. Format 2 jest obecnie formatem domyślnym dla nowych repozytoriów, a kompresję ustawia się za pomocą --compression, używając wartości auto, off lub max. Stare repozytorium w formacie 1 pozostaje nieskompresowane do czasu jego migracji. Jeśli repozytorium restic powstało przed wersją 0.14 i nigdy nie zostało poddane migracji, tekst, logi i zrzuty baz danych nadal zajmują pełny rozmiar.

Zdalne cele: S3 a SSH

W tym miejscu zazwyczaj podejmuje się decyzję.

Restic potrzebuje do komunikacji z S3 danych uwierzytelniających w środowisku i nie wymaga uruchomienia żadnych dodatkowych usług. Ten sam schemat działa w przypadku samodzielnie hostowanego bucketa. Jest to często stosowane połączenie: należy uruchomić MinIO z interfejsem API S3 na własnym VPS i wskazać go w 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

Komunikacja Borg ze zdalnym repozytorium wymaga SSH oraz instalacji Borg po stronie zdalnej. Wersja po stronie zdalnej musi być zgodna z wersją klienta. Stanowi to utrudnienie, gdy zdalny system nie jest zarządzany samodzielnie. Nie stanowi problemu, gdy jest to drugi serwer już objęty administracją. Zapewnia też najsilniejszą ochronę przed ransomware spośród mechanizmów oferowanych przez oba narzędzia: klucz SSH tylko do dopisywania danych. Należy wymusić uruchamianie przez ten klucz polecenia borg serve. Klient może wtedy dodawać archiwa, ale nie może ich usuwać. Dzięki temu przejęty serwer nie może usunąć własnej historii.

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

Restic zapewnia odpowiednik tego mechanizmu tylko przy użyciu własnego serwera REST, który obsługuje tryb tylko do dopisywania danych. W przypadku zwykłego S3 taki sam efekt zapewnia polityka bucketa lub blokada obiektów. Jest to zadanie dostawcy, a nie restic. Należy również odpowiednio zabezpieczyć transport. Połączenie SSH wymaga takiej samej ochrony jak każde inne logowanie: należy zastosować SSH tylko z użyciem klucza i ograniczonym wpisem authorized_keys dla konta kopii zapasowych.

Szybkość: konsekwencje poszczególnych projektów

Żaden z projektów nie publikuje testu wydajności, któremu można ufać w przypadku własnych danych. Dlatego należy wnioskować na podstawie mechanizmu działania.

Borg over SSH działa szybko w sieci o dużych opóźnieniach, ponieważ część serwerowa jest inteligentna. Klient wysyła zapytanie, zdalny proces borg serve odpowiada na nie na podstawie indeksu repozytorium, a transakcja jest zatwierdzana w jednym miejscu. Wyszukiwanie fragmentów nie powoduje osobnych podróży przez sieć dla każdego małego pliku.

Restic w magazynie obiektowym nie ma części serwerowej. Musi więc odtworzyć stan na podstawie plików indeksów i plików pack pobieranych przez HTTP. Aby ograniczyć liczbę żądań, przed przesłaniem pakuje wiele małych fragmentów do większych plików pack. Ponadto przechowuje lokalną pamięć podręczną w ~/.cache/restic, aby podczas następnego uruchomienia nie pobierać ponownie całego indeksu. Po usunięciu tej pamięci podręcznej następna kopia zapasowa działa wolno, ponieważ pamięć podręczna jest odbudowywana. W sieci o dużych opóźnieniach i przy milionach małych plików restic działa wolniej niż Borg na tych samych danych.

Na dysku lokalnym lub w szybkiej sieci LAN różnica w dużej mierze zanika. W obu narzędziach ograniczeniem staje się szybkość odczytu i obliczania skrótów danych źródłowych.

Blokowanie i tworzenie kopii zapasowych kilku maszyn

Borg 1.4 zakłada wyłączną blokadę repozytorium na czas całej operacji. Jednoczesny zapis dwóch klientów do jednego repozytorium nie działa: drugi klient czeka, a następnie kończy działanie z powodu przekroczenia limitu czasu oczekiwania na blokadę. Obsługiwany schemat zakłada użycie jednego repozytorium na klienta. Oznacza to również, że deduplikacja odbywa się tylko w repozytorium jednej maszyny, dlatego dziesięć niemal identycznych serwerów przechowuje dziesięć kopii tego samego systemu bazowego.

Restic umożliwia jednoczesne tworzenie kopii zapasowych przez kilku klientów w jednym repozytorium, ponieważ tworzenie kopii wymaga blokady współdzielonej, a tylko zadania konserwacyjne, takie jak prune, wymagają blokady wyłącznej. Dziesięć podobnych serwerów wskazanych na jedno repozytorium restic wykonuje deduplikację względem siebie, dlatego drugi i kolejne serwery często przechowują bardzo mało danych. Ceną jest większy zakres skutków awarii: jedno hasło i jedno repozytorium zawierają wszystko, więc utrata hasła oznacza utratę danych ze wszystkich dziesięciu serwerów.

Retencja: forget i prune a prune i compact

Oba narzędzia oddzielają decyzję o tym, co zachować, od odzyskania miejsca. W obu przypadkach należy uruchomić drugi etap.

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

W obu narzędziach występuje ta sama pułapka, którą należy jasno wskazać. W Borg polecenie borg prune usuwa archiwa, ale samo nie zwalnia miejsca na dysku. Miejsce jest odzyskiwane po uruchomieniu borg compact. Dlatego zadanie cron, które wykonuje prune, ale nigdy nie uruchamia compact, powoduje nieograniczony wzrost repozytorium, mimo że lista archiwów pozostaje krótka. W restic użycie forget bez --prune usuwa tylko odwołania do migawek. Dane pozostają do czasu wykonania prune.

Po wykonaniu prune należy uruchomić restic check. Polecenie to weryfikuje struktury repozytorium i informuje o ewentualnym uszkodzeniu. Jest to znacznie lepsze rozwiązanie niż wykrycie problemu dopiero podczas przywracania danych.

Przywracanie — jedyny test, który ma znaczenie

Oba narzędzia montują migawkę, aby można było przeglądać jej zawartość. To najszybszy sposób na przywrócenie 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 w archiwum są przechowywane bez początkowego ukośnika, dlatego etc/nginx jest poprawne, a /etc/nginx niczego nie dopasowuje i niczego nie wypakowuje. Nie jest przy tym wyświetlany błąd wyjaśniający przyczynę. Wypakowywanie zapisuje również pliki w bieżącym katalogu roboczym. Dlatego najpierw należy przejść do katalogu roboczego przeznaczonego na testy. W przeciwnym razie stare pliki zastąpią pliki używane w systemie.

Niezależnie od wybranego narzędzia harmonogram to tylko połowa zadania. Należy uruchamiać przywracanie do katalogu roboczego przeznaczonego na testy zgodnie z harmonogramem, który jest faktycznie monitorowany, tak jak w pełnej instrukcji przewodnik tworzenia kopii zapasowych VPS za pomocą restic, gdzie używany jest timer systemd.

Które rozwiązanie sprawdza się w danym zastosowaniu

Należy wybrać restic, gdy miejscem docelowym jest magazyn obiektowy, wymagany jest jeden plik binarny i brak oprogramowania po stronie zdalnej, kilka maszyn powinno wspólnie korzystać z deduplikacji lub osoba wykonująca odtwarzanie może być inna niż osoba konfigurująca kopie zapasowe. Jest to pojedynczy statycznie linkowany plik binarny, któremu wystarczy adres URL repozytorium. Pod względem operacyjnym trudno znaleźć prostsze rozwiązanie.

Należy wybrać Borg, gdy miejscem docelowym jest kontrolowany serwer Linux, łącze charakteryzuje się dużymi opóźnieniami, a zbiór danych zawiera miliony małych plików, wymagany jest klucz SSH z uprawnieniem append only jako zabezpieczenie przed ransomware lub kompresja ma być dostosowywana do poszczególnych zadań. Jest to starsze narzędzie. Jego stabilna seria rozwija się powoli. W oprogramowaniu do tworzenia kopii zapasowych jest to zaleta.

Oba rozwiązania są poprawnym wyborem. Błędny wybór to ten, którego nigdy się nie testuje. Jeśli kopie aplikacyjne są już tworzone, należy je zachować. Wzorzec opisany w konfiguracji Nextcloud w Docker z kopiami baz danych ma zastosowanie do obu narzędzi, ponieważ plik aktywnie używanej bazy danych skopiowany w przypadkowym momencie nie jest kopią zapasową bazy danych.

FAQ

Czy restic czy BorgBackup jest szybszy?

Na dysku lokalnym lub w szybkiej sieci LAN ich wydajność jest zbliżona. W obu przypadkach ograniczeniem stają się szybkość odczytu i obliczania skrótów danych źródłowych. Borg zwykle wygrywa przez połączenie SSH o dużych opóźnieniach, gdy występuje bardzo wiele małych plików, ponieważ proces borg serve po stronie zdalnej odpowiada na zapytania dotyczące indeksu bez wykonywania osobnej operacji sieciowej dla każdego fragmentu. Restic zwykle wygrywa w przypadku magazynu obiektowego, z którym Borg w ogóle nie może pracować.

Czy BorgBackup może wykonywać kopie zapasowe do S3 lub Backblaze B2?

Nie bezpośrednio. Repozytorium Borg jest udostępniane przez proces borg serve za pośrednictwem SSH, a taki proces nie działa wewnątrz zasobnika. Stosowanym obejściem jest montowanie magazynu obiektowego jako systemu plików za pomocą rclone. Projekt Borg tego nie zaleca, ponieważ przerwanie montowania w trakcie transakcji może uszkodzić repozytorium. Jeśli potrzebny jest magazyn obiektowy, należy użyć restic.

Czy można uruchamiać oba narzędzia dla tych samych danych?

Tak. Niektórzy tak robią: Borg zapisuje kopię na drugim serwerze, aby umożliwić szybkie lokalne odtwarzanie, a restic zapisuje kopię magazynie obiektowym poza lokalizacją. Narzędzia nie współdzielą żadnych danych, dlatego koszt odczytu i obliczania skrótów jest ponoszony dwukrotnie. Należy także bezpiecznie przechowywać dwa hasła. Taką konfigurację należy stosować tylko po przetestowaniu obu procesów odtwarzania.

Co się stanie po utracie hasła do repozytorium?

W obu narzędziach dane będą niemożliwe do odzyskania. Restic wyprowadza klucz z hasła za pomocą scrypt i nie oferuje mechanizmu obejścia. Borg w trybie repokey przechowuje zaszyfrowany klucz wewnątrz repozytorium, dlatego do odtworzenia wystarcza hasło. W trybie keyfile potrzebny jest także plik klucza z ~/.config/borg/keys/. Hasło należy przechowywać w menedżerze haseł, który nie działa na serwerze objętym kopią zapasową. W przypadku używania keyfile należy wyeksportować klucz Borg za pomocą borg key export.

Czy należy czekać na Borg 2.0?

Nie. W lipcu 2026 Borg 2.0 nadal jest wersją beta, obecnie 2.0.0b22, a projekt oznacza ją jako przeznaczoną wyłącznie do testów. Stabilna seria to 1.4, obecnie 1.4.5. Należy rozpocząć od wersji 1.4. Borg 2 zmienia format repozytorium i udostępnia udokumentowaną ścieżkę aktualizacji, dlatego rozpoczęcie pracy już teraz nie uniemożliwi późniejszej migracji.