ResticとBorgBackupの違いと選び方

Restic と BorgBackup の違いを 1 つの段落で

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

その他の違いは比較的小さいものです。どちらも内容に基づくチャンク分割でファイルを分割するため、40 GB のディレクトリで 200 MB だけ変更された場合、アップロード量はおよそ 200 MB です。どちらもクライアント側で暗号化します。どちらも FUSE（ユーザー空間ファイルシステム）でスナップショットをマウントできるため、そこから 1 つのファイルをコピーできます。2026 年 7 月時点で、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、restic 独自の REST サーバー、S3、Backblaze B2、Azure、Google Cloud Storage、さらに rclone がアクセスできる任意のストレージを扱えます。

Borg リポジトリもディスク上のファイルですが、Borg は単純な転送方式でリポジトリに接続することはありません。リモートリポジトリの場合、Borg は SSH 経由で接続先に borg serve を起動し、そのプロセスと独自プロトコルで通信します。サーバー側では実際の処理を行います。リポジトリを保持し、トランザクションを適用し、インデックスに関する問い合わせに応答します。これが、Borg に 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 でそのパスワードから鍵を導出します。その後に書き込まれるすべての pack ファイルは、暗号化および認証されます。パスワードを失うと、データは失われます。設計上、復旧手段がないためです。

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 以降が必要です。現在、新しいリポジトリでは format 2 がデフォルトで使用され、圧縮は --compression に auto、off または max を指定して設定します。古い format 1 のリポジトリは、移行するまで圧縮されません。したがって、restic リポジトリが 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 インストールが必要です。接続先のバージョンは、クライアントと互換性がなければなりません。接続先を自分で管理していない場合、これは運用上の負担になります。すでに管理している 2 台目のサーバーであれば問題ありません。さらに、どちらのツールでもランサムウェア対策として最も強力な制御を実現できます。それが append only の SSH key です。key に borg serve を実行させるよう強制すると、クライアントはアーカイブを追加できますが、削除はできません。そのため、侵害されたマシンから自身の履歴を消去できません。

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

restic で同等の機能を利用できるのは、append only モードをサポートする専用の REST server を実行する場合だけです。通常の S3 に対しては、bucket policy または object lock によって同じ効果を得られます。これはプロバイダー側の機能であり、restic の機能ではありません。転送経路も制限してください。SSH 側も他のログインと同じように慎重に扱う必要があります。バックアップアカウントに対して、key のみを使用する SSH と制限付きの authorized_keys エントリを適用します。

速度: 各設計が意味すること

どちらのプロジェクトも、利用するデータに適用できる信頼性の高いベンチマークを公開していません。そのため、仕組みから判断します。

Borg over SSH は、サーバー側が処理を担うため、遅延のあるネットワークでも高速です。クライアントが問い合わせると、リモートの borg serve プロセスがリポジトリのインデックスから回答し、トランザクションを 1 か所でコミットします。チャンクの検索のたびに、小さなファイルごとのネットワーク往復が発生することはありません。

オブジェクトストレージ上の Restic にはサーバー側の処理機能がないため、HTTP 経由で取得したインデックスファイルと pack ファイルから状態を組み立てる必要があります。リクエスト数を抑えるため、アップロード前に多数の小さなチャンクを大きな pack ファイルへまとめます。また、次回の実行時にインデックス全体を再取得しないよう、~/.cache/restic にローカルキャッシュを保持します。このキャッシュを削除すると、次回のバックアップではキャッシュの再構築に時間がかかり、処理が遅くなります。遅延の大きいネットワークで数百万の小さなファイルを扱う場合、同じデータでは Restic が Borg より遅く感じられます。

ローカルディスクや高速な LAN では差がほぼなくなり、どちらのツールも最終的には、ソースを読み取り、ハッシュを計算する速度に制限されます。

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

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

