rcloneでpCloudへバックアップする方法――復元テストまでやって初めて安心できた

2026-07-12

rcloneを使えば、ローカルのデータをpCloudへコピーできます。しかし、転送が成功しただけでは、バックアップとして十分とは言えません。誤って削除を同期する可能性があり、設定ファイルや暗号化パスワードを失えば、必要なときに戻せないからです。

私も、最初は「定期的に転送できているから大丈夫」と考えていました。実際に別の空ディレクトリへ復元し、ファイルを開けるところまで確認すると、バックアップで重要なのはアップロードではなく、復元できることだと実感します。

この記事では、rcloneでpCloudへバックアップする基本設定から、copyとsyncの違い、世代管理、暗号化、照合、小さな復元テストまでを順に整理します。

記事更新日: 2026年7月12日

先に結論

初めて設定するなら、私は次の順番をおすすめします。

rclone configでpCloudを登録する
小さなテスト用ディレクトリでcopy --dry-runを実行する
copyでpCloudへ転送する
rclone checkで転送元と転送先を照合する
pCloudから別の空ディレクトリへ復元する
復元したファイルを実際に開く
必要になってから暗号化、世代管理、自動実行を追加する

最初からsyncを定期実行するのは避けた方が安全です。syncは転送元と同じ状態にするため、必要に応じて転送先のファイルを削除します。単純なオフサイトコピーから始めるなら、転送先の余分なファイルを削除しないcopyの方が扱いやすいです。

rcloneはバックアップ製品ではなく、データ転送ツール

rcloneは、多数のクラウドストレージへファイルを転送、同期、照合、暗号化できるツールです。pCloudも公式に対応しています。

ただし、rcloneを導入しただけでバックアップが完成するわけではありません。次の要素は利用者が決める必要があります。

何をバックアップするか
どの頻度で転送するか
削除や上書きをどう扱うか
何世代残すか
転送失敗にどう気付くか
暗号化鍵をどこへ保管するか
どの手順で復元するか

rcloneは、この設計を実行するための道具です。同期とバックアップを同じものとして扱わないことが、最初の注意点でした。

`copy`と`sync`の違い

コマンド	転送先だけにあるファイル	主な用途	注意点
`rclone copy`	削除しない	追加・更新ファイルのコピー	古い不要ファイルも残り続ける
`rclone sync`	必要に応じて削除する	転送元と同じ状態のミラー	誤削除やランサムウェア被害も反映し得る
`rclone check`	変更しない	サイズやハッシュによる照合	照合だけで、復元可能性までは確認できない

rclone公式ドキュメントでも、copyは転送先のファイルを削除せず、syncは転送元に合わせて転送先を削除すると説明されています。syncにはデータ損失の可能性があるため、先に--dry-runまたは対話モードで確認するよう明記されています。

ただし、copyも同じパスにある古い内容を自動で世代保存するコマンドではありません。転送元のファイルが壊れたり暗号化されたりした状態で再実行すれば、同名の転送先を更新する可能性があります。削除を避けることと、過去の版を残すことは別に設計します。

pCloudをrcloneへ登録する

1. rcloneをインストールする

rcloneはOSのパッケージ管理機能でも導入できます。ただし、配布されるバージョンが古い場合があるため、実際に使うバージョンを確認します。

rclone version

インストール方法と最新版は、rclone公式のダウンロードページで確認してください。

2. 対話形式でpCloudを登録する

次のコマンドで設定を開始します。

rclone config

新しいremoteを作成し、ストレージの種類としてpcloudを選びます。Client IDとClient Secretは、独自のpCloudアプリを使わない通常の設定では空欄にできます。その後、ブラウザでpCloudへログインし、rcloneのアクセスを許可します。

ブラウザを使えないリモートサーバーでは認証方法が異なります。また、pCloudのEUリージョンとリモート認証を組み合わせる場合はhostnameの設定が必要になることがあります。画面の番号や質問内容はrcloneのバージョンで変わるため、pCloudバックエンドの公式手順を見ながら設定するのが安全です。

ここで作られるrclone設定ファイルには、pCloudへアクセスするためのトークンが含まれます。設定内容を記事、Git、チャット、スクリーンショットへ貼り付けないでください。

3. 接続だけを確認する

この記事ではremote名をpcloudとします。実際の名前に読み替えてください。

rclone lsd pcloud:

ディレクトリ一覧を取得できれば接続確認は完了です。この出力には個人のフォルダー名が含まれるため、そのまま公開しない方が安全です。

まずは`copy`と`--dry-run`で試す

いきなり重要なディレクトリを指定せず、公開しても問題のないテストファイルだけを入れた小さなディレクトリを用意します。

