ResticとBorgBackupの比較：どちらを選ぶべきか？

Restic と BorgBackup の比較（1段落）

Restic と BorgBackup は、Linux サーバーの重複排除、暗号化、増分バックアップという中核機能が同じです。選択を決める違いは、バックアップの保存先です。Restic は S3 などのオブジェクトストレージ API にネイティブ対応しているため、保存先のマシンに何もインストールせず、バケットを主要な保存先として使用できます。安定版の Borg は、リポジトリを保持するマシンに borg プログラムをインストールする必要があります。Borg リポジトリは、ファイルシステムや API ではなく、プロセスによって提供されるためです。保存先がオブジェクトストレージなら、選択肢はすでに決まっています。管理下にある別の Linux マシンが保存先なら、Borg を使用でき、多くの場合はこちらのほうが高速です。

その他の違いは、より小さいものです。どちらもコンテンツ定義チャンク分割を使用するため、40 GB のディレクトリ内で変更されたデータが 200 MB だけなら、アップロード量はおよそ 200 MB です。どちらもクライアント側で暗号化します。どちらも FUSE（ユーザー空間ファイルシステム）でスナップショットをマウントできるため、1 個のファイルを取り出せます。2026 年 10 月時点で、Restic は 0.19.1、Borg の安定版系列は 1.4 で、最新バージョンは 1.4.5 です。Borg 2.0 は何年もベータ版のままで、現在も testing only と表示されています。そのため、現時点でデプロイすべきなのは 1.4 です。

リポジトリモデルが本質的な違いです

restic リポジトリは、config、keys/、snapshots/、index/、data/ というファイルのディレクトリで構成され、pack ファイルを格納します。これを読み取るために、ほかの要素は必要ありません。そのため、restic は非常に多くのバックエンドに対応できます。blob の配置、取得、一覧表示、削除ができるストレージであれば、restic リポジトリを格納できます。これにより、1 つのバイナリでローカルパス、SFTP、独自の REST サーバー、S3、Backblaze B2、Azure、Google Cloud Storage、および rclone でアクセスできる任意のストレージを扱えます。

Borg リポジトリもディスク上のファイルですが、Borg は単純な転送方式でリポジトリに接続することはありません。リモートリポジトリの場合、Borg は SSH 経由で接続先で borg serve を起動し、そのプロセスと独自のプロトコルで通信します。サーバー側では実際の処理を実行します。リポジトリを保持し、トランザクションを適用し、インデックスに関する問い合わせに応答します。これが、安定版の Borg 1.4 系列に S3 バックエンドがない理由です。バケット内で実行するプロセスが存在しないためです。Borg 2 ではこの点が変更され、ストレージを borgstore という新しい層に移しています。ドキュメントでは、sftp://、rclone:remote:path、s3:、または b2: のリポジトリ URL について説明しています。ただし、Borg 2 は現在もベータ版であり、プロジェクトは本番環境で使用しないよう案内しています。そのため、現在実運用でバックアップを取る場合、S3 に対応していないという問題は依然として残ります。

この単一の設計上の違いが、以下に示す実用面での違いの大半を生みます。

# 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

暗号化：片方は無効化が可能

Restic は常に暗号化されます。暗号化を無効にするモードは存在しません。restic init はパスワードを要求し、scrypt を用いてそこから鍵を生成します。その後書き込まれるすべてのパックファイルは暗号化され、認証が付与されます。設計上、復旧経路は存在しないため、パスワードを紛失するとデータは失われます。

Borg はリポジトリ作成時に暗号化の有無を選択でき、その選択は永続的です。borg init --encryption=repokey は暗号化された鍵をリポジトリ内に保持するため、パスフレーズのみで復元が可能です。--encryption=keyfile は鍵をクライアント側の ~/.config/borg/keys/ に保持します。そのため、リポジトリ全体が盗まれても中身は保護されますが、その鍵ファイルを別途バックアップしておかなければアーカイブは読み取り不能になります。各モードには -blake2 バリアントが存在し、HMAC-SHA256 の代わりに BLAKE2b で認証を行います。これは SHA 加速機能のないハードウェアで高速に動作します。--encryption=none も存在し、リポジトリが自身で管理する暗号化ディスク上に配置されている場合には現実的な選択肢となります。

