Restic + S3互換ストレージで安全バックアップ：暗号化・世代管理・検証まで

バックアップ・障害対策・監視中級
ResticBackupS3Object Storage暗号化

本記事はアフィリエイト広告（A8.net）を含みます。価格・仕様は2026年7月時点の目安です。最新は各公式サイトでご確認ください。

TL;DR

  • Restic はオープンソースのバックアップツール。暗号化・重複排除・増分バックアップが標準機能で、追加の暗号化設定なしに安全な保管先へ送れる
  • リポジトリ（保存先）は restic init で初期化。S3互換オブジェクトストレージには AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY を環境変数で渡し、s3:https://server:port/bucket_name 形式のURLで接続する
  • バックアップは restic backup、世代管理は restic forget --keep-daily --keep-weekly --keep-monthly などの --keep-* オプションで設計する
  • バックアップは復元できて初めて意味がある。restic check（整合性検証）と restic restore（実際の復元）を定期的に回す運用まで含めて設計する
  • 定期実行はcronでラップし、RESTIC_PASSWORD などの認証情報はスクリプト側で読み込む形にする

3-2-1バックアップ戦略でいう「オフサイト1部」の実装として、ResticとS3互換ストレージの組み合わせは、個人開発〜中小企業の運用でよく使われる構成です。全体設計は3-2-1バックアップ戦略を、保存先そのものの基礎はS3互換オブジェクトストレージ入門を先に読むと理解が早まります。

Resticとは — 暗号化・重複排除・増分バックアップが標準装備

Resticは、コマンド1つで暗号化バックアップを取れるオープンソースのバックアップツールです。初めて触る人がつまずきやすい3つの用語を先に整理します。

  • 暗号化：バックアップデータはリポジトリに書き込まれる前にクライアント側で暗号化されます。保存先の事業者がデータの中身を見ることはできません（パスワードを失うと復号できず、データも失われる点は要注意です）
  • 重複排除（deduplication）：ファイルの内容をブロック単位で分割し、既に保存済みのブロックは再送信しません。同じファイルを毎日バックアップしても、変化がなければ転送量・保存量はほぼ増えません
  • 増分バックアップ：2回目以降の実行では、変更されたファイルだけを扱います。これは重複排除の仕組みによって自然に実現されます

保存先（リポジトリ）はローカルディスク・SFTP・REST Server・Amazon S3・S3互換ストレージなど複数の方式に対応しています。本記事では、VultrなどのS3互換オブジェクトストレージを保存先にする構成を扱います。

インストールと初期化

インストール

Debian/Ubuntu系ではパッケージが提供されています。

sudo apt-get install restic

macOSはHomebrewで導入できます。

brew install restic

配布パッケージが古い場合は、公式バイナリを使う方法もあります。導入後は次のコマンドでバージョンを確認できます。

restic version

リポジトリの初期化（S3互換ストレージへの接続）

Resticは保存先を「リポジトリ」と呼びます。S3互換ストレージ（Amazon以外の事業者）を使う場合、公式ドキュメントでは次の形式で指定します。

s3:https://server:port/bucket_name

接続にはS3互換の認証情報が必要です。環境変数として設定します。

export AWS_ACCESS_KEY_ID=<アクセスキーID>
export AWS_SECRET_ACCESS_KEY=<シークレットアクセスキー>

リポジトリの場所とパスワードも環境変数にしておくと、以降のコマンドが簡潔になります。

export RESTIC_REPOSITORY="s3:https://<エンドポイント>/<バケット名>"
export RESTIC_PASSWORD="<リポジトリの暗号化パスワード>"

この状態で初期化を実行します。

restic init

成功すると created restic repository ... と表示されます。このパスワードを失うとリポジトリ内のデータは復号できず、事実上失われます。 パスワードマネージャーなど別経路で必ず控えておいてください。

リージョンの指定が必要な事業者では AWS_DEFAULT_REGION の環境変数、またはオプション -o s3.region="us-east-1" で明示できます。また、Amazon以外の多くのS3互換サービスはパス形式のURLを前提にしているため、事業者によっては -o s3.bucket-lookup=path を明示的に指定する必要がある場合もあります。オブジェクトストレージそのものの仕組みはS3互換オブジェクトストレージ入門で解説しています。

バックアップの実行と世代管理

バックアップを実行する

対象ディレクトリを指定してバックアップします。

restic backup /var/www --verbose

2回目以降の実行では、変更のないファイルは再送信されず、重複排除により保存量・転送量が抑えられます。バックアップの一覧はスナップショットという単位で管理され、次のコマンドで確認できます。

restic snapshots

世代管理（forget）で古いスナップショットを削除する

保存先は無限ではないため、古いスナップショットを整理するポリシーが必要です。Resticは forget コマンドに保持ポリシーを指定する方式を取ります。主なオプションは次の通りです。

