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

Restic と BorgBackup の比較

Restic と BorgBackup は、どちらも Linux サーバーの重複排除、暗号化、増分バックアップという主要な機能を備えています。選択の決め手となるのはバックアップ先の要件です。Restic は S3 などのオブジェクトストレージ API をネイティブでサポートしているため、バックアップ先で特別なソフトウェアを動かすことなく、バケットを直接ターゲットにできます。一方、Borg はリポジトリを保持するマシン側にも borg プログラムのインストールが必要です。これは Borg リポジトリがファイルシステムや API ではなく、プロセスによって提供されるためです。バックアップ先がオブジェクトストレージであれば Restic が適しています。管理下の別の Linux サーバーをバックアップ先とする場合は Borg が選択肢に入り、多くの場合こちらの方が高速です。

その他の違いは些細なものです。両者ともコンテンツ定義チャンク分割を行うため、40 GB のディレクトリで 200 MB の変更があれば、アップロードされるデータ量も約 200 MB に抑えられます。どちらもクライアント側で暗号化を行い、FUSE (filesystem in userspace) を介してスナップショットをマウントし、個別のファイルを抽出することも可能です。2026 年 7 月現在、restic は 0.19.1、Borg の安定版シリーズは 1.4.5 です。Borg 2.0 は長年ベータ版でありテスト目的とされているため、現時点での運用には 1.4 を選択すべきです。

リポジトリモデルこそが真の違い

restic のリポジトリは、config、keys/、snapshots/、index/、および data/ といったパックファイルで構成されるディレクトリです。読み取りに必要なものはこれら以外にありません。これが、restic が非常に多くのバックエンドを扱える理由です。Blob の保存、取得、一覧表示、削除が可能なストレージであれば、どのようなものでも restic リポジトリとして機能します。この仕組みにより、単一のバイナリでローカルパス、SFTP、独自の 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 を用いてそこから鍵を生成します。その後書き込まれるすべてのパックファイルは暗号化され、認証が付与されます。設計上、復旧経路は存在しないため、パスワードを紛失するとデータは失われます。

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 は、restic 0.14.0 以降で必要となるリポジトリフォーマット 2 になるまで、圧縮機能を一切備えていませんでした。現在、新規リポジトリではフォーマット 2 がデフォルトであり、圧縮は --compression を使用して auto、off、または max の値で設定されます。古いフォーマット 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 がインストールされている必要があり、クライアントとバージョンに互換性が求められます。リモート側が自身の管理下でない場合、これは障壁となります。しかし、自身で管理している別のサーバーであれば問題はなく、両ツールの中で最も強力なランサムウェア対策である「追記のみ許可する 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 台目のクライアントは待機した後にロックタイムアウトで失敗します。推奨される運用パターンは、クライアントごとにリポジトリを分けることです。これは、重複排除が単一マシンのリポジトリ内でのみ行われることを意味するため、ほぼ同一のサーバーが 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 を実行してください。これはリポジトリ構造を検証し、破損があれば通知してくれます。復元時に初めて破損を知るよりも、この方法がはるかに安全です。

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

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

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 環境では両者に大きな差はなく、いずれもソース側の読み取り速度とハッシュ計算速度がボトルネックとなります。Borg は、多数の小さなファイルが存在する高レイテンシな SSH リンクにおいて優位です。これは、リモート側の borg serve プロセスがネットワークのラウンドトリップを発生させずにインデックスの問い合わせに応答できるためです。一方、ターゲットがオブジェクトストレージである場合は restic が有利です。Borg はオブジェクトストレージを直接サポートしていません。

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

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

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

はい、可能です。実際に、高速なローカル復元のために Borg で別のサーバーへバックアップし、オフサイトコピーとして 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 ではリポジトリ形式が変更されますが、公式にドキュメント化されたアップグレード手順が提供される予定であるため、今から始めても将来的に移行できなくなることはありません。