RcloneViewのCheckとCompare機能でクラウドファイルの整合性を検証する
クラウドにファイルをコピーするのは仕事の半分に過ぎません。すべてのバイトが無事に届いたことを検証することこそが、信頼できるワークフローと希望的観測との違いを生みます。
数テラバイトをプロバイダー間で移動したり、夜間バックアップを実行したり、重要なデータセットをアーカイブしたりする作業には、いずれも共通のリスクがあります。それは、静かに進行するデータ破損です。転送の中断やプロバイダー側のバグ、あるいは時間の経過によるビットロットが原因で、送信先にファイルが存在しているように見えても、実際は元のファイルと異なっている場合があります。Rcloneには送信元と送信先をファイル単位で比較する専用のcheckコマンドが用意されており、RcloneViewはそのプロセスを視覚的でわかりやすいものにします。このガイドでは、クラウドファイルをいつ、どのように検証すればよいかを説明します。
すべてのクラウドを一か所で管理・同期
RcloneViewはrcloneのクロスプラットフォームGUIです。フォルダを比較し、ファイルを転送・同期し、クリーンなビジュアルインターフェースでマルチクラウドのワークフローを自動化できます。
- ワンクリック操作: コピー · 同期 · 比較
- 信頼性の高い自動化のためのスケジューラーと履歴
- Google Drive、OneDrive、Dropbox、S3、WebDAV、SFTPなどに対応
コア機能は無料。Plusで自動化機能を利用可能。
ファイル整合性の検証が重要な理由
クラウドプロバイダーは内部でデータを複製していますが、エラーから完全に免れているシステムはありません。ここでは、検証によって実際の問題を発見できる代表的なシナリオを紹介します。
- 転送の中断 -- 大容量コピー中の ネットワーク切断により、名前だけでは完全に見える不完全なファイルが送信先に残ることがあります。
- ビットロット -- ストレージメディアは数か月から数年かけて劣化し、めったにアクセスされないファイルのビットが反転することがあります。
- プロバイダー側のバグ -- まれに発生するAPIエラーにより、エラーを出さずにゼロバイトのアップロードや途中で切れた書き込みが発生することがあります。
- 移行の検証 -- 数十万件のファイルをプロバイダー間で移動した後は、何も失われたり変更されたりしていないことの証明が必要です。
検証ステップがなければ、これらの問題は実際にファイルが必要になるまで発見されません。
Rclone Checkの仕組み
rclone checkコマンドは、送信元と送信先のパスを比較し、異なるファイルを報告します。関与するプロバイダーによって、以下のいずれかの方法が使用されます。
| 方法 | 仕組み | 使用される場面 |
|---|---|---|
| ハッシュチェック | 両方のプロバイダーが報告するチェックサム(MD5、SHA1など)を比較する | 両方のプロバイダーが共通のハッシュをサポートしている場合 |
| サイズチェック | ファイルサイズのみを比較する | 共通のハッシュが利用できない場合 |
| ダウンロードチェック | 両方のファイルをダウンロードしてバイト単位で比較する | --downloadフラグで強制した場合 |
両方のプロバイダーがサポートしている場合、ハッシュベースのチェックが最も高速かつ信頼性の高い方法です。Google Drive、OneDrive、S3互換プロバイダー、Backblaze B2はいずれもファイルハッシュを報告しますが、必ずしも同じ種類のハッシュとは限りません。
RcloneViewでCompareを使用する
RcloneView内蔵のCompare機能を使うと、送信元と送信先のフォルダーを視覚的に並べて表示できます。
- Explorerペインを開き、片側に送信元のリモート、もう片側に送信先を選択します。
- 比較したいフォルダーに移動します。
- Compareをクリックして解析を実行します。
- 結果を確認します -- ファイルは一致、送信元のみ、送信先のみ、相違ありといった状態ごとに色分けされます。
この視覚的なアプローチは、特定のフォルダーを抜き取りで確認したり、コマンドライン出力を覚えずに移行後の結果を確認したりするのに最適です。
ターミナルからRclone Checkを実行する
リモート全体の完全な整合性スキャンを行うには、RcloneViewでTerminalを開き、以下を実行します。
rclone check source:path dest:path
知っておくと便利なフラグ:
| フラグ | 目的 |
|---|---|
--size-only | サイズのみで比較し、ハッシュチェックをスキップする |
--download | 両方のコピーをダウンロードしてバイト単位の比較を強制する |
--one-way | 送信元のファイ ルが送信先に存在するかのみをチェックする(逆方向はチェックしない) |
--combined report.txt | 一致・不一致の結合レポートをファイルに書き出す |
--missing-on-src missing.txt | 送信先には存在するが送信元にはないファイルを記録する |
--missing-on-dst missing.txt | 送信元には存在するが送信先にはないファイルを記録する |
--error errors.txt | チェックに失敗したファイルを記録する |
移行後の徹底的なチェックの例:
rclone check gdrive:/Archive s3-backup:archive-bucket --combined /tmp/check-report.txt
移行後の検証ワークフロー
プロバイダー間でデータを移行した後は、以下のワークフローに従って成功を確認してください。
- 一方向チェックを実行し、送信元のファイルがすべて送信先に届いたことを確認します。
rclone check source:path dest:path --one-way - 不一致を確認 -- 差異が報告されたファイルは再コピーが必要です。
- RcloneViewのコピーまたは同期機能で
--ignore-existingを外して失敗したファイルを再転送します。 - 再度チェックを実行し、すべての差異が解消されたことを確認します。
--combinedフラグを使用して監査目的でレポートを保存します 。
経年によるビットロットの検出
長期アーカイブについては、定期的な整合性チェックをスケジュールしましょう。
- RcloneViewでアーカイブに対して
rclone checkを実行するジョブを作成します。 - Job Schedulerを使って、毎週または毎月実行するようにスケジュールします。
- 実行のたびにジョブ履歴を確認し、新たに破損したファイルがないかチェックします。
これは特に、ファイルが一度書き込まれてほとんど読み込まれることのないコールドストレージ層(S3 Glacier、Backblaze B2アーカイブなど)において重要です。
プロバイダー間のチェックサム互換性
すべてのプロバイダーが同じハッシュアルゴリズムをサポートしているわけではありません。簡単な早見表を以下に示します。
| プロバイダー | MD5 | SHA1 | その他 |
|---|---|---|---|
| Google Drive | あり | なし | Quickxorが利用可能 |
| OneDrive | なし | なし | QuickXorHash |
| Amazon S3 | あり(シングルパートの場合はETag) | なし | -- |
| Backblaze B2 | なし | あり | ネイティブのSHA1 |
| Dropbox | なし | なし | Dropboxコンテンツハッシュ |
| SFTP/Local | あり | あり | 複数対応 |
2つのプロバイダーが共通のハッシュを持たない場合、rcloneはサイズのみの比較にフォールバックします。そのような場合にバイトレベルの確実性が必要なら、--downloadを使用してください。
ベストプラクティス
- 大規模な移行の後は必ず検証する -- コピーコマンドが成功したからといって、すべてのファイルが無傷であるとは限りません。
--combinedレポートを活用し、何が一致し、何が一致しなかったかを監査可能な記録として残しましょう。- 数か月間手を付けないアーカイブデータには、定期的なチェックをスケジュールしましょう。
- 可能な限り、サイズのみのチェックよりもハッシュチェックを優先しましょう -- 同一サイズでの破損はまれですが実際に起こり得ます。
- チェック後にドライランの同期を実行し、不一致を自動的に修正しましょう。
関連ガイド:
対応クラウドプロバイダー