オプション意味
--keep-last n直近 n 世代を保持
--keep-daily n直近 n 日分、日ごとに最新1件を保持
--keep-weekly n直近 n 週分、週ごとに最新1件を保持
--keep-monthly n直近 n か月分、月ごとに最新1件を保持
--keep-yearly n直近 n 年分、年ごとに最新1件を保持
--keep-within duration直近のスナップショットから指定期間内のものをすべて保持

例えば「日次7世代・週次4世代・月次6世代」を残す運用は次のように書きます。

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6

forget はスナップショットの参照を外すだけで、実データはリポジトリに残ったままです。参照されなくなったデータを実際に削除するには prune を続けて実行する必要があります。

restic prune

2つを毎回手動で分けるのは煩雑なため、forget に --prune を付けると、スナップショットが実際に削除された場合のみ自動で prune まで実行されます。

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

prune はリポジトリをロックしてバックアップができない時間帯を作るため、定期バックアップと重ならないよう実行時間帯を分けて設計してください。ポリシーが意図通りか不安な場合は --dry-run を付けて、実際には何も削除せずに結果だけ確認できます。

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run

復元できて初めて意味がある — checkとrestoreによる検証

バックアップ運用で最も見落とされがちなのが、「バックアップは取れているが、復元したことは一度もない」 という状態です。リポジトリが壊れていても、バックアップコマンド自体は正常終了して見えることがあります。定期的な検証を運用に組み込みます。

restic check で整合性を確認する

リポジトリのメタデータ（インデックスや参照関係）が壊れていないかを確認します。

restic check

メタデータだけでなく、保存されているデータの中身まで読んで検証したい場合は --read-data を付けます。処理時間は長くなりますが、より厳密な検証になります。

restic check --read-data

restic restore で実際に復元してみる

check は整合性の確認であり、「実際にファイルへ戻せるか」までは保証しません。最新のスナップショットを検証用ディレクトリへ復元して、中身を目視・比較するところまでを運用に含めます。

restic restore latest --target /tmp/restore-check

特定のスナップショットIDを指定して復元することもできます。IDは restic snapshots の一覧から確認します。

restic restore <snapshot-ID> --target /tmp/restore-check

「月1回、本番とは別のマシンで restore を実際に走らせて中身を確認する」というルールを決めておくと、災害時に「そもそも復元できなかった」という最悪の事態を避けられます。この視点は経営層への説明にも直結します。詳しくはRPO/RTOを経営層に説明するで扱っています。

cronでの自動化

日次バックアップ・世代管理・整合性確認をまとめてスクリプト化し、cronで回します。認証情報はスクリプト内にベタ書きせず、権限を絞った環境ファイルから読み込む形にします。

#!/usr/bin/env bash
set -euo pipefail

# 認証情報・リポジトリ情報を読み込む（chmod 600 で権限を絞る）
source /etc/restic/env

restic backup /var/www --verbose

# 日次7・週次4・月次6を保持し、削除が発生した場合のみpruneまで実行
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# 週次で整合性チェック（曜日判定は呼び出し側のcron式で制御）
restic check

crontabには次のように登録します。多重起動を防ぐため flock を挟み、実行ログをファイルへ残します。

0 3 * * * /usr/bin/flock -n /tmp/restic-backup.lock /usr/local/bin/restic-backup.sh >> /var/log/restic-backup.log 2>&1

cron・systemd timerそれぞれの設定方法や、実行環境がログイン時と異なることによる落とし穴（PATH・環境変数）はcronとsystemd timerで定期実行で詳しく扱っています。

まとめ

Resticは、暗号化・重複排除・増分バックアップという安全なバックアップに必要な要件を標準機能として備えたツールです。S3互換オブジェクトストレージと組み合わせれば、RESTIC_REPOSITORY と認証情報の環境変数だけで、オフサイトの暗号化バックアップ先を用意できます。

運用としてのポイントは3つです。

  1. 世代管理：forget --keep-daily/--keep-weekly/--keep-monthly でポリシーを明文化し、--prune で実データも整理する
  2. 復元検証：check はメタデータの整合性確認、restore は実際の復元確認。両方を定期的に回して初めて「使えるバックアップ」と言える
  3. 自動化と失敗の可視化：cron（またはsystemd timer）でラップし、失敗時に気づける形にする

「バックアップを取ること」がゴールではなく、「必要なときに復元できること」がゴールです。仕組みを組んだら、一度は実際に restore まで通してみてください。

各サービス公式

Vultr（クラウド/オブジェクトストレージ）

※価格・仕様・提供リージョンは変動します。最新の料金とオブジェクトストレージの対応状況は各公式サイトでご確認ください。

関連記事

バックアップ・障害対策・監視オブジェクトストレージ入門 — S3互換でバックアップと配信を安くバックアップ・障害対策・監視バックアップの復元テストを自動化する：月次DR演習のスクリプト例バックアップ・障害対策・監視3-2-1バックアップとは？データを失わないための最小設計【2026年】
記事一覧に戻る