Google Drive 误置了数月的客户数据

原文 ↗ Hacker News 讨论 ↗

关于 Google Drive 丢失用户数月文件的报告，正在引发人们对依赖大型云服务进行长期数据存储的更广泛担忧。评论者讨论在 Google 服务条款下所有权和权利究竟意味着什么、用户究竟有多少法律救济——尤其是在免费层级——以及数据丢失究竟源于后端故障还是同步客户端 bug。许多人得出的结论是，重要文件绝不应只存在于一个云账户中，建议采用独立备份策略（rclone、NAS、Synology、CubeBackup、多提供商冗余），并把“云”视为更广泛备份计划中的一个组成部分，而不是唯一的事实来源。

事件范围与可靠性担忧

  • 评论者报告称 Drive 文件丢失、文件夹结构回滚，以及已删除文件重新出现；还有人报告 Gmail 消息和 Google Photos 项目在较大日期范围内消失。
  • 有几位表示，他们早就怀疑 Google Docs/Drive 存在静默数据丢失或随机内容删除的问题，而此前支持团队一直不予理会。
  • Google 的官方状态面板显示没有事故；许多人认为一方状态页面并不可信，更像是营销而非诊断。

数据所有权、权利与责任

  • 围绕“不是你的 drive，就不是你的数据”展开了长篇讨论：
    • 有人认为，如果服务提供商可以在没有有效补救的情况下删除数据，那么法律上的所有权并无意义，尤其是在免费层级、责任上限为 $0 的情况下。
    • 也有人反驳说，你仍然保有知识产权，理论上可以起诉索赔，而责任上限并不会抹去所有侵权主张（尽管执行代价高昂）。
  • 对房东、窃贼和云合同的类比说明，真正重要的是实际救济，而不是抽象的所有权。

备份期望与实践

  • 强烈共识：永远不要信任单一云服务提供商；如果云端只有一份副本，那就不是备份。
  • 许多人描述了 3‑2‑1 风格的方案：
    • 用 rclone 将 Drive/OneDrive 镜像到 Dropbox、S3、Backblaze B2、Glacier 或 NAS。
    • 定期导出 Google Takeout，有时通过脚本化流程并借助加密工具流式写入对象存储。
    • 使用专门工具（CubeBackup、Synology ActiveBackup、Duplicati、Restic）备份 Workspace 账户或个人 Google 数据。
  • 有人强调要定期测试恢复，并使用带校验和的文件系统（btrfs/ZFS）来检测 bit-rot 和损坏。

替代方案与自托管

  • 建议包括 Dropbox、Mega、Backblaze B2 和 AWS S3，以及自托管的 Nextcloud/Synology/Immich/Piwigo 再配合异地硬盘。
  • 几位强调“非相关冗余”：多个提供商 + 本地副本，不要把一切都押在一个云上。

对根因的猜测

  • 猜测包括：
    • 一个过时的副本被提升为主副本，导致回滚 6 个月并产生复杂的合并冲突。
    • 桌面同步客户端的 bug 或缺陷，用旧的服务器状态覆盖了本地内容。
    • 后端存储故障返回了错误指针，或“旧文件删除”流程误触发。
  • 线程中没有明确的技术根因被证实。

产品与 UX 方面的挫败感

  • 许多人批评 Google Drive 的文件浏览器和搜索；也有人表示在如此规模上构建 Drive 确实很难，但付费层级仍意味着应当承担照管责任。
  • 与 OneDrive/SharePoint/Teams 以及 Workspace 与个人 Google 账户的对比，凸显了人们对大型厂商协作套件的更广泛不满。