バックアップにresticが選ばれる理由｜Borg・Kopiaとの違い

サーバーやクラウド上のデータを守るために、これまで cron と tar や rsync を組み合わせたスクリプトでしのいできた。しかし暗号化されていない、容量がどんどん膨らむ、復元できるか確証が持てない——こうした不安を抱えながら運用しているインフラ担当の方は少なくないはずです。

専任のバックアップ基盤を持たない中小企業やスタートアップでは、一人のエンジニアがサーバー運用を抱えながら「本格的なバックアップツールを導入したいが、何を選べばいいか分からない」という状況に陥りがちです。OSS のバックアップツールを調べ始めると、restic・BorgBackup・Kopia といった候補が次々と出てきて、それぞれの違いがつかめないまま判断に迷ってしまいます。

本記事では、Go 製のバックアップ OSS である「restic」を取り上げ、その仕組み（重複排除・暗号化・スナップショット）と、近いツールである BorgBackup・Kopia との違いを整理します。最終的に「自分の環境には restic が合うのか、それとも別のツールが合うのか」を根拠を持って判断できる状態を目指します。

なお本記事は restic の公式 README・公式ドキュメント・公式サイトといった一次情報をもとに構成しており、筆者が動作検証やインストールを行った内容ではありません。記載した数値・仕様はいずれも公式情報の確認時点（2026年6月）のものです。

resticとは｜「バックアップを正しく行う」ための単一バイナリOSS

resticが解決する課題と設計原則

restic は「Fast, secure, efficient backup program（高速・安全・効率的なバックアッププログラム）」と自らを位置づける OSS です。公式サイトのキャッチコピーは「Backups done right!（バックアップを正しく行う）」で、バックアップという作業にありがちな「設定が複雑」「暗号化が面倒」「本当に復元できるか不安」といった摩擦を取り除くことを目指しています（restic 公式サイト）。

restic の特徴は、サーバーや複雑なセットアップを必要とせず、単一の実行ファイルとして動作する点にあります。対応 OS は Linux・macOS・Windows の主要 3 プラットフォームに加え、FreeBSD・OpenBSD などにも対応しています。

公式 README では、restic が以下の 5 つの設計原則を掲げていることが示されています（restic README）。

この 5 原則のなかでも「Verifiable（検証可能）」を明示的に掲げている点は、バックアップツールとしての思想がよく表れています。バックアップは取ること自体が目的ではなく、いざというときに確実に復元できることが本質である、という前提に立っているわけです。

リポジトリ基本情報（言語/ライセンス/スター数/メンテ状況）

採用判断にあたっては、ツールそのものの素性とメンテナンス状況の確認が欠かせません。restic のリポジトリ（restic/restic）の基本情報は以下のとおりです。

スター数は 34,583 と、バックアップ系 OSS のなかでも非常に大きな規模で、リポジトリ名で指名検索が成立するほど認知されています。ライセンスは BSD-2-Clause で、商用利用を含め柔軟に扱えます。

メンテナンス状況の観点では、リポジトリはアーカイブされておらず（archived = false）、フォーク版でもなく（fork = false）、無効化もされていません（disabled = false）。最終 push は 2026年6月14日と直近であり、現在も活発に開発が継続されている健全なプロジェクトであると確認できます。「採用後に開発が止まってしまわないか」という不安に対しては、現時点では前向きに評価できる状態です。

Go 製であることは、運用面でも見逃せない利点です。後述するように restic は単一バイナリで配布されるため、ランタイムや依存ライブラリのインストールが不要で、サーバーへの導入が容易です。

resticの仕組み｜重複排除・暗号化・スナップショットを理解する

restic が「効率的」かつ「安全」と言えるのは、重複排除と暗号化、そしてスナップショットという 3 つの仕組みに支えられているからです。採用の技術的な根拠を得るために、それぞれの内部実装を見ていきます。

重複排除の仕組み（CDC・SHA-256・増分）

restic はバックアップ対象のデータを書き込む前に重複排除（deduplication）を行います。この際に使われるのが、コンテンツ定義チャンキング（CDC, content-defined chunking）という手法です。

CDC では、ファイルを固定長ではなく内容に応じた可変長のチャンク（塊）に分割します。各チャンクは SHA-256 ハッシュで識別され、同一のチャンクが複数のファイルや複数のスナップショットに現れても、リポジトリには 1 度だけ保存されます。これにより、同じデータを何度もバックアップしてもストレージ消費は最小限に抑えられます。

固定長分割ではなく内容ベースで分割する点が重要で、ファイルの先頭に数バイト追加したりリネームしたりしても、チャンク全体が無効化されることがありません。変更があった部分のチャンクだけが新たに保存されるため、日々のバックアップで「増分のみを消費する」という設計原則が実現されます。

暗号化の仕組みと対象範囲（AES-256/Poly1305/scrypt）

