2026年8月4日

rcloneでクラウドストレージにバックアップする方法｜S3設定・暗号化・cron自動化まで

バックアップ・監視

rcloneを使うと、サーバー上のバックアップファイルをAmazon S3やGoogle Drive、Backblaze B2などのクラウドストレージへ、1つのコマンドで送れるようになります。安全に運用するための要点は、「sync ではなく copy を基本にする」「--dry-run で事前に確かめる」「必要なら暗号化してから送る」の3つです。この記事では、インストールからS3の接続設定、WordPressのバックアップをcronで毎日アップロードする仕組みまでを順に説明します。

rcloneのインストール

公式のインストールスクリプトを使うと、最新の安定版が /usr/bin/rclone に入ります。

sudo -v ; curl https://rclone.org/install.sh | sudo bash
rclone version

Ubuntuなどのaptリポジトリにもrcloneはありますが、配布されている版が古く、クラウド側の仕様変更に追従できていないことがあります。特にGoogle DriveやOneDriveなど認証方式が変わりやすいサービスを使う場合は、公式スクリプトか公式サイトのバイナリを使うほうがトラブルを避けられます。（2026年10月現在、rcloneは70種類以上のストレージに対応しています。）

接続先（リモート）を設定する

rcloneでは、接続先を「リモート」という名前付きの設定として登録します。対話形式の rclone config で作るのが基本ですが、S3のように項目が決まっているものはコマンド1行でも作れます。

rclone config create mys3 s3 \
  provider=AWS \
  access_key_id=your-access-key-id \
  secret_access_key=your-secret-access-key \
  region=ap-northeast-1

設定は ~/.config/rclone/rclone.conf に保存されます。実際の場所は rclone config file で確認できます。このファイルにはアクセスキーがそのまま書かれるため、権限を 600 にしておき、Gitリポジトリや公開ディレクトリに置かないよう注意してください。

S3のアクセスキーには、バックアップ用のバケットだけを操作できるIAMユーザーのものを使います。管理者権限のキーを使うと、サーバーが侵害されたときにAWSアカウント全体が危険にさらされます。権限を最小限に絞った結果、バケットの存在確認（作成チェック）で権限エラーが出る場合は、--s3-no-check-bucket を付けると回避できます。

接続できたかは、次のコマンドで確かめます。

rclone lsd mys3:                 # バケット一覧
rclone ls mys3:my-backup-bucket  # バケット内のファイル一覧

ブラウザのないサーバーでGoogle Driveを設定する

Google DriveやDropboxはOAuth認証が必要で、ブラウザでの許可操作が発生します。VPSのようにブラウザがない環境では、rclone config の途中で自動設定（auto config）を使わない選択をし、手元のPCで rclone authorize "drive" を実行します。手元のブラウザで許可すると表示されるトークンを、サーバー側の入力欄に貼り付ければ設定が完了します。手元のPCにも同じ系統のバージョンのrcloneを入れておくと、手順がスムーズです。

copyとsyncの違いを理解する

rcloneでいちばん事故が起きやすいのが、copy と sync の取り違えです。

rclone copy 元先：元にあるファイルを先へ送る。先にしかないファイルは消さない
rclone sync 元先：先を元と同じ状態にする。元にないファイルは先から削除される
rclone move 元先：送った後に元のファイルを削除する

sync は、送信元を誤って空のディレクトリに指定したり、ローカル側のファイルが何かの理由で消えたりすると、クラウド側のバックアップまで消してしまいます。日付入りのアーカイブファイルを貯めていくバックアップなら、copy で十分です。

どちらを使う場合も、最初の実行では --dry-run を付けて、何が転送・削除されるかを確認してください。

rclone copy /var/backups/wordpress mys3:my-backup-bucket/wordpress --dry-run -v

どうしても sync を使いたい場合は、--backup-dir で削除・上書きされるファイルの退避先を指定しておくと、誤操作からの復旧が可能になります。

rclone sync /var/www/html mys3:my-backup-bucket/current \
  --backup-dir mys3:my-backup-bucket/old/$(date +%F)

なお、--backup-dir は同じリモート内で、同期先と重ならない場所を指定する必要があります。

送る前に暗号化する（crypt）

クラウド事業者側でもデータは保管時に暗号化されますが、データベースのダンプには会員情報などが含まれることがあります。アクセスキーが漏れたときの被害を抑えるには、rcloneの crypt リモートで、送る前に手元で暗号化しておく方法が有効です。