実用上のルール：通常のサーバーバックアップには repokey-blake2 を、完全に信頼できない場所にリポジトリを置く場合は keyfile を使用してください。レンタルサーバー上では決して none を選択しないでください。

圧縮と、restic での対応が遅れた理由

Borg は当初から圧縮に対応しています。デフォルトは lz4 です。十分に高速なため、常に有効にしておけます。zstd はレベル 1 から 22 を受け付け、デフォルトは 3 です。zlib と lzma は、処理時間よりバイト数を重視する場合に使用します。auto はチャンクごとにヒューリスティックな判定を行うため、すでに圧縮されたデータを二重に圧縮しません。

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

Restic は repository format 2 まで、圧縮に対応していませんでした。repository format 2 には restic 0.14.0 以降が必要です。現在、新しい repository では format 2 がデフォルトです。圧縮は --compression により、次の 5 つの値のいずれかに設定します。auto（デフォルト）、off、fastest、better、max です。fastest と better のモードは restic 0.19.0 で追加されました。そのため、古いバイナリでは auto、off、max だけを指定できます。古い format 1 repository は、移行するまで圧縮されません。したがって、restic repository が 0.14 より前に作成され、移行していない場合、テキスト、ログ、データベースダンプに対して現在も圧縮前のサイズ分の容量を消費します。

リモートターゲット: S3 と SSH の比較

ここが選択の分かれ目となります。

restic が S3 に接続する場合、環境変数に認証情報を設定するだけで済み、リモート側で実行するプロセスは不要です。このパターンは自身でホストするバケットに対しても有効であり、VPS 上で S3 API を提供する MinIO を構築し、そこに 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 がリモートリポジトリに接続するには、SSH に加えてリモート側にも Borg がインストールされている必要があり、クライアントとバージョンに互換性が求められます。リモート側が自身の管理下でない場合、これは障壁となります。しかし、自身で管理している別のサーバーであれば問題はなく、両ツールの中で最も強力なランサムウェア対策である「追記のみ許可する SSH 鍵」を利用できます。SSH 鍵に borg serve を強制することで、クライアントはアーカイブの追加はできても削除はできなくなります。これにより、侵害されたマシンが自身のバックアップ履歴を消去することを防げます。

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

restic で同等の機能を実現するには、追記のみモードをサポートする独自の REST サーバーを運用する必要があります。通常の S3 を使用する場合は、バケットポリシーやオブジェクトロックによって同様の効果を得られますが、これは restic ではなくプロバイダー側の役割です。SSH 接続についても他のログインと同様の注意が必要なため、バックアップ用アカウントには 制限付き authorized_keys を使用した鍵認証のみの SSH を適用し、通信経路を保護してください。

速度：各設計が意味するもの

どちらのプロジェクトも、ユーザー自身のデータで信頼できるベンチマークを公開していません。そのため、仕組みから推論する必要があります。

Borg over SSH は、サーバー側がインテリジェントであるため、レイテンシのある回線でも高速に動作します。クライアントが問い合わせを行うと、リモートの borg serve プロセスがリポジトリインデックスから回答し、トランザクションがその場でコミットされます。小さなファイルごとにネットワークの往復が発生するようなチャンク検索は行われません。

オブジェクトストレージ上の Restic にはサーバー側が存在しないため、HTTP 経由で取得したインデックスファイルとパックファイルから状況を構築する必要があります。リクエスト数を抑えるため、アップロード前に多数の小さなチャンクを大きなパックファイルにまとめ、~/.cache/restic にローカルキャッシュを保持することで、次回の実行時にインデックス全体を再取得しないようにしています。このキャッシュを削除すると、再構築のために次回のバックアップが低速になります。数百万の小さなファイルがある高レイテンシの回線では、同じデータであっても Restic が Borg よりも遅く感じられるケースです。

