タグ: BackBlazeストレージ

前回の記事では、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.com

Backblaze 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アプリケーションからローカルストレージと同じ感覚で利用できるようにする構成をまとめます。

以前の記事でも触れましたが、筆者はWasabiの「Timed Deleted Storage（90日最低保存期間）」によって、一度約8万円という高額請求を経験しました。

『150日の亡霊』顛末記-Wasabiクラウドストレージの理解不足による重課金の罠-（長文）

もちろん、Wasabiそのものが悪いサービスというわけではありません。

バックアップ用途のように、一度保存したデータを長期間保持する使い方であれば非常に優秀です。問題だったのは、私が動かしていたアプリケーションとの組み合わせでした。

当時の環境では、MongoDBを利用するサービスが大量の一時ファイルや更新データを短時間で生成・削除しており、その挙動がWasabiの90日最低保存期間と最悪の相性になってしまいました。

さらにNextcloudでも、サムネイル生成やプレビュー画像、一時ファイルなどが絶えず作られては削除されます。

アプリケーションとしてはごく正常な動作です。しかし、Wasabiでは「90日以内に削除されたオブジェクト」であっても、残りの保存期間分がTimed Deleted Storageとして課金対象になります。

結果として、利用容量以上に「削除したデータ」が積み上がり、気付いた頃には非常に大きな請求になっていました。

この経験以降、筆者は運用を大きく見直しました。

NextcloudのデータはローカルSSDへ退避し、一時ファイルの保持期間も短縮。キャッシュやサムネイルの扱いも見直したことで、Timed Deleted Storageは12MB程度まで抑え込めています。

現在では当時のようなペナルティはほぼ発生しておらず、運用自体は十分安定しています。それでも、根本的な問題は残っていました。

実際に保存しているデータは20GB程度しかありません。（というか、Nextcloudを限定的な使い方しかしていないため増やせないという）

さらに、今後導入を考えているPiwigoのようなフォトギャラリーでは、サムネイル生成や画像整理が日常的に行われます。

「この操作をするとTimed Deleted Storageが増えるかもしれない。」

そんなことを気にしながらアプリケーションを導入したり、設定を考えたりするのは、本来あるべき運用ではありません。

サービスに合わせてアプリケーションを制限するのではなく、アプリケーションが本来の動きをしても問題にならないストレージを選びたい。

そう考え、オブジェクトストレージそのものを見直すことにしました。

Backblaze B2を候補に選んだ理由

移行先として最初に候補へ挙がったのは、Cloudflare R2とBackblaze B2でした。

どちらも個人利用では人気の高いサービスですが、筆者が重視したのは「料金」そのものではなく、「運用中に余計なことを考えなくて済むか」という点です。

Wasabiで最も苦労したのは、保存容量ではありません。「削除する」という、ごく普通の操作にコストが発生することでした。Backblaze B2では、料金はByte-Hoursという時間単位で計算されます。

サムネイルや一時ファイルを数分だけ作成して削除した場合、その数分間しか課金されません。アプリケーションが普通に動けば、料金も普通に計算される。

もちろん、小容量利用でのコスト面も魅力です。

最低利用容量はなく、10GBまでは無料。筆者のように20GB程度しか保存していない環境であれば、月額は数十円程度に収まります。

また、以前は「日本から利用するには代理店経由なのでは」と思い込んでいましたが、実際には本家サイトからそのまま個人契約でき、クレジットカードやPayPalにも対応していました。

Backblaze B2のアカウントを作成する

移行先をBackblaze B2に決めたら、まずはアカウントを作成します。

公式サイトから 「B2 Cloud Storage」 を選択し、メールアドレスとパスワードを登録するだけで利用を開始できます。個人利用でも特別な手続きは必要なく、クレジットカードやPayPalでそのまま契約できます。

途中で保存先リージョンを選択しますが、 US West を選択しました。物理的に日本へ比較的近く、レイテンシも十分実用的です。

認証メールで本人確認を済ませると、管理画面へログインできます。

Bucketを作成する

続いて、データを保存するためのBucketを作成します。

