世界を動かす技術を、日本語で。

Backblazeがデータのバックアップを停止しました

2026年4月14日原文(rareese.com)

概要

  • Backblaze は、ユーザーに通知せずに OneDriveやDropbox のフォルダのバックアップを停止
  • 長年利用してきたが、 信頼性に疑念 が生じた体験談
  • クラウド同期と バックアップの違い についての注意喚起
  • 仕様変更が告知されず、重要なデータがバックアップ対象外となる危険性
  • サービスの根本的な約束違反 として警鐘を鳴らす内容

Backblazeのバックアップ方針変更に対する不信感

  • 2015年からBackblaze を利用し、以前は外付けHDDでバックアップ運用
  • 無制限ストレージ やシンプルなアプリ設計、評判の良さが導入理由
  • ハードディスク故障時の 復元サービス体験 で高い信頼を得ていた実績
  • アプリの操作性やWebサイトの使い勝手に 小さな不満 があったものの、全データが守られる安心感が優先
  • ファイル名流出事故 などの過去の問題も、全体的な信頼感で受容

バックアップソフトの本質と理想

  • バックアップソフトの役割は 全ての必要なファイルを守ること
  • ユーザーごとに 重要なファイルやワークフローが異なる ため、包括的なバックアップが理想
  • バックアップ事業者は 未来のニーズを予測できない ため、原則として全データを保護すべき

仕様変更の発覚と失望

  • 2025年、.gitフォルダがバックアップ対象外 になっていることに気付き、復元できず失望
  • 除外リスト に記載がなく、ユーザーが気づきにくい仕様
  • RedditでDropboxフォルダが対象外 になったことを知り、自身のOneDriveもバックアップされていないと判明
  • 事前通知や警告が一切なく、リリースノートの一文のみ で説明
  • クラウドストレージのフォルダやキャッシュを除外」という“改善”として扱われているが、実質的なサービスダウン

クラウド同期とバックアップの違い

  • OneDriveやDropboxは同期サービス であり、バックアップとは異なる
  • 多くのクラウドサービスは 削除ファイルやバージョン履歴の保持期間が短い
  • アカウント凍結やサービス障害時に データ消失リスク が高い
  • Backblazeの 長期保存や無制限保存 のメリットが失われた現状

サービスの信頼性と今後の懸念

  • 重要な仕様変更がユーザーに通知されない 運用体制
  • 除外対象が 今後さらに増えるリスク
  • 業務や趣味で使う独自ファイル形式 が突然バックアップ対象外となる可能性
  • 公式サイトやアプリ上で除外リストが十分に明示されていない 問題
  • 全てのデータを守る」という根本的な約束が破られたと感じるユーザー視点

まとめと警鐘

  • 2015年当時の「全データ無制限バックアップ」 という約束が事実上反故
  • バックアップは 信頼関係 で成り立つサービスであることの再認識
  • Backblazeは 一部のデータしか守らないサービス へ変質
  • 今後も 仕様変更や除外対象追加のリスク があるため、利用者は注意が必要
  • 「シンプルにした結果、バックアップ自体をやめてしまった」 という皮肉な結末

Hackerたちの意見

これに気づいたんだけど(幸いにも重大になる前に)、BBから移行することにしたよ。10年以上の顧客なのに、完全におかしい。バックアップが止まっただけじゃなくて、古い履歴も全部消えちゃった。彼らがやるべきことは、すべてをバックアップすることなのに、コンソールでそれが確認できると安心できるはずなのに。デスクトップクライアントを放置してるし、意味のある例外を追加するのも難しい。今はみんなB2を使わせたいのが明らかだね。

今は何を使ってるの?友達のために聞いてるんだけど。

除外設定は一つの問題だけど、バックブレイズがファイルの復元に失敗したことがあるんだ。無制限の履歴にお金を払ってるのに。サポートに「何が起こったの?」って問い合わせたら、「ああ、そのファイルはどこかで削除されちゃった、ごめんね」って言われて、3ヶ月分のクレジットを提案された。もうバックブレイズのバックアップは信じられないよ。

何それ

もっと詳しい情報ある?これは結構大事なことだと思う。BackblazeとHetznerの違いは、こういうことができないっていうのが主なポイントだから。