ローカルディスクや高速な LAN ではこの差はほとんど埋まり、どちらのツールもソースの読み取りとハッシュ化の速度によって制限されることになります。

ロックと複数マシンのバックアップ

Borg 1.4 は操作全体を通じてリポジトリを排他的にロックします。2 台のクライアントが同時に 1 つのリポジトリへ書き込むことはできません。2 台目は待機したのち、ロックのタイムアウトにより失敗します。サポートされている構成は、クライアントごとに 1 つのリポジトリを割り当てる方法です。これは重複排除が単一マシンのリポジトリ内でのみ行われることを意味するため、10 台のほぼ同一なサーバーは、同じベースシステムのコピーを 10 個保存することになります。

Restic は複数のクライアントが同時に 1 つのリポジトリへバックアップすることを許可しています。バックアップは共有ロックを取得し、prune のようなメンテナンス作業のみが排他的ロックを取得するためです。10 台の類似したサーバーを 1 つの restic リポジトリに向けると相互に重複排除が行われるため、2 台目以降のサーバーが保存するデータ量は非常に少なくなることがよくあります。その代償として影響範囲が広がります。1 つのパスワードと 1 つのリポジトリにすべてが集約されるため、パスワードを紛失すると 10 台分すべてのデータが失われます。

保持期間: forget と prune、あるいは prune と compact

両ツールとも「何を保持するか」の決定と「領域の解放」を分離しており、どちらも 2 番目のステップを実行する必要があります。

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

両ツールに共通する落とし穴であり、明確に述べておく価値があります。Borg では、borg prune はアーカイブを削除しますが、それ自体ではディスク領域を解放しません。borg compact を実行することで領域が戻るため、prune を行い compact を行わない cron ジョブを運用すると、アーカイブリストは短いままリポジトリが肥大化し続けます。Restic では、--prune を伴わない forget はスナップショットの参照を削除するだけであり、prune が実行されるまでデータは残ります。

prune の後には restic check を実行することを推奨します。リポジトリの構造を検証し、破損の有無を通知します。これは復元時に破損を知るよりもはるかに優れた方法です。

復元：唯一の有効なテスト

どちらのツールもスナップショットをマウントして中身を閲覧できます。これが単一のファイルを素早く取り出す最も速い方法です。

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

borg extract でのパスの指定方法に注意してください。アーカイブ内のパスは先頭のスラッシュなしで保存されるため、etc/nginx が正しく、/etc/nginx は何も一致せず、エラーも表示されずに何も抽出されません。また、抽出処理は現在の作業ディレクトリに対して行われるため、古いファイルで現在のファイルを上書きしないよう、事前に作業用ディレクトリへ移動してください。

エラーなしで復元が完了しても、それが成功の証明にはなりません。その上で動作するアプリケーションには、何をもって「完全な復元」とするかという独自の基準があるためです。例えば、Postgres のデータディレクトリのコピーから再構築した Immich サーバーは、ディスク上の全写真は存在していても、タイムラインには何も表示されない状態で起動します。これこそが Immich のバックアップと復元 で回避策を講じる必要がある障害です。

どのツールを選ぶにせよ、スケジュール設定は作業の半分に過ぎません。restic による VPS バックアップガイド で解説されているように、systemd タイマーを使用して、実際に監視可能な間隔で作業用ディレクトリへの復元テストを実行してください。

用途に応じたツールの選択

オブジェクトストレージをバックアップ先とする場合、単一のバイナリのみで完結させたい場合、複数のマシン間で重複排除を行いたい場合、あるいは自分以外の誰かがリストアを行う可能性がある場合は、restic を選択してください。restic はリポジトリの URL を指定するだけで動作する単一の静的バイナリであり、運用面でこれに勝るものはほとんどありません。