以下は、ローカルの/path/to/sourceをpCloud上のbackup/currentへコピーする例です。実行前にパスを自分の環境へ置き換えてください。

rclone copy --dry-run /path/to/source pcloud:backup/current

--dry-runでは永続的な変更を行わず、予定される操作を確認できます。転送元と転送先を逆にしていないか、想定外のファイルが含まれていないかを確認してから、本番のコピーを実行します。

rclone copy /path/to/source pcloud:backup/current --progress

rcloneはディレクトリそのものではなく、指定したディレクトリの中身を転送します。backup/current/source/...ではなくbackup/current/...へ入る点にも注意が必要です。

転送後に`rclone check`で照合する

転送コマンドが終了コード0で完了しても、転送元と転送先が一致しているかは別に確認します。

rclone check /path/to/source pcloud:backup/current

rclone checkは、利用できる場合はサイズとハッシュを比較し、違いや欠落を報告します。転送元や転送先を変更するコマンドではありません。

pCloudはリージョンによって対応ハッシュが異なります。通常はバックエンドが利用可能な方式をrcloneが扱いますが、より厳密にデータを読み出して比較したい場合は--downloadも選択肢になります。その場合は実際にデータをダウンロードするため、通信量と所要時間が増えます。

rclone check /path/to/source pcloud:backup/current --download

全データで毎回実行するのが重い場合でも、定期的な照合と、小さなサンプルの復元は分けて実施できます。

復元テストを行う

ここがこの記事で最も重要な部分です。元の場所へ直接戻すと既存ファイルを上書きする可能性があるため、必ず別の空ディレクトリを使います。

1. 復元先を作る

mkdir -p /tmp/rclone-restore-test

2. pCloudからコピーする

rclone copy pcloud:backup/current /tmp/rclone-restore-test --progress

3. バックアップ側と復元先を照合する

rclone check pcloud:backup/current /tmp/rclone-restore-test

4. ファイルを実際に使う

照合結果だけで終わらせず、復元したファイルをいくつか開きます。

テキストファイルを読めるか
画像やPDFを開けるか
圧縮ファイルを展開できるか
ファイル名と更新日時が用途上問題ないか
アプリのエクスポートファイルを読み込めるか

データベースのdumpを保存している場合は、使い捨ての検証環境へrestoreし、テーブルや代表的なレコードを確認します。dumpファイルが存在するだけでは、復元可能とは判断できません。

私はこの小さな復元テストを行って、初めて「pCloudにファイルが見えている」ことと「必要なデータを戻せる」ことの違いを実感しました。

`sync`を使うなら世代を残す

転送先を現在の状態と一致させたい場合はsyncが便利です。ただし、転送元で消えたファイルは転送先からも削除されます。最初に必ず--dry-runで確認します。

rclone sync --dry-run /path/to/source pcloud:backup/current

さらに、上書きまたは削除されるファイルを別ディレクトリへ移す--backup-dirを組み合わせると、直前の状態を残せます。

rclone sync --dry-run /path/to/source pcloud:backup/current \
  --backup-dir pcloud:backup/versions/2026-07-12

dry-runの結果を確認してから、--dry-runを外します。

rclone sync /path/to/source pcloud:backup/current \
  --backup-dir pcloud:backup/versions/2026-07-12

--backup-dirは、転送先と同じremoteを使い、現在の転送先と重ならない場所を指定する必要があります。日付部分を実行日ごとに変え、古い世代をいつ削除するかも別途決めます。詳しい条件はrcloneの--backup-dir公式説明を確認してください。

自動実行では、1回に許容する削除数を--max-deleteで制限する方法もあります。通常の変更量を確認してから閾値を決め、閾値を超えたときは処理結果を確認します。これは世代管理の代わりではなく、大量削除へ気付くための安全策です。

pCloudでは削除されたファイルがtrashへ移動しますが、保持期間は契約内容に依存します。trashだけを世代管理の代わりにせず、自分が必要とする保持期間を設計した方が安全です。

暗号化する場合はrclone cryptを使う

クラウド事業者からファイル内容やファイル名を見えにくくしたい場合は、rcloneのcrypt remoteを重ねる方法があります。これはpCloud側の追加暗号化サービスとは別の、rcloneクライアント側の暗号化です。

rclone config

新しいremoteの種類としてcryptを選び、先に作成したpCloud remote内の専用ディレクトリを暗号化先として指定します。設定手順はrclone cryptの公式ドキュメントを参照してください。

暗号化には重要な注意点があります。

暗号化パスワードを失うと復元できない
rclone設定ファイル内のパスワードは、初期状態では軽い難読化にすぎない
rclone設定ファイル自体の暗号化と、別媒体への安全なバックアップが必要
暗号化パスワードのバックアップを、暗号化データと同じ場所だけに置かない
設定を変更する前に、既存データを復号できることを確認する

