前回の記事では、WasabiからBackblaze B2へ移行する理由と、B2のアカウント作成から接続確認までをまとめました。
今回は実際に、Wasabiへ保存されているデータをBackblaze B2へ移行します。
「クラウドからクラウドへデータを移す」と聞くと、一度ローカルへダウンロードし、それを再びアップロードするイメージを持つ方も多いかもしれません。
筆者も当初はその方法を考えていました。
しかし、この方法ではサーバーのディスク容量を一時的に消費するだけでなく、ダウンロードとアップロードの二重の転送が発生します。データ量が増えるほど、作業時間もストレージ使用量も無視できません。
そこで今回は、rclone が持つリモート間同期機能を利用し、WasabiからBackblaze B2へ直接データを転送しました。
Linuxサーバーはデータを一時的に中継するだけで、ローカルディスクへ保存することはありません。ストレージAPI同士がストリームとしてデータを受け渡すため、容量を気にすることなく移行できます。
本記事では、接続確認からドライラン、本番同期、そして移行後の整合性確認までの流れをまとめます。
今回の移行環境
今回の環境は次の通りです。
- サーバー：Ubuntu 24.04 LTS
- ツール：rclone
- 移行元：Wasabi（S3互換）
- 移行先：Backblaze B2
- 移行対象：
app_dataディレクトリ
今回はs3fsなどでマウントしたディレクトリは一切利用せず、rclone syncによるクラウド間同期のみで移行を行いました。
まずは接続できることを確認する
同期を始める前に、移行元・移行先の両方へ問題なく接続できることを確認します。今回は、それぞれ次のようなRemoteを登録しました。
Wasabi
[wasabi-remote]
type = s3
provider = Wasabi
access_key_id = <WASABI_ACCESS_KEY>
secret_access_key = <WASABI_SECRET_KEY>
region = ap-northeast-2
endpoint = s3.ap-northeast-2.wasabisys.comBackblaze B2
[b2-remote]
type = b2
account = <B2_APPLICATION_KEY_ID>
key = <B2_APPLICATION_KEY>
hard_delete = true設定後は、それぞれのバケット一覧が取得できることを確認します。
# Wasabi
rclone lsd wasabi-remote:
# Backblaze B2
rclone lsd b2-remote:ここでエラーが出るようであれば、APIキーやアクセス権限を見直しておきます。
最初に移行対象を確認する
同期コマンドを実行する前に、まず対象となるデータ量を確認します。
容量だけではなく、オブジェクト数もこの段階で記録しておくと、移行後の確認が非常に楽になります。
rclone size wasabi-remote:src-storage/app_data筆者の環境では、
Total objects: 769 (769)
Total size: 454.601 MiB (476683987 Byte)という結果になりました。
今回は約455MBと比較的小規模ですが、この数字はあとでBackblaze B2側と比較する重要な基準になります。
いきなり同期せず、まずはドライランを行う
rclone syncは非常に便利ですが、その名前の通り「同期」を行うコマンドです。
移行先との差分によっては削除や上書きも実行されるため、筆者はいきなり本番を流すことはほとんどありません。
まずは--dry-runを付け、実際には転送を行わず、どのような処理が実行されるかだけを確認します。
rclone sync \
wasabi-remote:src-storage/app_data \
b2-remote:dest-backup/app_data \
--dry-run \
-P \
-v今回の結果は次の通りでした。
Transferred: 454.601 MiB / 454.601 MiB, 100%, 318.497 MiB/s, ETA 0s
Transferred: 769 / 769, 100%
Elapsed time: 3.0s全769オブジェクトについて問題なく処理できることを確認できました。
ドライランで異常がなければ、本番へ進みます。
本番同期を実行する
確認が終わったら、--dry-runを外して実際の同期を行います。
rclone sync \
wasabi-remote:src-storage/app_data \
b2-remote:dest-backup/app_data \
-P \
--transfers 4 \
--checkers 8今回は並列転送数を4、差分確認を8として実行しました。この値は回線速度やCPU性能によって最適値が異なりますが、個人サーバー程度であれば十分扱いやすい設定です。
今回のデータ量では、同期自体は数秒程度で完了しました。ローカルディスクを経由していないため、サーバー側の空き容量を気にすることなく作業できたのは大きな利点でした。
移行後は必ず整合性を確認する
同期が終了したら、「終わった」で済ませず、必ず移行先を確認します。まずはBackblaze B2側で同じように容量を集計します。
rclone size b2-remote:dest-backup/app_data結果は、
Total objects: 769 (769)
Total size: 454.601 MiB (476683987 Byte)となりました。
移行前に確認した
- オブジェクト数
- 総容量
の両方が完全に一致しています。さらにBackblaze B2のWebコンソールでもファイル数と容量を確認し、問題なく反映されていることを確認しました。
ここまで確認できれば、データ移行は完了です。
おわりに
今回の移行作業そのものは数分で終わりました。しかし、本当に時間を掛けたのは「どのストレージへ移るか」を考えることだったように思います。
以前のWasabiでは、Timed Deleted Storageを意識してアプリケーションの設定まで調整する必要がありました。
もちろん、その経験があったからこそ、料金体系だけではなく「普段どのようなファイルが生成・削除されるのか」という視点でストレージを選ぶようになりました。
オブジェクトストレージは、容量や価格だけを比較してしまいがちです。
しかし実際には、アプリケーションの動作と料金体系が噛み合っているかどうかの方が、長く運用していく上では重要なのだと改めて感じています。
次回は、このBackblaze B2をLinuxへマウントし、NextcloudやPiwigoなどのWebアプリケーションからローカルストレージと同じ感覚で利用できるようにする構成をまとめます。