restic はリポジトリに保存する全データをデフォルトで暗号化します。公式リファレンスによると、暗号化方式は AES-256 のカウンターモード（CTR）で、メッセージ認証には Poly1305-AES が使われます。鍵の導出には scrypt という鍵導出関数（KDF）が用いられ、ユーザーが入力したリポジトリパスワードと各種パラメータから鍵が生成されます（restic 公式リファレンス）。

ここで採用判断上とくに重要なのが、暗号化の対象範囲です。restic ではファイルの内容だけでなく、ファイル名やディレクトリ構造といったメタデータも暗号化されます。公式リファレンスには次のように記載されています。

Apart from the files stored within the keys and data directories, all files are encrypted with AES-256

出典: restic 公式リファレンス

つまり、保存先のストレージ管理者がリポジトリの中身を覗いても、どんなファイルが・どんなディレクトリ構造で保存されているかすら分からない、ということです。これは設計原則の「Secure（安全）」、すなわち「保存先を信頼できない環境と想定する」という思想を具体化したものです。S3 のような外部クラウドストレージにバックアップを置く場合、この設計は大きな安心材料になります。

一方で、暗号化はパスワードに依存します。リポジトリのパスワードを紛失すると、データは復元不能になります。この点は採用前に運用ルールとして固めておくべき注意点です（後述の「まとめ」でも触れます）。

スナップショットと保持管理（forget/prune/check）

restic はバックアップを「スナップショット」という単位で管理します。各スナップショットはメタデータを伴う増分バックアップで、前述の重複排除のおかげで、2 回目以降は変更分のみがリポジトリに追加されます。

スナップショットが増え続けると古いものが溜まっていくため、restic には保持管理のためのコマンドが用意されています。

• restic snapshots: 保存されているスナップショットの一覧を表示する
• restic forget: 保持ポリシー（日次N世代・週次N世代など）に基づいてスナップショットを削除する
• restic prune: forget で参照されなくなった実データをリポジトリから掃除し、容量を回収する
• restic check: リポジトリの整合性を検証する

設計原則の「Verifiable（検証可能）」を支えているのが check コマンドです。バックアップが破損していないか、復元可能な状態が保たれているかを検証できる点は、いざというときに「復元できなかった」という最悪の事態を避けるうえで重要です。

なお、restic は再現可能ビルド（Reproducible Builds）にも対応しており、配布されるリリースバイナリがソースコードからバイト単位で同一に再現できることが保証されています。配布バイナリの信頼性を重視する環境では、これも評価ポイントになります。

対応バックエンドと基本的な使い方の流れ

対応バックエンド（クラウド対応の広さ）

「自分の保存先に restic が対応しているか」は、採用判断の実務的な分かれ目です。restic は README で以下のバックエンド（保存先）にネイティブ対応していることを示しています（restic README）。

• ローカルディレクトリ
• SFTP（SSH 経由）
• HTTP REST server（rest-server という restic 公式の別リポジトリ）
• Amazon S3（本家 S3 または Minio サーバー経由）
• OpenStack Swift
• Backblaze B2
• Microsoft Azure Blob Storage
• Google Cloud Storage
• rclone backend 経由でその他多数のサービス

注目すべきは、主要クラウドのオブジェクトストレージ（S3・B2・Azure Blob・GCS・Swift）にネイティブ対応している点です。さらに rclone を介せば、rclone が対応する多数のクラウドサービスへもバックアップできます。「クラウドストレージにそのままバックアップを置きたい」というニーズに、追加の中継サーバーなしで応えられる点は restic の大きな強みです。

基本的なコマンドフロー（README Quick start引用）

restic の基本的な利用の流れは「リポジトリの初期化 → バックアップ → 復元」というシンプルなものです。README の Quick start には、リポジトリ初期化の例として以下が示されています。

$ restic init --repo /tmp/backup
enter password for new backend:
enter password again:
created restic backend 085b3c76b9 at /tmp/backup

出典: restic README

続いて、バックアップを作成する例は以下のとおりです。

$ restic --repo /tmp/backup backup ~/work
enter password for repository:
scan [/home/user/work]
scanned 764 directories, 1816 files in 0:00
[0:29] 100.00%  54.732 MiB/s  1.582 GiB / 1.582 GiB  2580 / 2580 items  0 errors
snapshot 40dc1520 saved

出典: restic README

初期化時にパスワードを設定し（このパスワードがリポジトリ全体の暗号化鍵の元になります）、あとは backup コマンドで対象ディレクトリを指定するだけです。復元は restic restore で行うほか、restic mount を使えば FUSE 経由で過去のスナップショットをファイルシステムとしてマウントし、ファイルを直接閲覧することもできます。

運用面では、JSON 形式での出力に対応しているためスクリプトからの自動処理がしやすく、環境変数によるパスワードや認証情報の設定、cron などによるスケジューリング自動化も公式ドキュメントで案内されています。コマンド体系・運用の詳細はrestic 公式ドキュメントにまとまっています。

