2026年9月1日

Backblaze B2へのバックアップ設定方法（rcloneでサーバーから自動転送）

バックアップ・監視

Backblaze B2 へサーバーのバックアップを送るには、「バケット専用のアプリケーションキーを作る」「rclone で B2 を登録する」「cron で定期転送する」「ライフサイクルルールで古い版を整理する」の4段階で設定します。この記事では、VPS や専用サーバーから rclone を使って B2 へ自動でバックアップする手順と、B2 特有の「削除ではなく非表示になる」動きへの対処、復元の確認方法までを説明します。

Backblaze B2 の特徴と、この記事の範囲

Backblaze B2 はオブジェクトストレージのサービスで、独自の B2 API に加えて S3 互換 API も提供しています。そのため B2 専用のツールだけでなく、rclone や restic のような S3 対応ツールからも使えます。

B2 の大きな特徴は、ファイルのバージョン管理が標準で働くことです。同じ名前のファイルをアップロードすると古い版が残り、ファイルを削除すると「非表示（hide）」の状態になって履歴は残ります。誤削除から戻せる反面、何も設定しないと古い版がたまり続けて保存量が増えます。後半のライフサイクルルールの設定は省かないでください。

WordPress のバックアッププラグインにも B2 に対応したものがあります（対応の有無が有償版限定の場合もあり、機能の範囲はバージョンで変わるため各プラグインの公式情報で確認してください）。この記事はプラグインではなく、サーバー側で DB とファイルをまとめて送る方法を扱います。

手順1：バケットとアプリケーションキーを作る

Backblaze のアカウントでは、作成時に選んだリージョン（データセンターの地域）にデータが置かれます。後から変えるには別アカウントが必要になる仕組みのため、作成前に保存先の地域を決めておきます（2026年10月現在）。

管理画面でバケットを作るときは、公開設定を「Private」にします。バックアップを公開バケットに置く理由はありません。保存時の暗号化（SSE-B2）を有効にする設定もあるので、あわせてオンにしておくとよいでしょう。

次にアプリケーションキーを作ります。アカウント作成時に発行されるマスターアプリケーションキーは全バケットを操作できるため、サーバーには置きません。管理画面のアプリケーションキーの作成画面で、次のように範囲を絞ったキーを作ります。

アクセスできるバケット：バックアップ用のバケットだけ
権限：読み書き（ファイルの読み取り・書き込み・一覧）

作成直後に表示される keyID と applicationKey を控えます。applicationKey はこの画面を閉じると再表示できないので、パスワードマネージャーなど安全な場所へ保存してください。画面の名称や項目の配置はサービス側の更新で変わることがあるため、見当たらない場合は Backblaze のヘルプで「Application Keys」を確認します。

手順2：rclone をインストールして B2 を登録する

rclone は公式サイトのインストール手順か、ディストリビューションのパッケージで導入します。パッケージ版は古いことがあるため、rclone version でバージョンを確認し、古すぎる場合は公式の手順で入れ直します。

登録は対話式の rclone config でも、コマンド1行でもできます。

rclone config create b2backup b2 \
  account=your-key-id \
  key=your-application-key

chmod 600 ~/.config/rclone/rclone.conf
rclone lsd b2backup:

最後の rclone lsd でバケット名が表示されれば接続できています。キーを特定のバケットに限定した場合、そのバケット以外は見えないのが正常です。

設定ファイルにはキーが平文で保存されます。rclone config のメニューから設定ファイル自体にパスワードをかけることもできますが、その場合は cron 実行時にパスワードを渡す仕組みが別途必要になります。少なくともパーミッションは 600 にし、root 以外が読めない場所に置いてください。

手順3：転送の動きを確認する

rclone には copy（送り元にあるものを送るだけ）と sync（送り先を送り元と同じにする、送り元にないものは送り先から消す）があります。まず --dry-run で何が起きるかを確認します。

rclone sync /var/www/html/wp-content b2backup:your-backup-bucket/files/wp-content \
  --exclude "cache/**" --exclude "*.log" \
  --fast-list --transfers 8 \
  --dry-run -v

B2 では、rclone で削除したファイルは既定で「非表示」になり、古い版として残ります。--b2-hard-delete を付けると本当に削除されますが、バックアップ用途では付けないほうが安全です。誤って送り元を消したまま sync しても、B2 側の古い版から戻せるからです。

