Microsoft 365中的SharePoint和OneDrive数据恢复能力
在 Microsoft 365 中，OneDrive 基于 SharePoint 文件平台构建。 在本文中，仅使用 SharePoint 来引用这两种产品。 本文也适用于在 SharePoint 中存储数据的任何其他产品，例如云附件、Teams 中共享的文件、Teams 会议录制和脚本、循环组件和白板。
SharePoint 的核心内容存储有两个主要资产：
- Blob 存储：上传到 SharePoint 的用户内容存储在 Azure 存储中。 SharePoint 基于 Azure 存储构建了自定义复原计划，以确保用户内容和真正主动/主动的系统几乎实时重复。
- 元数据：有关每个文件的元数据存储在 Azure SQL 数据库中。 Azure SQL 提供了 SharePoint 使用的完整业务连续性案例，本文稍后将介绍详细信息。
后续部分将介绍用于确保数据复原能力的完整控件集。
Blob 存储复原能力
SharePoint 具有用于在 Azure 存储中存储客户数据的自定义解决方案。 每个文件同时写入主数据中心区域和辅助数据中心区域。 如果写入任一 Azure 区域失败，则文件保存失败。 将内容写入 Azure 存储后，校验和与元数据一起单独存储，并用于确保在将来所有读取过程中提交的写入与原始文件相同。 在所有工作流中都使用相同的技术，以防止任何应发生的损坏的传播。 在每个区域中， Azure 本地冗余存储 (LRS) 提供高级别的可靠性。
SharePoint 使用 Append-Only 存储，这意味着 Microsoft 只能添加新的 Blob，在永久删除旧 Blob 之前无法更改旧 Blob。 此过程可确保文件在初始保存后无法更改或损坏，从而防范试图破坏旧版本的攻击者。 由于版本完整性保护内置于 SharePoint 的体系结构中，因此可以检索以前版本的文件内容，具体取决于单个管理员设置。
任一数据中心的 SharePoint 环境都可以访问两个 Azure 区域中的存储容器。 出于性能原因，始终首选同一本地数据中心中的存储容器，但是，在所需阈值内看不到结果的读取请求具有从远程数据中心请求的相同内容，以确保数据始终可用。
元数据复原能力
SharePoint 元数据对于访问用户内容也至关重要，因为它存储 Azure 存储中存储的内容的位置和访问密钥。 这些数据库存储在具有广泛 业务连续性计划的 Azure SQL 中。
SharePoint 使用 Azure SQL 提供的复制模型，并构建了一种专有的自动化技术，以确定需要故障转移，并在必要时启动操作。 因此，从 Azure SQL 的角度来看，它属于“手动数据库故障转移”类别。 此处提供了 Azure SQL 数据库可恢复性的最新指标。
SharePoint 使用 Azure SQL 的备份系统启用 时间点还原 (PITR) 长达 14 天。
自动故障转移
SharePoint 使用自定义生成的自动故障转移，以在发生特定于位置的事件时将对客户体验的影响降到最低。 监视驱动的自动化检测超出特定阈值的单组件或多组件故障会导致将所有用户的活动自动重定向到有问题的环境，并重定向到暖辅助数据库。 故障转移会导致元数据和计算存储完全由新数据中心提供。 由于 Blob 存储始终以完全主动/主动方式运行，因此故障转移无需更改。 计算层首选最近的 Blob 容器，但随时使用本地和远程 Blob 存储位置来确保可用性。
SharePoint 使用 Azure Front Door 服务在 Microsoft 网络内部提供路由。 此配置允许独立于 DNS 的故障转移重定向，并减少本地计算机缓存的影响。 大多数故障转移操作对最终用户都是透明的。 如果发生故障转移，客户无需进行任何更改即可保持对服务的访问权限。
版本控制与文件还原
对于新创建的文档库，SharePoint 在每个文件上默认为 500 个版本，并且可以根据需要配置为保留更多版本。 UI 不允许设置小于 100 个版本的值，但可以将系统设置为使用公共 API 存储更少的版本。 出于可靠性考虑，不建议使用任何小于 100 的值，并且可能会导致用户活动导致意外数据丢失。
有关版本控制的详细信息，请参阅 SharePoint 中的版本控制。
文件还原是能够将 SharePoint 中任何文档库的“时间”返回到过去 30 天内的任何一秒。 此过程可用于从勒索软件、批量删除、损坏或任何其他事件中恢复。 此功能使用文件版本，因此减少默认版本会降低此还原的有效性。
文件还原功能记录了 OneDrive 和 SharePoint。
删除、备份和时间点还原
从 SharePoint 中删除的用户内容将经历以下删除流程。
已删除的项目会在回收站中保留一段时间。 对于 SharePoint，保留时间为 93 天。 从原始位置删除项时，它将开始。 从网站回收站中删除项目时，该项目会进入 网站集回收站。 它将保留 93 天的剩余时间，然后永久删除。 有关如何使用回收站的详细信息，请参阅以下链接：
此过程是默认删除流，不考虑保留策略或标签。 有关详细信息，请参阅 了解 SharePoint 和 OneDrive 的保留期。
93 天回收管道完成后，将针对元数据和 Blob 存储单独进行删除。 元数据会立即从数据库中删除，这会使内容不可读，除非从备份中还原元数据。 SharePoint 维护 14 天的元数据备份。 根据此发布时 的文档 ，这些备份几乎实时地在本地进行，然后推送到冗余 Azure 存储容器中的存储，计划为 5-10 分钟。
此外，客户还可以选择使用 Microsoft 365 备份 进行数据恢复。 Microsoft 365 备份提供更长的保护时间，并提供独特的快速恢复，从常见业务连续性和灾难恢复 (BCDR) 方案（如勒索软件或意外/恶意员工内容覆盖/删除）。 其他 BCDR 方案保护也直接内置于服务中，提供增强的数据保护级别。
删除 Blob 存储内容时，SharePoint 会利用 Azure Blob 存储的软删除功能来防止意外或恶意删除。 使用此功能，在永久删除内容之前，总共有 14 天的时间可以还原内容。 此外，由于 Blob 是不可变的，因此 Microsoft 始终可以在 14 天内还原文件的状态。
注意
虽然 Microsoft 应用程序会将内容发送到回收站进行标准过程，但 SharePoint 提供了允许跳过回收站并强制立即删除的 API。 查看应用程序，确保仅在必要时出于合规性原因执行此操作。
完整性检查
SharePoint 使用各种方法来确保 Blob 和元数据在数据生命周期的所有阶段的完整性：
- 存储在元数据中的文件哈希：整个文件的哈希与文件元数据一起存储，以确保在所有操作期间保持文档级数据完整性
- 存储在元数据中的 Blob 哈希：每个 Blob 项存储加密内容的哈希，以防止基础 Azure 存储中损坏。
- 数据完整性作业：每 14 天，每个站点都会通过列出数据库中的项并将其与 Azure 存储中列出的 Blob 进行匹配来扫描完整性。 作业报告任何 blob 引用缺少的 storage-blob，并可以根据需要通过 Azure 存储软删除 功能检索这些 Blob。