Restic では、1 つのリポジトリに複数のクライアントが同時にバックアップできます。バックアップでは共有ロックだけを取得し、prune などのメンテナンス処理だけが排他的ロックを取得するためです。似た構成のサーバー 10 台を 1 つの restic リポジトリに接続すると、サーバー間でも重複排除されます。2 台目以降のサーバーでは、保存されるデータ量が非常に少なくなることがあります。代わりに、障害時の影響範囲が大きくなります。すべてのデータを 1 つのリポジトリに集約し、パスワードも 1 つになるため、そのパスワードを失うと 10 台分すべてを失います。

保持期間: forget と prune、または prune と compact

どちらのツールも、「保持するものを決める」処理と「空き容量を回収する」処理を分けており、後者を別途実行する必要があります。

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 を実行してください。リポジトリの構造を検証でき、破損の有無も確認できます。復元時に初めて破損を知るより、はるかに安全です。

復元が唯一意味のあるテストです

どちらのツールでもスナップショットをマウントして内容を参照できます。これは、1 個のファイルを最も速く復元する方法です。

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 は何にも一致せず、何も展開されません。理由を示すエラーも出ません。展開先は現在の作業ディレクトリでもあるため、最初にスクラッチディレクトリへ移動してください。そうしないと、稼働中のファイルを古いファイルで上書きします。

どちらのツールを選んでも、スケジュール設定は作業の半分にすぎません。実際に監視しているタイマーでスクラッチディレクトリへ復元を実行してください。VPS 向け restic バックアップガイドの後半にある完全な手順と同様に、systemd timer を使用します。

どちらをどの用途に選ぶか

保存先がオブジェクトストレージの場合、実行ファイルを 1 つにまとめたい場合、遠隔側にソフトウェアをインストールしたくない場合、複数のマシン間で重複排除したい場合、または復元を担当する人が自分とは限らない場合は、restic を選びます。リポジトリの URL を指定して使える単一の static binary であり、運用面では非常に扱いやすい構成です。

保存先が管理下の Linux ボックスの場合、リンクのレイテンシが大きくデータセットに数百万個の小さなファイルが含まれる場合、ランサムウェア対策として append only の SSH key を制御に使いたい場合、またはジョブごとに圧縮方式を調整したい場合は、Borg を選びます。Borg はより古いツールで、安定版の系列もゆっくり更新されます。バックアップソフトウェアでは、これは長所です。

どちらも正しい選択です。誤った選択は、テストしていないものです。すでにアプリケーションレベルの dump を取得している場合は、その運用を続けてください。データベース dump を含む Nextcloud on Docker の構成のパターンはどちらのツールにも適用できます。稼働中のデータベースファイルを任意の時点でコピーしても、データベースのバックアップにはならないためです。

FAQ

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

ローカルディスクまたは高速な LAN では両者に大きな差はなく、どちらもソース側の読み取り速度とハッシュ計算速度がボトルネックになります。非常に多くの小さなファイルを高遅延の SSH 接続経由で処理する場合は、Borg が有利になる傾向があります。これは、遠隔側の borg serve プロセスがインデックスの問い合わせに応答するため、チャンクごとにネットワーク往復が発生しないからです。保存先がオブジェクトストレージの場合は、Borg は利用できないため、restic が有利です。

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

直接はできません。Borg リポジトリは SSH 経由で borg serve プロセスによって提供されますが、バケット内でそのようなプロセスは実行されません。rclone を使ってオブジェクトストレージをファイルシステムとしてマウントする回避策はありますが、Borg プロジェクトは推奨していません。トランザクションの途中でマウントが切断されると、リポジトリが破損する可能性があるためです。オブジェクトストレージが必要な場合は、restic を使用してください。

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

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

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

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

Borg 2.0 を待つべきですか？

いいえ。2026 年 7 月時点で、Borg 2.0 はまだベータ版で、バージョンは 2.0.0b22 です。プロジェクトもテスト用途のみと位置付けています。安定版系列は 1.4 で、現在のバージョンは 1.4.5 です。今すぐ 1.4 で始めてください。Borg 2 ではリポジトリ形式が変更されますが、文書化されたアップグレード手順が提供されているため、現在始めても将来利用できなくなることはありません。