--fast-list は一覧取得の API 呼び出し回数を減らす指定で、ファイル数が多い場合に効果があります。そのぶんメモリを使うので、小さな VPS では様子を見て調整してください。--transfers は同時転送数です。回線を占有して困るときは --bwlimit 5M のように帯域を制限できます。

手順4：スクリプトにまとめて自動化する

データベースのダンプを作り、ファイルと一緒に送るスクリプトの例です。

#!/usr/bin/env bash
# /usr/local/bin/b2-backup.sh
set -euo pipefail

REMOTE="b2backup:your-backup-bucket"
STAMP="$(date +%Y%m%d-%H%M%S)"
TMP="/var/backups/b2-tmp"
mkdir -p "$TMP"
chmod 700 "$TMP"

# 1) データベース（認証情報は ~/.my.cnf、権限 600）
mysqldump --single-transaction --quick --default-character-set=utf8mb4 wordpress \
  | gzip > "${TMP}/db-${STAMP}.sql.gz"
rclone copy "${TMP}/db-${STAMP}.sql.gz" "${REMOTE}/db/"
rm -f "${TMP}/db-${STAMP}.sql.gz"

# 2) ファイル
rclone sync /var/www/html/wp-content "${REMOTE}/files/wp-content" \
  --exclude "cache/**" --exclude "*.log" \
  --fast-list --transfers 8 \
  --log-level NOTICE

echo "b2 backup ok: ${STAMP}"

45 3 * * * flock -n /run/b2-backup.lock /usr/local/bin/b2-backup.sh >> /var/log/b2-backup.log 2>&1

cron から実行すると、ユーザーのホームディレクトリにある rclone の設定ファイルを見つけられないことがあります。うまくいかないときは rclone --config /root/.config/rclone/rclone.conf のように設定ファイルの場所を明示します。cron は失敗しても知らせてくれないので、ログの監視や失敗時の通知も用意してください。

手順5：ライフサイクルルールで古い版を整理する

B2 のバケットには、古い版をいつまで残すかを決めるライフサイクル設定があります。既定は「すべての版を残す」なので、このままでは非表示になったファイルや上書き前の版がたまり続けます。管理画面のバケット設定から、「古い版を一定日数後に削除する」タイプのルールを選び、日数を指定します。たとえば 30 日にすれば、過去 30 日以内の状態ならいつでも戻せる、という運用になります。

DB のダンプのように毎回別名で保存するファイルは、版ではなくファイル自体が増えていきます。こちらはライフサイクルルールの詳細設定で、プレフィックス（db/）を指定し、アップロードから一定日数で非表示にし、その後削除する、というルールを作ります。ルールの選択肢や表記は変わることがあるため、設定後はバケットの使用量が想定どおりに推移しているかを数日おきに確認してください。

ランサムウェア対策を強めたい場合、B2 は Object Lock にも対応しています。ロック期間中は自分でも削除できなくなるので、期間の設計を十分に検討してから有効にします。

手順6：暗号化と復元の確認

B2 側の暗号化に加えて、送る前に自分で暗号化したい場合は、rclone の crypt リモートを B2 リモートの上に重ねる方法があります。crypt のパスワードを失うとデータを読めなくなるので、バックアップとは別の場所に控えを保管します。重複排除や世代管理まで含めて任せたいなら restic も選択肢で、restic の公式ドキュメントでは B2 を S3 互換 API 経由で使う方法が案内されています（2026年10月現在）。

復元は、本番とは別の場所へ戻して確かめます。

# 最新の状態を検証用ディレクトリへ
rclone copy b2backup:your-backup-bucket/files/wp-content /tmp/restore-test/wp-content -v

# 過去の版も含めて一覧を確認
rclone ls --b2-versions b2backup:your-backup-bucket/files/wp-content/uploads/2026/

--b2-versions を付けると、古い版がファイル名に日時を付けた形で表示され、個別に取り出せます。DB のダンプは検証用のデータベースへ流し込み、記事数やユーザー数が本番と一致するかを見ます。復元にかかった時間も記録しておくと、障害時の見積もりに使えます。

まとめ

B2 は版の管理が標準で働き、削除は「非表示」になる。ライフサイクルルールで古い版の保持日数を決める
マスターキーはサーバーに置かず、バケットと権限を絞ったアプリケーションキーを使う
rclone で登録し、--dry-run で sync の動きを確認してから cron で自動化する
バックアップ用途では --b2-hard-delete を付けず、誤削除から戻せる状態を保つ
必要に応じて crypt や restic で事前に暗号化し、定期的に復元を試す