管理下の Linux サーバーをバックアップ先とする場合、ネットワークの遅延がある環境で数百万もの小さなファイルを扱う場合、ランサムウェア対策として追記専用の SSH 鍵を利用したい場合、あるいはジョブごとに圧縮設定を調整したい場合は、Borg を選択してください。Borg は歴史あるツールであり、安定版の更新は緩やかです。バックアップソフトウェアにおいて、この安定性は大きな利点となります。

どちらを選択しても正解です。誤った選択とは、一度もテストを行わないことです。すでにアプリケーションレベルのダンプを取得している場合は、それを継続してください。データベースダンプを用いた Docker 上の Nextcloud セットアップで示されているパターンは、どちらのツールにも適用できます。稼働中のデータベースファイルをランダムなタイミングでコピーしただけでは、データベースのバックアップとは呼べないためです。

FAQ

restic と BorgBackup ではどちらが高速ですか？

ローカルディスクや高速な LAN では大きな差はなく、どちらも最終的にはバックアップ元の読み取り速度とハッシュ計算速度に制限されます。非常に多くの小さなファイルを高遅延の SSH 接続経由で扱う場合は、Borg が有利になりやすくなります。遠隔側の borg serve プロセスがインデックスへの問い合わせに応答するため、チャンクごとにネットワーク往復が発生しないためです。保存先がオブジェクトストレージの場合は、安定版の Borg では対応できないため、restic が有利です。

BorgBackup で S3 または Backblaze B2 にバックアップできますか？

安定版の 1.4 系列ではできません。Borg 1.4 のリポジトリは SSH 経由で borg serve プロセスが提供しますが、バケット内でそのようなプロセスは動作しません。Borg 2 では borgstore レイヤーを通じて s3:、b2:、rclone: のリポジトリ URL が追加されます。ただし 2026 年 10 月時点で Borg 2 はまだ beta であり、プロジェクトは本番環境で使用しないよう案内しています。1.4 では、rclone を使ってオブジェクトストレージをファイルシステムとしてマウントし、この差を補う方法があります。Borg FAQ はリポジトリの保存先としてネットワークファイルシステムを使用しないよう勧告しており、FUSE やネットワークファイルシステムによって速度低下や破損が発生する可能性があると警告しています。現在、本番バックアップにオブジェクトストレージが必要であれば、restic を使用してください。

2 つのツールを同じデータに対して実行できますか？

できます。実際に、迅速なローカルリストア用に Borg で 2 台目のサーバーへ保存し、オフサイトコピー用に restic でオブジェクトストレージへ保存する運用もあります。両者は何も共有しないため、読み取りとハッシュ計算のコストを 2 回負担します。また、安全に保管するパスワードも 2 つ必要です。両方のリストアをテスト済みの場合にだけ、この構成を使用してください。

リポジトリのパスワードを失うとどうなりますか？

どちらのツールでも、データを復旧できなくなります。restic は scrypt でパスワードから鍵を導出し、回避策はありません。Borg の repokey モードでは暗号化された鍵がリポジトリ内に保存されるため、パスフレーズだけでリストアできます。一方、keyfile モードでは ~/.config/borg/keys/ の鍵ファイルも必要です。パスワードは、バックアップ対象のサーバー上に存在しないパスワードマネージャーで管理してください。keyfile を使用する場合は、borg key export で Borg の鍵をエクスポートしてください。

Borg 2.0 を待つべきですか？

いいえ。2026 年 10 月時点で Borg 2.0 はまだ beta であり、2.0.0b25（2026 年 9 月 27 日リリース）です。プロジェクトもテスト専用と位置付けています。安定版の系列は 1.4 で、現在のバージョンは 1.4.5 です。今すぐ 1.4 で開始してください。Borg 2 ではリポジトリ形式が変更されますが、文書化されたアップグレード手順（borg transfer --from-borg1）が提供されるため、今始めても将来利用できなくなることはありません。Borg 2 では、安定版になった後に、S3、B2、rclone のネイティブサポートも追加されます。