暗号化は漏洩時のリスクを下げますが、鍵を失うリスクを増やします。暗号化remoteを作ったら、少量のデータで暗号化、転送、復元、復号まで試してから対象を広げます。

自動実行ではログと終了コードを残す

手動の復元テストが成功してから、cronやsystemd timerなどで定期実行します。自動化するときは、転送コマンドだけでなく、失敗に気付く仕組みが必要です。

rclone copy /path/to/source pcloud:backup/current \
  --log-level INFO \
  --log-file /path/to/log/rclone-backup.log

最低限、次を確認します。

rcloneの終了コードが0か
エラーや転送失敗がログにないか
最終成功時刻が古くなっていないか
バックアップ先の容量が不足していないか
定期的なrclone checkが成功しているか
前回決めた期間内に復元テストを実施したか

ログにはファイル名やパスが含まれることがあります。公開範囲、保存期間、アクセス権を決め、ブログやIssueへそのまま貼らないようにします。通知を追加する場合も、ログ全文ではなく成功・失敗と実行時刻だけを送る方が安全です。

アプリのバックアップはファイルコピーだけでは足りない

Nextcloud、写真管理、CMSなどをセルフホストしている場合、永続ボリュームをrcloneでコピーしただけでは復元できないことがあります。

一般的には、次を分けて考えます。

データ	バックアップ例	復元時の確認
DB	アプリ推奨のdump	新しいDBへrestoreできるか
実ファイル	rcloneでオフサイトへ転送	件数、ハッシュ、代表ファイルを確認
設定	機密値を除いた設定と手順	新環境で再現できるか
Secret・鍵	専用の安全な保管先	必要な担当者が取り出せるか
バージョン情報	アプリ、DB、イメージの版を記録	互換性のある順序で戻せるか

稼働中のDBファイルをそのままコピーすると、整合性のない状態になる可能性があります。DBはアプリやデータベースが推奨するdump手順を使い、実ファイルと同じ時点へ戻せるようにします。

rcloneはオフサイト転送を担当できますが、アプリを停止する順序、DB dump、復元後のmigrationまでは自動で判断してくれません。

3-2-1の「1」をpCloudで補う

3-2-1バックアップは、一般に次の考え方です。

データを3つ持つ
2種類の異なる媒体に置く
1つを別の場所へ置く

pCloudへのrclone転送は、最後のオフサイトコピーとして使えます。ただし、pCloudだけに移してローカルの別コピーを消せば、3-2-1にはなりません。また、同じ認証情報や暗号化鍵をすべて同じ端末だけに保存すると、その端末を失ったときに復元できなくなります。

バックアップ先を増やすことより、障害ごとにどのコピーから戻すかを決めておく方が実用的でした。

公開前に伏せたい情報

rcloneの記事やトラブル相談では、動作確認のために設定やログを貼りたくなります。しかし、次の情報は公開しない方が安全です。

rclone設定ファイルの内容
OAuth token、Client Secret、暗号化パスワード
実際のremote名とバックアップ先パス
バックアップ対象のファイル名やディレクトリ構成
個人名、メールアドレス、端末名を含むログ
cronの正確な実行時刻やサーバー構成

相談時はrclone config redactedなど、公式が用意する伏字化された情報を使い、それでも公開前に内容を確認します。dry-runの出力にも実ファイル名が含まれるため注意が必要です。

復元テストのチェックリスト

[ ] 転送元と転送先を逆にしていない
[ ] syncの前に--dry-runを実行した
[ ] 転送後にrclone checkを実行した
[ ] 元の場所とは別の空ディレクトリへ復元した
[ ] 復元したファイルを実際に開いた
[ ] DB dumpを検証環境へrestoreした
[ ] 暗号化パスワードとrclone設定を別に保管した
[ ] 誤削除に備えた世代管理がある
[ ] 自動実行の失敗を検知できる
[ ] 次回の復元テスト日を決めた

まとめ

rcloneとpCloudを組み合わせると、オフサイトバックアップを比較的シンプルに作れます。ただし、copyとsyncの削除挙動を理解せずに自動化すると、元データの誤削除まで転送先へ反映する可能性があります。

最初はcopy --dry-runから始め、転送後にrclone checkを実行し、別の空ディレクトリへ戻します。そして、復元したファイルを実際に開きます。

バックアップの成功条件は、ジョブが正常終了したことでも、pCloudにファイルが見えることでもありません。必要なデータを、必要なときに、自分の手順で戻せることです。

次に読む記事

更新履歴

2026-07-12: copyとsyncの違い、dry-run、世代管理、暗号化、照合、復元テスト、情報漏洩対策を追加して全面改稿
2024-10-02: 旧版公開