处理 Microsoft 365 中的数据损坏
运行大规模云服务的一个具有挑战性的方面是如何处理数据损坏，因为数据量很大，系统独立。 数据损坏的原因可能是：
- 应用程序或基础结构 bug，损坏部分或全部应用程序状态
- 导致数据丢失或无法读取数据的硬件问题
- 人为操作错误
- 恶意黑客和内部人员
- 外部服务中导致某些数据丢失的事件
由于提高数据完整性复原能力意味着更少的数据损坏事件，Microsoft已内置Microsoft 365 种保护机制，以防止损坏的发生，以及使我们能够在发生损坏时恢复数据的系统和流程。 检查和流程存在于工程发布过程的各个阶段，以提高对数据损坏的复原能力，包括：
- 系统设计
- 代码组织和结构
- 代码评审
- 单元测试、集成测试和系统测试
- 行程线测试/门
在 Microsoft 365 生产环境中，数据中心之间的对等复制可确保始终存在任何数据的多个实时副本。 标准映像和脚本用于恢复丢失的服务器，复制的数据用于还原客户数据。 在 Exchange Online 中，每个邮箱都托管在 数据库可用性组中， (DAG) ，并复制到同一区域中的地理上独立的数据中心。 每个邮箱数据库有四个副本分布在 DAG 内的数据中心：一个活动副本、两个最新副本和一个在发生灾难性逻辑损坏的罕见事件中使用的 7 天滞后副本。 对于 SharePoint 和 OneDrive， 文件会同时写入 主要和次要数据中心区域。 多种类型的 校验和 存储在元数据中，而不是相应文件，用于确保数据生命周期的所有阶段的数据完整性。
由于内置数据复原检查和流程，Microsoft仅维护Microsoft 365 信息系统文档的备份， (包括安全相关文档) ，使用 SharePoint 中的内置复制和我们的内部代码存储库工具 Source Depot。 系统文档存储在 SharePoint 中，源 Depot 包含系统和应用程序映像。 SharePoint 和 Source Depot 都使用版本控制，并且几乎实时复制。