2 ポイント 投稿者 GN⁺ 2023-11-28 | 1件のコメント | WhatsAppで共有
  • Windows向け Google Drive for desktop の利用者が、Drive が 2023年5月の状態に戻ったように 見え、それ以降のデータやフォルダ構成の変更が消えたとして支援を求めた
  • アクティビティ履歴にも5月の記録しか表示されず、自分で削除したファイルもないため、通常の削除復元経路である ゴミ箱でもファイルを見つけられなかった
  • Google サポートチームが案内した復旧プログラムと DriveFS フォルダのバックアップ・復元 手順は効果がなく、エンジニアによる確認が行われているかどうかも分からなかったという
  • 他の利用者からも、フォルダ・ファイルの欠落、ローカルファイルの未アップロード、Drive desktop の長期的な不具合など、似た問題が報告されている
  • Google Drive コミュニティマネージャーは調査が完了し、解決策があると案内し、Drive for desktop v84.0.0.0〜84.0.4.0 の同期問題に関する Forum 投稿へ案内している

最初に報告された症状

  • Windows の Drive for Desktop 利用者が、Google Drive のファイルが突然消えたと報告した
  • Drive が文字どおり 2023年5月の状態 に戻ったように見え、5月から報告時点までのデータが消失した
  • フォルダ構成も5月時点の状態に戻ったように見えた
  • Google Drive のアクティビティ履歴には変更内容が見当たらず、5月のアクティビティだけが表示された
  • ファイルを手動で削除していないため、ゴミ箱にもファイルはなかった としている
  • 利用者は、ファイルや Drive を他人と同期・共有しておらず、ローカルで使っていたと説明した

復旧の試みと行き詰まった点

  • 韓国の Google サポートチームの案内に従って 復旧プログラム を実行したが失敗した
  • DriveFS フォルダをバックアップして復元するよう案内されたが、変化はなかった
  • その後、米国側と見られる Google サポートチームにも問題を報告し、エンジニアにエスカレーションするよう案内された
  • エンジニアからの返答はなく、問題が調査中なのかも分からなかったという
  • 利用者は数日前まで Drive を使っており、翌朝に問題が発生したと説明している

続いた類似事例

  • 他の利用者も同じ問題を経験しているとコメントを残した
  • 一部の利用者はフォルダやファイルが消え、案内された復旧オプションが機能しないとしている
  • ある利用者は 2年分のファイル を失ったと述べた
  • 別の利用者は、ローカルにはファイルがあるが、2週間にわたってクラウドへアップロードされていなかったと述べた
  • 2023年12月末と2024年1月にも、Drive desktop がほぼ1か月動作しなかったり、PC の共有フォルダの一部が drive.google.com に表示されなかったりするとのコメントが続いた

Google の案内と関連リンク

  • Google Drive コミュニティマネージャーは、チームが問題を調査し、解決策があると案内した
  • 案内されたリンク先は Drive for desktop v84.0.0.0 - 84.0.4.0 Sync Issue である
  • この回答は Google 社員の Dave - Sr. Product Support Manager が推奨している
  • その後、Product Expert Alumni は、元の Drive for Desktop の問題を抱える利用者に対し、Google サポート文書 を参照し、1対1サポートへ連絡するよう案内を共有した
  • Drive for Desktop の問題とは無関係な一般的なファイル復旧の問い合わせについては、別の ファイル復旧案内スレッド に従うよう区別している

利用者に残った影響

  • 一部の利用者は1か月近くファイルを復旧できず、追加ストレージ料金を払い続けていると述べている
  • 復旧メニュー自体が存在せず、案内された手順を使えないというコメントもある
  • 業務の証憑、出生証明書、従業員の勤務記録など、重要なファイルを見つけられないという事例が続いている
  • 最初のスレッドはロックされており、返信の投稿は無効化されている

