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は何年もベータ版のままで、現在もテスト専用と表示されています。そのため、現在デプロイすべきなのは1.4です。

リポジトリモデルが実際の違いです

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

Borg リポジトリもディスク上のファイルですが、Borg は単純な転送方式でリポジトリと通信しません。リモートリポジトリの場合、Borg は SSH 経由で接続先で borg serve を起動し、そのプロセスと独自のプロトコルで通信します。server 側は実際の処理を行います。リポジトリを保持し、トランザクションを適用し、インデックスに関する問い合わせに応答します。このため、Borg には S3 バックエンドがなく、プロジェクトも追加していません。bucket 内で実行するプロセスが存在しないためです。

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

# 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 file は、暗号化および認証されます。パスワードを失うと、データは失われます。設計上、復旧手段がないためです。

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は、リポジトリ形式2まで圧縮に対応していませんでした。リポジトリ形式2にはrestic 0.14.0以降が必要です。現在、新しいリポジトリでは形式2がデフォルトです。圧縮は--compressionにauto、off、またはmaxを指定して設定します。古い形式1のリポジトリは、移行するまで圧縮されません。そのため、resticリポジトリが0.14より前に作成され、移行していない場合は、テキスト、ログ、データベースダンプに対して現在も完全なサイズ分の容量を使用しています。

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

通常、ここで選択が決まります。

Restic で S3 に接続するには、環境変数に認証情報を設定するだけで済みます。どこかで別のサービスを実行する必要はありません。同じ構成を、自分でホストする bucket にも使用できます。これは一般的な組み合わせです。自分の 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 でリモート repository に接続するには、SSH と接続先での Borg のインストールが必要です。接続先のバージョンはクライアントと互換性がなければなりません。接続先を自分で管理していない場合、これは負担になります。すでに管理している2台目のサーバーであれば問題ありません。また、どちらのツールでも ransomware に対して最も強力な制御手段である、追記専用の SSH key を利用できます。key に borg serve の実行を強制すると、クライアントは archive を追加できますが、削除はできません。そのため、侵害されたマシンから自分の履歴を消去できません。

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

Restic で同等の構成にするには、追記専用モードをサポートする独自の REST server を実行する必要があります。通常の S3 に対しては、bucket policy または object lock で同じ効果を得られます。これは restic ではなく provider 側の機能です。転送も制限してください。SSH 側も通常の login と同じ注意が必要です。backup account には、key のみを使用し restricted な authorized_keys エントリを設定する SSHを適用します。

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

どちらのプロジェクトも、自分のデータで信頼できるベンチマークを公開していません。そのため、仕組みから判断してください。

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

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

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

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

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

Resticでは、複数のクライアントが同じリポジトリに同時にバックアップできます。バックアップでは共有ロックを取得し、pruneなどのメンテナンス処理だけが排他的ロックを取得するためです。同じresticリポジトリを指定した類似サーバー10台では、相互に重複排除が行われます。そのため、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バックアップガイドの残りの手順と同じように、実際に監視するタイマーでスクラッチディレクトリへの復元を実行してください。

どの用途にどちらが適しているか

保存先がオブジェクトストレージの場合、1つのバイナリだけを使い、接続先にソフトウェアを配置したくない場合、複数のマシン間で重複排除したい場合、または復元を担当する人が自分とは限らない場合は、resticを選びます。リポジトリのURLを指定して使える単一の静的バイナリであり、運用面でこれに勝るものは多くありません。

保存先が自分で管理するLinuxボックスの場合、リンクに遅延がありデータセットに数百万個の小さなファイルが含まれる場合、ランサムウェア対策として追記専用の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で別のサーバーへ保存し、オフサイトコピー用に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ではリポジトリ形式が変更され、文書化されたアップグレード手順も提供されます。そのため、今日開始しても将来移行できなくなることはありません。