.gitフォルダもいつの間にかバックアップされなくなっていた**という体験談が語られているRobert Reese氏の記事は、かなり率直で、しかもなかなか強烈です。ひと言でまとめると、「Backblazeは昔のように“全部をバックアップする”サービスではなくなっているのではないか」という告発です。
Backblazeは、個人向けのクラウドバックアップサービスとして知られています。
ざっくり言うと、PCの中身をクラウドに丸ごと保存しておいて、もしPCが壊れてもデータを取り戻せるようにする仕組みです。外付けHDDにこまめにコピーを取る代わりに、クラウドでやるイメージですね。
筆者は10年ほどBackblazeを使ってきて、実際にハードディスク故障の際にデータを復元できた経験もあり、かなり信頼していたようです。だからこそ、今回の変化は「裏切られた」と感じるレベルだったわけです。
筆者がまず気づいたのは、**.gitフォルダがバックアップされなくなっていた**ことでした。
.gitフォルダというのは、Gitというバージョン管理システムが変更履歴を保存している場所です。
Gitはプログラマーにとっては定番の道具で、ざっくり言えば「いつ、誰が、何を変えたか」の履歴を残すための仕組みです。コードそのものが消えていなくても、この履歴がないとかなり困ることがあります。
筆者は、GitHubに push -f して履歴を飛ばしてしまったとき、Backblazeから復元しようとしたそうです。ところが、すでに .git が対象外になっていて復元できなかった。これはかなり痛いです。単なる“ファイル”ではなく、開発の記録そのものが消えるわけですから。
そしてさらに驚くべきことに、OneDriveフォルダもバックアップ対象から外れていたことに気づきます。
Redditで「Dropboxフォルダがバックアップされていない」というスレッドを見て不安になり、自分のBackblazeを確認したところ、OneDriveフォルダが消えていた、という流れです。
ここ、かなり重要です。
筆者が怒っているのは「仕様変更そのもの」だけではありません。その変更が静かに行われ、しかも分かりやすく通知されていないことです。これはたしかに不信感が強まります。個人的にも、こういう“後からじわじわ効いてくる変更”はかなり嫌ですね。
この記事では、OneDriveやDropboxはすでにクラウド上にあるのだから、Backblazeでバックアップしなくてもいいのでは？という反論にも触れています。
でも筆者は、同期（sync）とバックアップ（backup）は違うと強く主張しています。
これは大事なポイントです。
OneDriveやDropboxは便利ですが、削除や変更が反映されるため、「消したら終わり」になりやすい。
さらに、無料/通常プランでは古いファイルや削除済みファイルの保持期間も限られます。筆者はOneDriveの削除ファイル保持は1か月、Backblazeはもっと長い保持がある、と比較しています。
つまり、クラウド同期フォルダに入れたから安心、ではないということです。
むしろ、同期サービス側のルール次第では、バックアップとしての強さは思ったほど高くありません。ここは一般の人が誤解しやすいところなので、記事の指摘はかなり筋が通っています。
筆者が最も腹を立てているのは、Backblazeがこの変更を大きく告知しなかった点です。
記事ではBackblazeのrelease notes（更新履歴）に、次のような説明があったと紹介されています。
クラウドストレージの人気プロバイダをバックアップ対象から除外した。OneDrive、Google Drive、Dropbox、Boxなどの mount points と cache directories を除外する。性能問題や過剰なデータ使用、意図しないアップロードを防ぐため。Backblazeはローカルで直接接続されたストレージのみをバックアップする方針に合わせた。
要するに、
「クラウド同期フォルダはバックアップしません」
という方針に変えたわけです。
ただし、筆者の主張はここで鋭いです。
「それを“improvements（改善）”と呼ぶのは無理があるだろう」と。たしかに、ユーザー目線では改善というより機能削減に見えます。これは言い方の問題ではなく、体験としてかなり大きい違いです。
しかも、Backblazeの設定画面や除外リストを見ても、DropboxやOneDrive、さらには.gitについて、はっきりした説明が見当たらないと筆者は言っています。
つまり、ユーザーが自分で気づかない限り、重要なデータが守られていない可能性がある。これはバックアップサービスとしてかなり怖いです。
筆者の結論はかなり過激です。
「Backblazeは一部のデータしかバックアップしていない。だから、もはや“バックアップしている”とは言えない」というものです。
もちろん、これは筆者の強い意見です。
でも、言いたいことは分かります。バックアップって、結局のところ信頼商品なんですよね。
「必要なときに戻せるはず」という期待にお金を払っているわけです。だから、見えないところで対象外が増えていると、サービスの根っこが揺らぐ。
個人的には、この怒りはかなり自然だと思います。
技術的にどんな理屈があろうと、ユーザーにとっては「保存されていると思っていたものが保存されていなかった」だけで致命的です。しかもそれが、明確な警告なしに起きたなら、なおさらです。
ここは少しバランスも取っておきたいところです。
Backblaze側の説明には、「クラウド同期フォルダはローカルストレージではない」という考え方があります。
つまり、OneDriveやDropboxはすでにクラウドと同期しているから、さらにBackblazeがそこをバックアップすると、無駄が多かったり、意図しない容量消費や複雑化が起きたりする、という理屈です。
この理屈自体は、理解はできます。
ただし、問題は**“理屈があること”と“ユーザーが納得できること”は別**だという点です。
バックアップサービスは、「何を保存するか」をユーザーが細かく意識しなくてもいいのが便利なはずです。
そこを後から狭めるなら、もっと丁寧に、もっと大きく知らせるべきだった。ここはかなり同意します。
この記事を読むと、バックアップサービスは「入れて終わり」ではないと改めて感じます。
むしろ、定期的に“本当に必要なものが入っているか”を確認する作業が必要なんですよね。
これは面倒です。正直かなり面倒。
でも、壊れたときに初めて「入ってなかった」と気づくよりは、はるかにマシです。
特に次のようなものは要注意です。
.git）バックアップソフトが「よかれと思って」除外してしまう可能性は、想像以上にあります。
ここは本当に、ユーザー側の確認が必要だと思います。
この記事は、単なる“サービス批判”ではなく、バックアップという仕組みそのものへの警告として読むと面白いです。
筆者の怒りはかなり強いですが、その怒りの背景には、
「バックアップは全部を守ってくれるものだと思っていたのに、静かに例外が増えていた」
という、かなりリアルな失望があります。
個人的には、この記事は少し感情的ではあるものの、だからこそ重要だと思います。
バックアップは、ふだん意識しないからこそ危ない。
そして、静かな仕様変更ほど怖いものはない。そう感じさせる記事でした。
参考: Backblaze has quietly stopped backing up your data | Robert Reese's Website