处理 Microsoft 365 中的数据损坏

  • 项目

运行大规模云服务的一个具有挑战性的方面是如何处理数据损坏，因为数据量很大，系统独立。 数据损坏的原因可能是：

  • 应用程序或基础结构 bug，损坏部分或全部应用程序状态
  • 导致数据丢失或无法读取数据的硬件问题
  • 人为操作错误
  • 恶意黑客和不满的员工
  • 外部服务中导致某些数据丢失的事件

由于数据完整性的复原能力更高意味着数据损坏事件更少，因此 Microsoft 已内置 Microsoft 365 保护机制，以防止损坏的发生，以及使我们能够在发生损坏时恢复数据的系统和流程。 检查和流程存在于工程发布过程的各个阶段，以提高对数据损坏的复原能力，包括：

  • 系统设计
  • 代码组织和结构
  • 代码评审
  • 单元测试、集成测试和系统测试
  • 行程线测试/门

在 Microsoft 365 生产环境中，数据中心之间的对等复制可确保始终存在任何数据的多个实时副本。 标准映像和脚本用于恢复丢失的服务器，复制的数据用于还原客户数据。 在 Exchange Online 中，每个邮箱都托管在数据库可用性组中， (DAG) ，并复制到同一区域中的地理上独立的数据中心。 每个邮箱数据库有四个副本分布在 DAG 内的数据中心：一个活动副本、两个最新副本和一个在发生灾难性逻辑损坏的罕见事件中使用的 7 天滞后副本。 对于 SharePoint 和 OneDrive， 文件会同时写入 主要和次要数据中心区域。 多种类型的 校验和 存储在元数据中，而不是相应文件，用于确保数据生命周期的所有阶段的数据完整性。

由于内置数据复原检查和过程，Microsoft 仅维护 Microsoft 365 信息系统文档的备份， (包括安全相关文档) ，使用 SharePoint Online 中的内置复制和我们的内部代码存储库工具 Source Depot。 系统文档存储在 SharePoint Online 中，源 Depot 包含系统和应用程序映像。 SharePoint Online 和 Source Depot 都使用版本控制，并且几乎实时复制。

资源