备份和还原
无论是大型还是小型组织，都可能会发生事故和事件。 因此，针对系统中断时如何将其还原这一问题，始终需要制定一个计划。 在 SQL Server 中，如果要将数据库还原到某个时间点，只有在完全恢复模式下运行时才能执行此操作。 在大容量日志恢复模式下，极有可能需要将数据库恢复到事务日志备份的末尾。
Azure SQL 的好处之一在于，Azure 可以替你处理所有这一切。 由于 Azure SQL 管理备份并在完整恢复模式下运行，因此它可以将数据库还原到任何时间点。 你甚至可在配置的保留策略内还原已删除的数据库。 如果逻辑服务器或实例上已启用 TDE，Microsoft 还将自动加密你的备份。
默认情况下，每周执行一次完整数据库备份。 每 5-10 分钟执行一次日志备份，每 12-24 小时执行一次差异备份。 默认情况下，这些备份文件存储在读取访问权限异地冗余存储 (RA-GRS) 上的 Azure 存储中。 但是，也可以选择在区域冗余存储 (ZRS) 或本地冗余存储 (LRS) 中进行备份。 Azure SQL 工程团队将持续不断地自动测试逻辑服务器和弹性数据库池中放置的数据库的自动备份的还原。 若要迁移到 Azure SQL 托管实例，可执行自动初始备份，以备份使用本机 RESTORE 命令或 Azure 数据库迁移服务还原的数据库的校验和。 并且在 Azure SQL 托管实例中，可以选择采用本机仅限复制的备份并将其存储到 Azure Blob 存储。
为 Azure SQL 托管实例和 Azure SQL 数据库创建备份策略
Azure SQL 可以处理冗杂的工作，但还是务必了解一下存储和处理备份是如何进行的，并了解保留和还原的选项。 说到底，你仍需负责时间点还原、长期保留和异地还原的总体策略。
时间点还原 (PITR)
在 Azure SQL 数据库和 Azure SQL 托管实例中，你可以执行自助式还原。 选择想要还原的确切时间点，然后使用 Azure 门户、PowerShell/Azure CLI 或 REST API 来启动该过程。 时间点还原 (PITR) 将在同一逻辑服务器中新建数据库（使用不同的名称）。 如果需要将原始数据库替换为 PITR 数据库，则必须重命名原始数据库和新数据库，才能恢复到正常工作状态。 不需要更新连接字符串。
PITR 的保留期介于 1 至 35 天之间。 默认情况下，保留期（适用于所有服务层级和部署选项）为 7 天。 在大多数部署选项和服务层级中，可以将策略配置为 1 至 35 天，具体取决于方案的要求。 例如，对于测试数据库，可能只需要 1 天，但对于任务关键数据库，则可以选择最大值 35 天。
长期保留 (LTR)
如果 35 天不足以满足组织的需求或合规性要求，可以选择长期保留 (LTR)。 该选项让你可以自动创建完整的数据库备份，并存储在 RA-GRS、ZRS 或 LRS 存储中，最长可存储 10 年。 对于 Azure SQL 数据库，LTR 已正式发布。 对于 Azure SQL 托管实例，LTR 现提供有限的公共预览版。
异地还原
如果出现灾难性事件，贵组织需要能够进行恢复。 备份会自动存储在 RA-GRS（除非选择 ZRS 或 LRS），这意味着备份将存储在配对区域中。 因此，如果整个区域关闭，且数据库或托管实例均位于该区域，你将受到保护。 你可以根据最新的异地复制备份异地恢复到其他任何区域。 相较于主要副本，该备份可能略有滞后，因为将 Azure blob 复制到其他区域需要时间。 可以使用 Azure 门户、PowerShell/Azure CLI 或 REST API 轻松执行异地还原。