左メニューから B2 Cloud Storage → Buckets を開き、「Create a Bucket」を選択します。

設定は次のようにしました。

• Bucket Name：任意（グローバルで一意）
• Visibility：Private
• Default Encryption：今回は無効
• Object Lock：無効

Object Lockはランサムウェア対策や改ざん防止には非常に有効な機能ですが、通常のファイルサーバー用途では「削除できない」という制約が先に立ってしまいます。

バックアップ専用のバケットであれば検討する価値がありますが、今回は日常的に更新されるストレージなので無効のままとしました。

最初に変更しておきたい設定

Bucketを作成したら、最初に確認しておきたい項目があります。

それが Lifecycle Settings です。

初期設定では Keep all versions となっており、同じファイルを上書きすると以前のバージョンが残り続けます。Backblaze B2はデフォルトでファイルの世代管理を行うため、このままでは古いバージョンも保存容量に含まれます。

筆者の用途では世代管理は不要だったため、

Keep only the last version of the file

へ変更しました。これで最新版のみを保持する運用になります。もちろん、バックアップ用途で利用するのであれば「Keep all versions」の方が適しています。

ここは「どちらが正しい」という話ではなく、用途に合わせて選択する部分です。

アプリケーションキーを発行する

続いて、Linuxから接続するためのAPIキーを作成します。

管理画面の Application Keys から Add a New Application Key を選択します。

今回は次のように設定しました。

• Key Name：任意
• Bucket：作成したBucketのみ
• Access：Read and Write
• Allow List All Bucket Names：有効

最後の Allow List All Bucket Names は忘れやすい項目です。

rcloneなどがBucket一覧を取得する際に利用するため、有効にしておく方が扱いやすくなります。

キーを作成すると

• keyID
• applicationKey

が表示されます。

このうち applicationKeyはこの画面でしか表示されません。 あとから確認できないため、安全な場所へ保管しておきます。

Ubuntu 24.04へrcloneを導入する

Backblaze B2への接続には、今回は rclone を採用しました。

以前はs3fsを利用していましたが、VFSキャッシュや同期機能などを考えると、現在ではrcloneの方が扱いやすい場面が多くなっています。

Ubuntu 24.04であればAPTからそのまま導入できます。筆者は好みでaptitudeを用いています。

sudo aptitude update

sudo aptitude install -y rclone fuse3

導入後以下で確認します。

rclone version

rcloneを設定する

設定は一般ユーザーで行います。

rclone config

を実行し、新しいRemoteを作成します。主な設定は以下の通りです。

• New remote
• 名前：任意
• Storage：Backblaze B2
• Account：keyID
• Key：applicationKey

途中で

Permanently delete files on remote removal, otherwise hide files.

という質問が表示されます。筆者はここだけ true を選択しました。Backblaze B2は削除しても「Hidden Version」として残すことができますが、今回の目的は「不要なデータを残さない運用」です。

そのため、削除時は完全削除となるよう hard_delete=true を設定しています。

なお、ファイルを上書きした場合の旧バージョン保持はLifecycle設定の対象になるため、先ほどBucket側で「Keep only the last version」に変更した意味もここで生きてきます。

接続を確認する

設定が終わったら、最後に接続できることを確認します。

rclone lsd 設定した名前:

設定が正しければ、作成したBucket一覧が表示されます。

続いて簡単なファイルをアップロードしてみます。

echo "Hello, Backblaze B2 from Linux!" > test-b2.txt

rclone copyto -P test-b2.txt \
    名前:バケット名/test-b2.txt

アップロード後は、

rclone ls 名前:バケット名

で存在を確認できます。さらに削除も試してみます。

rclone delete \
    名前:バケット名/test-b2.txt

今回は、削除後もTimed Deleted Storageのような最低保存期間を気にする必要はありません。短時間だけ存在したファイルは、その存在していた時間だけが課金対象となります。

これで、ようやく「削除すると料金が増えるかもしれない」という制約から解放されました。

もちろん、料金が安くなったことも嬉しいのですが、それ以上に「アプリケーションが本来の動作をしても気にしなくて良い」という安心感の方が、筆者にとっては大きな収穫だったように思います。