本文介绍了冷数据归档备份与恢复的技术原理、费用和设置方法。
数据是企业的核心资产。随着业务发展，企业数据呈现出规模化、爆炸式的增长，业务应用要求实时、在线的快速处理。对于数据库运维人员来说，保护企业核心数据的任务越来越具有挑战性，例如数据误删除、相关系统漏洞和勒索病毒、硬件故障，甚至自然灾害都可能造成数据的丢失。因此，备份和恢复是数据库非常重要的功能。
PolarDB-X对InnoDB数据支持数据备份和日志备份，在备份方式上支持了自动备份和手动备份，恢复方式上支持按时间点恢复和按备份集恢复等恢复策略。而归档到OSS的冷数据和InnoDB热数据，都是用户的实例数据，所以无论数据以什么形式存在，整个数据库实例都应该被视为一个整体来做备份恢复方案，为此我们对归档OSS的冷数据设计了一套完整的备份与恢复方案。
技术原理
针对于包含冷数据的实例，PolarDB-X同样提供不同粒度的数据恢复能力，包括实例级的一致性备份恢复能力、表级的表回收站能力、SQL级的SQL闪回能力等。
冷数据的Flashback Query
每个存储引擎指定为OSS的表分为元数据部分和数据文件部分。其中元数据存储在PolarDB-X的GMS元数据节点中，数据文件存储在OSS中，存储于OSS的数据文件格式为开源ORC格式。每一个OSS数据文件在对应的GMS元数据记录中都会包含两个时间戳字段commit_ts与remove_ts，用于版本控制，与MVCC多版本含义一致。
Flashback Query指的是用户可以针对SQL中的每张表指定一个时间点，查询相应时间点数据的Snapshot。
如上图所示，查询的当前时间now，对应的 read_ts > (F1.remove_ts or F2.remove_ts)，所以F1、F2数据不可见，而对应的F3文件，只有commit_ts没有remove_ts 且 read_ts > F3.commit_ts，所以F3数据可见。基于这个能力，我们提供了类似以下的SQL语法AS OF TIMESTAMP '指定时间'，指定时间做快照查询。
SELECT XX FROM oss_orders where userId = 100
AS OF TIMESTAMP '2022-07-05 11:11:11'除此之外我们还提供了Alter FileStorage OSS As Of Timestamp '恢复指定时间' 指令，该指令可以把冷数据文件按时间戳裁剪至所需要的时间点。
备份集备份与恢复
实例级备份恢复将DN InnoDB存储引擎的数据和OSS的冷数据视为一个整体，进行统一的恢复，需要支持指定的恢复时间点将原实例恢复到一个目标实例中。考虑到OSS冷数据的存储规模会比较大，采用和在线库一样高频的备份恢复策略，会带来比较大的备份存储成本，因此在实例级备份恢复任务的设计上，我们把InnoDB和OSS拆分成了相对独立的备份恢复逻辑。这样既可以一次性备份组合，也可以两者分离各自备份，提供了比较好的灵活性，但两者的备份恢复都需要一些设计约定：
支持定时或者手工触发全量备份的接口，允许实例级备份流程进行全局触发。其中InnoDB的备份恢复流程，在设计上也是把全量数据和增量数据拆分成了两个相对独立的逻辑，具体可参见PolarDB-X 是如何拯救误删数据的你：备份恢复。
支持任意时间点的恢复接口，在实例级恢复流程中会先调用在线数据InnoDB的时间点恢复机制，先确保对应的GMS、DN正常恢复，之后基于GMS的元数据信息，进一步恢复OSS上存储的冷数据。
在这个备份恢复的设计前提下，基于OSS的备份恢复流程如下：
OSS数据备份流程：
固定周期全量备份OSS数据文件。
管控需要先对CN发起
Alter FileStorage OSS Backup指令，将GMS中维护的OSS数据文件元数据（主要包括数据文件名及对应的时间戳版本信息）持久化到OSS，文件名为files_meta.txt。管控读取OSS中的files_meta.txt文件获取所有文件元数据。
管控将数据文件逐个拷贝到备份OSS Bucket进行备份。
OSS Schema元数据存储在GMS中，因此元数据的备份逻辑可以遵循MySQL基于Binlog的备份恢复流程。
内核固定周期Purge过期的老版本数据（Alter FileStorage OSS Purge Before Timestamp），保证每次备份数据集大小不会一直增大（需要保证Purge周期 > 备份周期）。
OSS数据恢复流程：
依赖InnoDB在线数据备份恢复，恢复出一个新的PolarDB-X实例，将GMS + DN找到最近全量备份+binlog增量恢复到指定时间点，此时对应时间点的OSS元数据会随着GMS恢复到指定时间点。
选择OSS数据备份集：判断历史周期备份集中是否存在距离恢复时间最近且备份时间大于恢复时间的备份集，如果存在则选择；如果不存在满足条件的历史备份集，说明恢复时间距离当前时间较近，直接选择当前原实例OSS下的全部数据文件，并通过
Alter FileStorage OSS Backup指令将GMS中维护的元数据文件推送至OSS。恢复任务将以上步骤中选取的OSS数据备份集拷贝一份到新实例，并更新新实例对应的OSS Bucket连接方式。
新实例上CN上执行
Alter FileStorage OSS As Of Timestamp '恢复指定时间'，将OSS数据文件按时间戳裁剪至所需要的时间点。
冷数据元数据维护的最小粒度是文件级，无法像热数据那样按照行去维护，所以两者之间会有一定的差异：
类型 | InnoDB在线热数据 | OSS历史冷数据 |
备份数据 | 全量+binlog增量 | 元数据复用InnoDB备份能力 + 数据文件全量拷贝 |
恢复数据 | 全量+增量Apply | 元数据复用InnoDB恢复能力 + 数据文件按时间戳裁剪 |
备份周期 | 天级别或周级别 | 周或者月级别 |
如上图所示，InnoDB和OSS备份恢复的一个显著区别是：InnoDB会找到最近小于恢复时间点的全量备份集，再应用增量来恢复到指定时间点；而OSS则是找到最近大于恢复时间点的备份集，利用数据集内置增量数据，再应用裁剪机制来恢复到指定的时间点。
费用
OSS数据备份暂时无需单独计费，当前可免费使用。
备份策略配置
在页面左上角选择目标实例所在地域。
在实例列表页面，单击PolarDB-X 2.0页签。找到目标实例，单击实例ID。
在左侧导航栏中，单击。
在归档数据详情页的数据归档备份区域，单击设置。
在数据归档备份设置对话框中，设置如下参数：
数据归档备份：开关默认为打开，不可关闭。
备份执行间隔：设置间隔多少天进行一次备份，取值范围为1～59天。
备份保留策略：可选择备份数据在指定时间内保留或永久保留。
备份保留时间：选择备份的保留时间，范围为30～730天。
单击确定。