Cloudflare R2とrcloneの接続を安全に切り分ける
Cloudflare R2をrcloneで操作するとき、最初に理解すべき対象はフォルダではなくオブジェクトキーです。
見た目のディレクトリは、キーの共通部分であるprefixとして扱われます。
この違いを曖昧にしたまま移動や削除をすると、対象範囲を誤りやすいです。
もう1つの落とし穴は、GetBucketVersioningの403です。
R2のS3 API互換表では、このAPIは未実装と説明されています。
したがって、1つのAPIが403を返したことと、認証情報全体が無効であることは分けて調べる必要があります。
公式資料から接続の前提を固定する
Cloudflareのrclone設定例では、S3 providerへCloudflareを指定し、アカウント固有のR2 endpointを使います。
設定の最小形は次です。
[r2]
type = s3
provider = Cloudflare
access_key_id = ...
secret_access_key = ...
endpoint = https://ACCOUNT_ID.r2.cloudflarestorage.com
acl = privateここで確認する値は、remote名、アカウントID、対象bucket、credentialの4つです。
credentialには、対象bucketや操作に必要な最小権限だけを与えます。
rcloneの設定ファイルへ秘密情報が平文で保存される可能性もあるため、設定の暗号化とOSのファイル権限を確認します。
設定ファイルとaccess keyをリポジトリへ追加しません。
bucketを列挙できない権限のtokenでは、rcloneのbucket確認に失敗することがあります。
その場合だけno_check_bucket = trueを検討し、先にAPI tokenの権限が対象bucketへ合っているかを確認します。
403を操作単位で分類する
同じ403でも、失敗したS3操作によって意味が変わります。
| 失敗した操作 | 最初に確認すること |
|---|---|
| bucket一覧 | tokenにbucket列挙権限があるか |
| object一覧 | 対象bucketとprefixへの権限があるか |
| upload | Object Write権限があるか |
| delete | 削除を含むWrite権限があるか |
| versioning取得 | R2でAPIが未実装ではないか |
R2のS3 API互換表は、GetBucketVersioningを未実装として扱っています。
他の一覧やコピーが動作しているなら、versioning確認だけの403を接続全体の失敗と解釈しません。
一覧、読み取り、書き込みがすべて失敗する場合は、接続設定を上から確認します。
endpoint、bucket名、tokenの権限を順に確認します。
操作前にprefixを文字列として固定する
削除や移動の前に、remote、bucket、prefixを別々に確認できるコマンドを実行します。
rclone lsf r2:my-bucket/archive/2026-08 --recursive
rclone size r2:my-bucket/archive/2026-08ここで出力されたキーが、操作したい対象と一致することを確認します。
bucket直下や空のprefixをそのまま削除対象にしません。
シェル変数やglobで対象を組み立てる場合は、展開後の完全なremote pathを表示してから続行します。
moveを使う前にコピーと削除を分ける
rcloneのmoveリファレンスが説明するように、条件によって移動はサーバー側の操作またはコピー後の削除になります。
重要データでは、失敗時に再開しやすいように段階を分けます。
# 1. コピー対象を確認
rclone copy r2:my-bucket/old-prefix r2:my-bucket/new-prefix --dry-run
# 2. コピー
rclone copy r2:my-bucket/old-prefix r2:my-bucket/new-prefix
# 3. コピー先を検証
rclone check r2:my-bucket/old-prefix r2:my-bucket/new-prefix
# 4. 削除対象を確認
rclone purge r2:my-bucket/old-prefix --dry-run
# 5. 完全に一致したprefixだけを削除
rclone purge r2:my-bucket/old-prefixrclone checkの結果を確認する前に、元prefixを削除しません。
差分がある場合は、コピーの失敗、対象prefixの間違い、権限不足を分けて再確認します。
purgeは復旧手段とセットで考える
purgeは指定したprefix以下をまとめて削除します。
1文字の入力ミスでも、意図した範囲を超えて削除する可能性があります。
R2のS3互換APIではbucket versioningの取得APIが未実装であるため、削除後にS3のversionから簡単に復元できると考えません。
重要なオブジェクトは、別bucket、別アカウント、または別ストレージへバックアップします。
事後確認に残す証拠
操作後は、次の情報をログや作業記録へ残します。
- 実行日時
- rcloneのバージョン
- sourceとdestination
- 実行前後のobject数とbyte数
rclone checkの結果- 削除した担当者と理由
access key、secret key、署名付きURLはログへ書きません。
R2のS3互換性は、多くのツールを利用できることを意味します。
AWS S3のすべてのAPIが同じ動作をすることを意味しません。
互換表を先に確認し、prefixを固定し、コピーと削除を分けることが安全運用の基本です。