BorgBackup・Kopiaとの違い｜restic選定の判断軸

restic を採用すべきかを判断するには、近いツールとの比較が欠かせません。ここでは最も近いピアである BorgBackup と Kopia を取り上げます。

比較表（restic / Borg / Kopia）

※ スター数・ライセンス等は各リポジトリの公式情報（確認時点）に基づきます。比較の詳細は外部の比較記事（Onidel: Restic vs BorgBackup vs Kopia）も参考になります。

BorgBackup（borgbackup/borg）は restic に最も近い存在で、重複排除・暗号化・スナップショット型という基本思想が共通し、CLI の使い勝手も似ています。違いとして、Borg は zstd・lzma・zlib を複数の圧縮レベルでサポートしており、テキスト中心のデータでは restic より 5〜15% 程度小さいリポジトリになる傾向があります。一方で、Borg はクラウドのオブジェクトストレージにネイティブ対応しておらず、SSH 越しの Borg サーバーを介すのが基本です。また、低 RAM 環境（2GB 以下程度）では Borg のメモリ効率が有利とされます。

Kopia（kopia/kopia）も Go 製・クロスプラットフォーム・重複排除・クライアント側 E2E 暗号化・圧縮対応と、restic に近い性格を持ちます。最大の違いは GUI を同梱している点で、コマンドライン操作に不慣れな利用者や、視覚的にバックアップを管理したい場面で選ばれます。restic より歴史が浅い新しめのツールである点も押さえておくとよいでしょう。

このほか、GUI を備え初心者向けの Duplicati や、ロックフリーな重複排除で多数クライアントの共有リポジトリ向けに使われる Duplicacy なども、バックアップツールの比較対象として名前が挙がることがあります。

どんな場合にresticを選ぶべきか（選定の判断軸）

3 ツールの違いを踏まえると、採用判断の軸は次のように整理できます。

restic が向いているケース

• S3・B2・Azure Blob・GCS などのクラウドオブジェクトストレージに、中継サーバーなしで直接バックアップを置きたい
• ファイル名やディレクトリ構造まで含めて暗号化し、信頼できない保存先でも安全性を確保したい
• Go 製の単一バイナリで、依存関係を気にせず複数の OS・サーバーに手早く導入したい
• 大きなコミュニティと活発な開発（スター数 34,583・直近の更新）に裏打ちされた安心感を重視したい

BorgBackup のほうが向いているケース

• バックアップ先が自前の SSH サーバーで、クラウドオブジェクトストレージへの直接対応が不要
• ストレージ容量を極力切り詰めたく、複数の圧縮アルゴリズム・レベルを使い分けたい
• メモリの限られた低スペック環境で運用したい

Kopia のほうが向いているケース

• コマンドラインに不慣れなメンバーがいて、GUI でバックアップを管理したい
• restic が対応していないバックエンドを使う必要がある

検索者が抱える「クラウドストレージにそのままバックアップしたい」というニーズに対しては、クラウドネイティブ対応の広さという点で restic が有力な選択肢になります。逆に、SSH サーバー中心の運用や極限までの容量最適化、低 RAM 環境であれば Borg、GUI 必須なら Kopia、というのが大まかな判断軸です。

まとめ｜resticの採用に向いているケース

ここまで、restic の仕組みと、BorgBackup・Kopia との違いを見てきました。要点を整理します。

• restic は Go 製・BSD-2-Clause ライセンスの単一バイナリ バックアップ OSS で、スター数 34,583・最終更新 2026年6月14日と、活発に開発が続く健全なプロジェクトです（アーカイブ・フォーク版ではありません）。
• 仕組みの面では、CDC による重複排除で増分のみを効率的に保存し、AES-256（CTR）+ Poly1305 + scrypt によってファイル内容だけでなくファイル名・ディレクトリ構造まで暗号化します。
• 主要クラウドのオブジェクトストレージにネイティブ対応している点が、Borg との最大の差別化要素です。

restic の採用が特に合うのは、「クラウドストレージに暗号化バックアップを直接置きたい」「依存関係を気にせず複数の OS に手早く導入したい」「活発なコミュニティの安心感を重視したい」というチームや環境です。

一方で、留意点もあります。リポジトリのパスワードを紛失するとデータは復元不能になるため、パスワード管理の運用ルールを事前に決めておく必要があります。また、圧縮は zstd のみで、複数の圧縮方式を細かく使い分けたい場合は Borg のほうが柔軟です。低 RAM 環境では Borg のメモリ効率が有利な点も覚えておくとよいでしょう。

より深く検討する際は、restic 公式ドキュメントでコマンドや運用の詳細を確認し、疑問点は公式のフォーラム（forum.restic.net）で情報を探すのが確実です。本記事が、自分の環境に restic が合うかどうかを根拠を持って判断する一助になれば幸いです。