【Azure Data Platform】SQL DW 备份策略

本文属于【Azure Data Platform】系列。
接上文：【Azure Data Platform】数据平台的选择
本文谈一下SQL DW的备份策略

前言

数据库的备份重要性不用多说，但是随着各种产品特别是云数据库的出现，其备份形式就有了比较多的种类。我本人并没有用过本地版的数据仓库。只是在工作过程中，使用了Azure SQL DB（SQL Server的PaaS版本）之后，又切换到SQL DW，在项目的角度来说，其备份策略也影响了项目的验收。

SQL DW实际上并没有“备份”这一说法，它只有快照（snapshot）， 当前的SQL DW，会保留7天或者最高42次快照。也就是说你最多能够还原到7天前。跟SQL DB不一样，SQL DB默认就能够保留7天备份，可以还原到7天内任何时间点（精确到秒）的状态，最高可以保持10年的备份（但是很贵）。

而SQL DW，只会做快照，默认是4小时自动做一次。也就是说在不干预的情况下可以还原到4小时前的那个时刻的状态，时间是不连续的。之所以存在这种差异，主要原因是SQL DW（官方名字为Dedicated SQL Pool）是分布式系统，它由Azure 存储中的多个文件组成。没有一个集中的设备来存储数据文件，很难实现与SQL DB那样的常规备份功能。同时快照是从存储在数据仓库中的数据中获取增量变更。

数据仓库还原是从现有或删除的数据仓库的快照还原点创建的新数据仓库。SQL DW在创建时就默认启动了自动还原点，也就是说会自动做快照。不过必须是活动或者没有被暂停的。

RPO和RTO

讲到备份，有两个词就不得不提，也就是RPO和RTO
RPO：Recovery Point Objective，恢复点目标， 简单来说，描述了在中断期间丢失的数据量超过业务连续性计划的最大允许阈值或"容限"之前可能经过的时间间隔。它回答了这个问题 - "考虑到该间隔期间丢失的数据量，业务流程的恢复在什么时间点可以容忍地进行？我的理解就是你能还原到最早什么时候的备份。
RTO：Recovery Time Objective ，恢复时间目标，是一个持续时间和服务级别，在该持续时间和服务级别内，在该持续时间和服务级别内，必须在该持续时间内恢复业务流程，以避免与连续性中断相关的不可接受的后果。换句话说，RTO 是以下问题的答案："在收到业务流程中断通知后，恢复需要多长时间？我的理解是可停机时间及恢复所需时间的总和。

SQL DW，支持8小时的RPO。要查看当前SQL DW的快照情况可以使用下面SQL ， 可以看到它是8小时间隔：

select   *
from     sys.pdw_loader_backup_runs
order by run_id desc

为了实现RPO， SQL DW默认就有自动的快照计划， 这个计划不能被禁用，但是还支持手动快照。通常在重大变更之前建议执行一次快照。下图就是手动执行快照的示意图：

在任何时间点，只要这些还原点未达到 7 天保留期，则保证专用 SQL 池最多能够存储 42 个用户定义的还原点和 42 个自动还原点。如下图可以看到如果我现在要还原，则最多能还原到7天前。

如果想保留超过7天的快照，需要恢复到实例上，直到总共有 42 个还原点（包括用户定义的还原点和自动还原点）。

注意如果SQL DW处于暂停状态，则不会执行快照。

异地备份

SQL DW每天创建一次到配对数据中心的异地备份。异地还原的 RPO 为 24 小时。可以将异地备份还原到支持SQL DW的任何其他区域中的服务器。异地备份可确保在无法访问主要区域中的还原点时可以还原数据仓库。

恢复快照

在Azure Portal可以直接选择还原点进行还原。但是不管是SQL DW还是SQL DB， 都不可以进行覆盖式的还原，需要额外还原到新的库，再进行后续操作。默认会为你生成一个时间标识作为数据库的后缀名：

小结

由于无法实现像SQL DB的时间点还原，那么SQL DW的备份策略可以考虑：

1. 在重大变更前进行手动快照并还原到实例上，然后暂停它，这样只需要付出存储费用。
2. 使用脚本定期或者按需导出数据及结构到ADLS上进行存储。