1件のコメント

 
GN⁺ 2023-11-28
Hacker Newsの意見
  • 余談だが、顧客が巨大企業のサポートフォーラムでボランティアをする動機が気になる
    反応の速いコミュニティがあるのは良いことだが、時価総額1兆ドルの企業なら、優れたカスタマーサポートにお金を使うべきだと思う
    この場合でも、ボランティアのカスタマーサポート担当者は「私たちはボランティアなのでユーザーアカウントにはアクセスできず、経験の共有しかできない。このケースでできることはない」と答えるだけで、Googleがこの問題を見たのかどうかすら知る方法がない

    • Google Play Storeに登録するにはカスタマーサポートを提供しなければならない、という点が皮肉
      https://support.google.com/googleplay/android-developer/answ...
      各アプリについて、有料アプリやアプリ内課金に関するユーザーの質問に適時回答し、カスタマーサポートの質問には3営業日以内に返信し、Googleが緊急の製品問題で連絡してきた場合は24時間以内に返答しなければならない、とされている
    • 他のサポートフォーラムで他人を助けるボランティアたちと動機は同じだと思う
      製品の背後にある会社の時価総額がいくらであっても、人間の本性は変わらない
      Microsoft SQL ServerやBlender関連のStack Overflow貢献者たちと何が違うと期待しているのか分からないし、たとえ偽のインターネットポイントをもらうだけでも、単に人を助けることを楽しむ人もいる
    • こうした議論に、社員でもない人たちがなぜ関わってくるのか理解できない
      こういう場合、提供できる助けはまったくない
    • オーストラリア市場でPixel Watch 2の通信事業者サポート状況を検索していたら、Google Supportのスレッドにたどり着いたが、どの通信事業者がいつ時計をサポートするのかという質問の「採用された回答」が、ヨーロッパにいるサポートボランティアの回答だった
      その人はサポート文書を繰り返し、権威ある回答のふりをしていただけで、何の価値も加えておらず、「採用された回答」のせいでスレッドが終わってしまった
      なぜ時間をかけてこんなことをするのか気になって見てみたところ、一部の人にとっては単なる履歴書用の活動に見えた
    • 最近、GitHubで人間と連絡を取ろうとした
      https://github.com/pricingページには、認証済みの教師で、すでにCopilotを購読している場合はどうなるのかをサポートチームに問い合わせるよう明確に書かれていた
      しかしGitHubの誰かに連絡するのは事実上不可能に見え、どの試みも自動返信と投稿のクローズに行き着いた
      ヘルプフォーラムにも投稿したが、当然ながら返答は得られなかった
      この件以降、重要なものはGitHubだけに置かないようになり、今後ほかの問題が起きても何の助けも受けられないだろうと思うようになった
      注意すべきなのは当然だが、こうした問題を経験すると、現代の大企業と連絡を取ることがどれほど難しいかを実感する
  • データが消えたという別のサポート依頼もある
    https://support.google.com/drive/thread/245534268/a-spreadsh...
    https://support.google.com/drive/thread/245524854/data-in-go...
    https://support.google.com/drive/thread/245596891/5-months-o...
    https://support.google.com/drive/thread/245661673/disappeari...
    https://support.google.com/drive/thread/245407620/i-can-t-fi...

  • 自分のデータもGoogle Takeoutでダンプしておくべきだと思った
    https://takeout.google.com

    • 外付けの4TB SSDを買い、Google側で大事故が起きてデータが永久に削除される場合に備え、数週間ごとにTakeoutでダウンロードしてオフラインバックアップを取っている
      ローカルドライブは「耐火」金庫に保管している
      ただし耐火という言葉は少し不正確で、耐火金庫の中でも物は燃えることがあるが、家やアパートで火事が起きたときに何もないよりはまし
      3つ目の外部バックアップとしてAmazon Glacierにもバックアップしている
      S3も使えるが、Glacierより少し高くなる可能性がある
    • RcloneはGoogle Driveをバックアップでき、Docsは.docxで、Sheetsは.xlsxで取得できる
      どのクラウドプロバイダーに対しても、より優れたファイル転送ツールだと思う
      https://rclone.org/
    • 見落としやすい注意点が1つある
      自分に共有されたファイルは、自分が容量上限を超えている、または所属組織が容量上限を超えている状態だとエクスポートされない
      すべてを手動でローカルにダウンロードするか、こうしたファイルを取得する別のツールを探す必要がある
    • Nestデータで試したところ、数日後に「問題が発生したので後でもう一度試してほしい」というメールを受け取っただけだった
    • Appleもこのようにデータを一か所からエクスポートできる機能を提供してくれたらよいと思う
  • 有料の企業向けグレードの Google Workspace アカウントでも似たようなことがあった
    ある日、Drive 全体が文字どおり約6年前にタイムトラベルしたかのように変わり、数十GBのファイルが消えた代わりに、100%削除したはずの古いファイル数十GBがその場所に現れた
    「Google は本当に削除しているのか」という方向に深く考えすぎるつもりはないが、Workspace アカウントなので「データを実際には絶対に削除しない」ような設定が有効になっている可能性もある
    Workspace の管理者 UI は理解するのに博士号が必要なほどなので、確認はしていない
    すべてをローカル NAS に同期していたので大きく心配はせず、思い出旅行のようでかなり興味深かった
    翌日には正常に戻った

    • こういう状況ではユーザーと調整すべきだと思う
      すでにユーザーが自分で修復し始めていたら、その作業もロールバックされたのだろうか?
      あるいはその機会にフォルダ構成を大きく整理したり再構成したりしていたら、どうなっていたのだろう?
    • 「データを実際には絶対に削除しない」設定はほぼ確実にあると思う
      ユーザーが誤って全部削除したときに、システム管理者が復元できるようにする機能
      Workspace の管理者 UI はエンドユーザーではなく、訓練を受けたシステム管理者向けに設計されており、それでも少し検索すればかなり簡単に分かる
  • Google Drive や、同期された状態を扱うクラウド全般の問題はこれだ
    人々は「ローカルコンピュータにもクラウドにもあるから、ずっと安全だ」と考える
    しかし、ユーザーがデータの消失に気づくまで、見えないところで悪いことがたくさん起こり得る
    ディスクにファイルを保存したのにクラウドクライアントに問題が起きると、特に接続が悪い場合、ファイルがまったく同期されず、OS の再インストール時に失ったり、ローカルからも削除されたりする可能性がある
    クラウド提供者側で問題が起きてバックアップを復元すると、その復元された状態が再び自分のコンピュータに同期される
    提供者が何らかのファイルを嫌うようになれば、たとえばアンチウイルスが検出した場合、サーバーから削除され、それが自分のコンピュータにも同期される
    誤検知かもしれないし、感染したファイルを保管しておく理由があるかもしれない
    Google Drive の公式クライアントはかなりよく作られていると思って長く使ってきたが、バグは起きる
    結論は、自分でバックアップすべきだということだ

    • 比較対象が間違っている
      平均的な消費者はそもそもバックアップをまったく取っておらず、ものをクラウドサービスに置くだけでも、その方式よりは大きな改善だ
    • 「自分でバックアップしろ」というのは、新鮮な食材で自炊すれば健康的に食べやすい、という話に似ている
      綿密に定期的にバックアップを作り、復元テストをするのが最善だとは分かっているが、そこまで真面目にやる人は非常に少ない
      自動化の余地はあるが、その場合でもバグで静かに失敗し、忙しい人が手遅れになってから気づくリスクに戻ってしまう
    • 結局はプレッパー的な考え方に近い
      すべてはリスクであり、各自が許容できるリスク水準を決める必要がある
      クラウドに問題があるかといえば、ある
      しかしほとんどの人は、クラウド提供者よりもローカルバックアップを台無しにする可能性のほうがはるかに高い
      平均的な人が外付けハードディスクをどう扱うかを見ると、中に壊れやすいガラスのディスクが入っていることを知らないように見える
  • 私も先週木曜日に6か月分のファイルを失い、完全に呆然としている
    Google Drive が私のバックアップであるはずだったのに、サポートチームと話すと、ファイルは復元できないと言われた
    リモートクライアントの強制アップデートが、ファイルが保存されていたクライアントのファイルシステムを破損させたようだ
    ソフトウェアは、クライアントマシン上のファイルがただ消えてしまうような形で書かれるべきではない
    これは受け入れられない

    • バックアップの核心は、データをどこかにコピーとして保管することだ
      唯一のコピーが Google Drive にあるなら、バックアップはまったくない状態だ
    • Google Drive はバックアップではない
      バックアップは少なくともオフラインであるべきで、「リアルタイム」データのスナップショットや複製であり、同じ場所ではない外部にもあるべきだ
      3-2-1 バックアップを調べるといい
      Google Drive はリアルタイムストレージなのでファイルが消え、防ぐ方法もなかったのだ
      繰り返すが、それはバックアップではなく、他人のコンピュータにある自分のファイルにすぎない
      バックアップで最も重要なのは、定期的に復元をテストすることだ
      私のルールは「成功した復元なし = バックアップなし」だ
      当たり前に見えるが、顧客のところで何度も起きており、いつも「バックアップ正常」のメールは来るのに、データを確認すると半年間何も記録されていなかったことがあった
  • あり得ない
    今日、母から電話があり、Google Drive のファイルがどこへ行ったのか1時間一緒に探した
    なぜこんなことが起きたのかまったく突き止められなかったが、この問題が原因だと確信するようになった

    • 親のものを GDrive に統合せず、既存の提供者にそのまま置いておくことにした判断に、二重に感謝している
  • ひどい
    フォーラムの投稿から苦痛と不確実さが伝わってくる
    最近では、複数のユーザープロファイルを使う Pixel ユーザーもファイルへのアクセス権を失った
    その場合、実際のデータは消えておらず、その後のアップデートで問題は修正された
    [0]https://support.google.com/pixelphone/thread/239104039/can-n...

  • Google Drive を S3 にバックアップするときは rclone を使っている
    似たようなことをしていないならおすすめする
    rclone は Google Docs も ODF 形式でエクスポートできる

    • ODF 変換は Google 側で行われる点に注意すべきだ
      つまりクラウド文書が恥ずかしいほど小さいあるサイズを超えると、たとえば動画がいくつか入ったインターンの年末発表用 Slides デッキのような場合、単にサイズエラーになり、rclone に直せることは何もない
      結局、警告をよく見る必要がある
    • veracrypt で暗号化したフラッシュドライブにも同期を走らせている
      ローカルストレージは個人データのバックアップ戦略の核心だと思う
    • 毎日 cron のようなもので走らせているのか気になる
      Google から自分の写真をどうバックアップするか検討中だ
  • クラウドサービスに過度に依存するのは致命的なミス
    こうした技術も日常的な機器と同じくらいエラーが起き得ることを、つい忘れがち
    機密性の高いファイルはクラウドに保存すべきではない

    • おそらく唯一のコピーとして置いておくな、という意味だと思う
      それは当然のこと
      しかし日常的な機器は、専門のストレージエンジニアが管理する冗長ストレージより明らかに信頼性が低い