rclone config で新しいリモートを作り、種類に crypt、ラップする先に mys3:my-backup-bucket/encrypted のような既存リモートのパスを指定し、パスワードを設定します。以後は mycrypt: に対して copy すれば、ファイル内容とファイル名が暗号化されてS3に保存されます。

ここで設定したパスワードを失うと、バックアップは二度と復号できません。rclone.confの控えとは別に、パスワード管理ツールなどで保管してください。また、rclone.conf内のパスワードは「難読化」されているだけで、暗号化ではありません。設定ファイル自体を守りたい場合は、rclone config のメニューから設定ファイルのパスワードを設定し、実行時は環境変数 RCLONE_CONFIG_PASS で渡します。

WordPressのバックアップを自動アップロードする

データベースのダンプとファイル一式を固めて、クラウドへ送るスクリプトの例です。

#!/bin/bash
# /usr/local/bin/wp-backup-rclone.sh
set -euo pipefail

DATE=$(date +%Y%m%d)
WORK=/var/backups/wordpress
REMOTE=mys3:my-backup-bucket/wordpress
mkdir -p "$WORK"

# DBダンプ（接続情報は ~/.my.cnf に置き、コマンドラインにパスワードを書かない）
mysqldump --single-transaction --default-character-set=utf8mb4 wordpress | gzip > "$WORK/db-$DATE.sql.gz"

# ファイル一式
tar -czf "$WORK/files-$DATE.tar.gz" -C /var/www html

# クラウドへ送る（既存ファイルは消さない）
rclone copy "$WORK" "$REMOTE" \
  --log-file /var/log/rclone-backup.log --log-level INFO

# クラウド側：30日より古いものを削除
rclone delete "$REMOTE" --min-age 30d --log-file /var/log/rclone-backup.log --log-level INFO

# ローカル側：7日より古いものを削除
find "$WORK" -type f -mtime +7 -delete

ポイントは、クラウド側の世代管理を rclone delete --min-age で別に行っていることです。sync でローカルとクラウドを揃える方式にすると、ローカルの保管期間がそのままクラウドの保管期間になり、ローカルで消えたものはクラウドからも消えます。保管期間を分けることで、「手元は7日分、クラウドは30日分」といった構成にできます。

rclone delete も削除コマンドなので、初回は --dry-run で対象を確認します。リモートのパスを1階層間違えると、別の用途のファイルまで対象になるためです。

cronには次のように登録します。flock を挟むと、前回の処理が長引いたときに次の回が重なって走るのを防げます。

# crontab -e
30 3 * * * /usr/bin/flock -n /tmp/wp-backup.lock /usr/local/bin/wp-backup-rclone.sh

cronはログインシェルと環境変数が違うため、rclone.conf が見つからないことがあります。root以外のユーザーで設定を作った場合は、そのユーザーのcrontabに登録するか、スクリプト内で --config /home/ユーザー名/.config/rclone/rclone.conf を指定してください。

転送の調整とよく使うオプション

--transfers 4：同時に転送するファイル数（既定は4）。回線に余裕があれば増やせますが、サーバーの負荷も上がります
--bwlimit 10M：帯域の上限。営業時間中に動かすならサイトへの影響を抑えられます
--fast-list：S3などで一覧取得のAPI呼び出しを減らします。ファイル数が多いときに有効ですが、メモリを多く使います
--exclude "cache/**"：除外パターン。WordPressのキャッシュディレクトリなど、復元に不要なものを外せます

バックアップが使えるか確かめる

送ったファイルがそろっているかは、rclone check で比較できます。

rclone check /var/backups/wordpress mys3:my-backup-bucket/wordpress --one-way

--one-way は「元にあるファイルが先にもあり、中身が一致するか」だけを見るオプションで、クラウド側に古い世代が残っている構成でも誤検知しません。

ただし、本当に確かめるべきなのは「戻せるか」です。定期的に rclone copy mys3:my-backup-bucket/wordpress/db-20261015.sql.gz /tmp/restore/ のように取り出し、テスト環境でデータベースに読み込めるか、tarを展開できるかを試してください。暗号化している場合は、パスワードを含めて復元できるかの確認になります。

まとめ

公式スクリプトで最新版を入れ、接続先は権限を絞ったキーでリモートとして登録する
バックアップには copy を使い、sync や delete は --dry-run で確認してから実行する
機密性の高いデータは crypt リモートで暗号化し、パスワードは別の場所に保管する
クラウド側の世代管理は rclone delete --min-age で、ローカルとは別に行う
cronでは flock と設定ファイルのパスに注意し、定期的に復元テストを行う