私もBackblazeで同じような経験をしたことがある。3年前にデスクトップクライアントを使ってファイルを復元しようとしたんだけど、最初に気づいたのは、ネットワークや他の問題でファイルがダウンロードできないと、そのままスキップされちゃうこと。だけど、ジョブファイルをいじることで再試行させることができるんだ。それはSQLiteのDBみたいなものだし。ファイルは小さなチャンクに分けて保存・ダウンロードされるんだけど、これらのチャンクのチェックサムは保存されてるけど、ファイル全体のチェックサムは保存されてないから、クライアントの出来が悪いせいで、復元したファイルが壊れてないかどうか確信が持てないんだ。それに、何度も再試行してもダウンロードできないファイルがあって、どうやらBackblaze側で壊れてるみたい。でも、一番イラッとしたのは、非ASCIIのファイル名が全部ぐちゃぐちゃになっちゃったこと。DBではUTF-8で保存されてるけど、クライアントはWindows-1252とかで保存しちゃうから、最終的にфикацみたいな名前のファイルが何百ギガもできちゃった。名前を元に戻すために再エンコードすることもできないし、プロセス中にいくつかの文字が消えちゃったからね。Backblazeクライアントにファイルを再ダウンロードさせて、復元できないファイルをログに記録して、壊れた名前を修正して、復元したファイルをまたチャンクに分けてチェックサムをSQLite DBと照合するスクリプトを書こうと思ったけど、あまりにも大変すぎて3年間先延ばしにしちゃった。データを手放すのは悲しいから、毎月Backblazeの料金を払い続けてたよ。あれからクライアントは改善されたのかな。

ある企業は信頼をビジネスにしている。こういう企業は、信頼を得るのは難しいけど、失うのは簡単で、取り戻すのはほぼ不可能だってことを理解する必要がある。この記事を読んで、バックブレイズを使ったり勧めたりすることはほぼないだろうな。(今は使ってないけど、彼らは歴史が長いから勧めるリストに入ってたんだ。)

理論的には、.gitフォルダーをそのままバックアップしたくない理由は理解できる。コミット履歴が多いリポジトリだと、Gitはオブジェクト数の膨張問題が深刻で、ファイルをスキャンするだけでも余計なオーバーヘッドがかかるからね。まだこうなってる理由はよくわからないけど、これが原因でGitが多くのファイルシステムツール(バックアップだけじゃなくて)とうまく連携できない理由の一つだと思う。もしSQLiteデータベースみたいなものだったら(本当に例えだけど)、そんなに不要なinodeの膨張は起こらなかっただろうね。それに、バックブレイズはバックアップソリューションなんだから、すべてをバックアップする必要があるのは当然だよ。彼らは三層戦略の三つ目のバックアップソリューションになるって約束してるけど、その三つ目が一番重要だと思う。理想的なシナリオでは一番触れないものだからね。ファイルを除外するなんてありえないよ。クラウドサービスの除外も同様にひどい。例えば、クリプトワームにやられたらどうなるか想像してみて。クラウドストレージツールは、すべてを暗号化して同期するから、デバイス間でストレージがぐちゃぐちゃになっちゃう。古いバージョンの復元も難しいし、実際のバックアップソリューションが必要になる。バックブレイズがこれらのフォルダーのファイルを除外するのは、彼らの目的を完全に誤解しているように感じる。

もしSQLiteデータベースみたいなものであったなら(本当にただの例だけど)Fossilを見てみてね(https://fossil-scm.org/) P.S. ここにも(https://www.sourcegear.com/vault/) > SourceGear Vault Proはプロの開発チーム向けのバージョン管理とバグ追跡ソリューションだよ。Vault Standardはバージョン管理だけを求める人向け。VaultはMicrosoft SQL ServerやIIS Web Servicesなどの技術を使ったクライアント/サーバーアーキテクチャに基づいていて、パフォーマンス、スケーラビリティ、セキュリティを向上させているんだ。

gitオブジェクトを個別にバックアップする必要はないと思うよ。gitがバージョン情報を管理してるからね。 .gitフォルダ自体を圧縮して、1つのユニットとしてバックアップすればいいんじゃないかな。

Backblazeやほとんどのユーザーにとって理解できることだと思うけど、解決策としてはデフォルトの除外リストに.gitを追加して、ユーザーが管理できるようにするのがいいんじゃないかな。

多分、Linusがカーネルやファイルシステムのオタクで、データベースのオタクじゃないからだと思う。だから、彼はパフォーマンス特性をよく理解しているファイルシステムを使う方が好きだったんじゃないかな(少なくともLinuxでは)。

Hacker Newsで議論の続きを見る