要注意！BackblazeでOneDriveやDropboxがバックアップ対象外に？今のうちに設定を確認しよう

Backblazeがいつの間にかOneDriveやDropbox、その他特定のフォルダーをバックアップ対象から除外するようになっているようです。予期せぬデータ消失を防ぐため、一度バックアップ設定が正しく機能しているか確認しておくことを強くおすすめします。

除外設定もそうだけど、Backblazeで「ファイルの復元に失敗した」経験がある。無制限履歴のプランにお金を払っているのに。

サポートに問い合わせたら「ああ、そのファイルはある時点で削除されてましたね。残念ですが」って返事とともに、3ヶ月分のクレジットを提示されただけ。

もうBackblazeのバックアップなんて信用できないよ。

企業には「信頼」を商売にしているところがある。そういう会社は、信頼を得るのは大変だけど、失うのは一瞬で、取り戻すのはほぼ不可能だということを理解する必要がある。この記事を読んで、自分は間違いなくBackblazeを使うことも勧めることもないと思う。（今は使っていないけれど、これまでは歴史が長いという理由で推奨リストに入れていた会社だったのに。）

.gitフォルダをそのままバックアップしたくない理由は理論的に理解できる。Gitはコミット履歴がたまるとオブジェクト数が膨大になる問題があって、フォルダをスキャンするだけでかなりのオーバーヘッドが発生するからね。

なぜいまだにこの仕組みなのかよくわからない。Gitが多くのファイルシステムツール（バックアップに限らず）とうまく噛み合わない最大の原因だと思う。もしSQLiteデータベースみたいな形式なら、これほど無駄なinodeの肥大化は起きなかっただろうに。

とはいえ、Backblazeは「バックアップ」ソリューションなんだ。すべてをバックアップするというニーズこそが本質でしょ。彼らは3段階のバックアップ戦略（直結バックアップ、ホームバックアップ、外部バックアップ）の最後を担うと約束しているわけで、その3番目は理想的なシナリオでは一番触れる機会が少ない、最も重要な砦のはず。どんなファイルであれ勝手に除外なんてしちゃいけない。

クラウドサービスの除外も同じくらい、いやそれ以上にひどい。クリプトワーム（ランサムウェア）に感染したとこを想像してみて。クラウドストレージツールがせっせと暗号化されたファイルを同期して、全デバイスのストレージをゴミだらけにしてしまう。古いバージョンの復元は面倒だし、大規模に行うのはほぼ無理だから、そういう時のために実際のバックアップソリューションが必要なんだ。Backblazeが特定のフォルダを除外するのは、自分たちの存在意義を完全に履き違えているように感じる。

ある時、BackblazeがVeraCryptで暗号化したドライブをバックアップするのを勝手にやめてしまった。何の告知も警告も通知もなく、ただ動かなくなった。散々トラブルシューティングをしてGoogle検索を駆使した結果、redditのどこかのスレッドで、これが意図的な変更だったことを知った。それ以来、彼らのバックアップサービスは使うのをやめたよ。

Backblaze Personalのビジネスモデルにおける問題点は「無制限」という言葉にあるんだろう。彼らがLinuxユーザーを意図的に除外しているのは、まあ僕らはオタクだし、r/datahoardersみたいな連中もいるわけで、「無制限」の解釈が一般とは違うからね[1]。

これは「無制限」という言葉の解釈を巡る、両者の食い違いの別の一例に過ぎない。「ファイル形式やサイズに制限なし」と謳ってはいるけれどね[2]。

[1] https://www.reddit.com/r/backblaze/comments/jsrqoz/personal_backup_linux/
[2] https://www.backblaze.com/cloud-backup/personal

パソコン上のDropboxやOneDriveフォルダをバックアップする際のクライアントアプリの課題は「ファイルオンデマンド」機能だよ。250GBのノートPCで1TBのOneDriveを同期していても、スマート/セレクティブ同期のおかげで大丈夫なわけだ。ところがBackblazeがそのフォルダをバックアップしようとして全ファイルのダウンロードをリクエストしたら、ディスク容量はゼロになるし、バックアップはできないし、ノートPCは動かなくなる。

BackblazeアプリにOneDriveへ直接アクセスさせるOAuth設定もできるけど、OneDriveをバックアップしたいなら別の製品を使うべきだと思う。

参考までに、GitHubへのフォースプッシュからの復元はGitHubのUI[0]やAPI[1]からできるよ。
自分のマシンに対してフォースプッシュしてしまった場合はreflog[2]が使える。
[0]: https://stackoverflow.com/a/78872853
[1]: https://stackoverflow.com/a/48110879
[2]: https://stackoverflow.com/a/24236065

この件が理由でBackblazeを解約するつもり。

最近この変更を知ったんだ。Dropboxが誤って上書きしてしまったファイルを探していた父に「大丈夫、そのためにBackblazeにお金を払ってるんだから」って言ったのがきっかけでね。

数ヶ月前にポリシーが変わっていたこと、そして我々には一切通知がなかったことを知った。結局、ファイルは復元不可能だった。

もしBackblazeの人間が見ているなら言いたい。こっちは君たちの製品にお金を払って、親のマシンにインストールして安心を買っているんだ。クラウドストレージのコスト削減のためにその約束を破るなんて、最低最悪の判断だよ。

100%伝えるべきだったね。目立つ警告なしに動作を変えるなんて、到底受け入れられない。

ただ、この種のディレクトリをバックアップすること自体、昔から定義が曖昧だったのも事実。DropboxやGoogle Driveのファイルは、アクセスしたりキャッシュされたりするまで、実際にはローカルに存在していない。バックアップソフトはクラウドストレージの1TB以上のデータを全てダウンロードさせるべきなのか？ローカルシステムの空き容量が少ない場合は？ネットワークが極端に遅かったら？そもそもデータが既に除外されている%AppData%にあったらどうする？

VCSでも同じ問題がある。.gitの中身を毎分同期すべきか？毎時？そもそも.gitが整合性を保っているタイミングはいつなのか？

個人的には.gitや他のVCSは1日X回同期して、Y分間変更がなかったことを確認してから同期すればいいと思う。ClaudeならGitを考慮した専用のバックアップスクリプトを書いてくれるんじゃないかな。

でも、Google DriveやDropboxのマウントポイントは実体ではない。明記されていない限り、バックアップソフトがそこまで面倒を見ることを期待するのは無理があるよ。

自分も15年以上前にCarboniteで似たようなことがあって解約した。バックアップサービスってのは、顧客が何をバックアップしようと、中立的であるべきだと思うんだよね。