Apache Doris 数据备份恢复实战：快照上手、自动化脚本与故障自救指南

【免费下载链接】dorisApache Doris is an easy-to-use, high performance and unified analytics database.项目地址: https://gitcode.com/gh_mirrors/dori/doris

一条DROP TABLE可能让几周的数据瞬间消失，一块 BE 盘故障也能让整组表集体失联。真到那一刻，能救你的只有平时留下的备份。Apache Doris 的数据备份与恢复正是为这种时刻准备的：它基于快照（Snapshot）机制，把数据库或指定表的数据以快照形式写到 S3、HDFS 这类远程存储，需要时再用 RESTORE 拉回集群——既可以恢复回原表，也能落到一张新表里慢慢核对。这篇文章按"先跑通、再验证、再自动化"的顺序，把一整套备份恢复流程串起来：三段 SQL 让你完成第一次快照，SHOW 命令闭环验证恢复结果，脚本负责整集群级撤离，最后聊节奏规划与排障。

快照机制：BACKUP 与 RESTORE 怎么配合

Doris 的备份恢复由两条 SQL 完成。BACKUP为一个库（或库下的若干表）生成快照并上传到事先建好的远程仓库（Repository）；快照有两个可调节的维度——type区分 FULL（全量）和 INCREMENTAL（增量），content区分 ALL（完整数据）和 METADATA_ONLY（只备元数据），这组参数在 BackupStmt.java 中定义。换句话说，日常不必每天搬全量数据：周期性全量打底、每天增量跟上，临时还可以只备一次 schema 变更。恢复一侧同样灵活，RESTORE支持原表就位置换，也支持用表名 AS 新表名的形式先恢复到新表做对比，再决定要不要覆盖。

第一步：把远程仓库建起来

仓库是快照的"落脚点"，建库和建仓库的顺序是：先有仓库，再有 BACKUP。以 S3 为例，下面是回归测试框架 Syncer.groovy 里创建 S3 仓库的真实写法：

CREATE REPOSITORY `repo_backup` -- 仓库名，后续 BACKUP/RESTORE 都要引用它 WITH S3 -- 存储类型；HDFS 等场景可用 WITH BROKER ON LOCATION "s3://doris-backup/repo_backup" -- 快照实际存放的路径 PROPERTIES ( "s3.endpoint" = "http://s3.example.com", -- S3 服务端点 "s3.region" = "us-east-1", -- 区域 "s3.access_key" = "your_access_key", -- 访问凭证 "s3.secret_key" = "your_secret_key" );

如果目标是 HDFS，改成WITH broker并补上fs.defaultFS、hadoop.username之类的属性即可，test_backup_restore_hdfs.groovy 里保留着完整的注释示例。仓库建好后用SHOW REPOSITORIES;确认它真的存在、可访问。

第二步：BACKUP 语句怎么写

仓库就绪后，一条 BACKUP 就能启动一次备份任务：

BACKUP SNAPSHOT db_test.snap_20261015 -- 快照名，挂在库下面的 label TO `repo_backup` -- 目标仓库 ON (t_order, t_user) -- 要备份的表；不写 ON 子句则整个库都备 PROPERTIES ( "timeout" = "3600" -- 超时时间（秒），源码强制下限 600 );

有两个容易踩的点：BACKUP 的表清单里不能给表起别名，解析器会直接报错；timeout低于 600 秒也会被拒绝，这两个约束都能在 AbstractBackupStmt.java 里找到。日常例行任务可以加"type" = "INCREMENTAL"只备增量；任务提交后是异步执行的，用SHOW BACKUP;跟踪状态。

第三步：RESTORE 把数据拉回来

出事之后的恢复动作，核心是把"对哪个时间点"说清楚：

RESTORE SNAPSHOT db_test.snap_20261015 FROM `repo_backup` ON ( t_order AS t_order_recovered, -- 恢复到新表做核对；省略 AS 即恢复回原表 t_user ) PROPERTIES ( "backup_timestamp" = "2026-10-15 02:13:00", -- 指定快照的时间戳，必须与仓库中记录一致 "reserve_replica" = "true" -- 恢复后保留副本，省去重新复制的开销 );

其中backup_timestamp是快照的定位键，写错或漏写就找不到对应的数据；它的取值来自仓库里的快照列表，而不是你"以为是"的时间。提交后用SHOW RESTORE;观察进度，test_backup_restore.groovy 演示了完整闭环：BACKUP → 等快照完成 → 清空原表 → RESTORE →SELECT校验行数一致。

恢复后如何验证数据

恢复做完不等于结束，验证要分三层做。第一层看任务本身：SHOW BACKUP;和SHOW RESTORE;都跑到成功状态。第二层看快照：SHOW SNAPSHOT IN repo_backup;会列出仓库中所有快照及其时间戳、状态，用来核对"我恢复的到底是不是那个点"。第三层看业务数据：对关键表跑行数、聚合值这类校验 SQL，和备份前的记录对账。

至于"恢复流程还能怎么玩"，regression-test/suites/backup_restore/ 目录下有近 40 个真实用例，比如恢复到新表（test_backup_restore_alias.groovy）、多表恢复（test_backup_restore_multi_tables.groovy）、分区级恢复等，通读一遍等于拿到一份现成的演练清单。

集群级备份：backup.py 一行命令跑起来

SQL 快照解决的是数据层的备份恢复；而整集群迁移、大版本升级或灾备演练时，还得把 FE 元数据和 BE 数据目录整体搬走。仓库里的 备份脚本 backup.py 就是干这个的，核心逻辑只有几行：

def backup_palo(backup_name=None): if not backup_name: backup_name = datetime.datetime.now().strftime(fmt) # 默认用时间戳命名 backup_fe(backup_name) # 遍历所有 FE 节点（master/follower/observer），多线程并行 backup_be(backup_name) # 遍历所有 BE 节点，多线程并行

单节点的动作可以概括为：FE 先执行jmap把堆转储成heap.bin再停服，然后把 FE 数据目录整体挪进backup/<备份名>/；BE 则是停服后同样把数据目录挪走。所有节点并行完成之后，交由 deploy 脚本的 stop/start 模块把服务重新拉起。用法很简单：

python pytest/deploy/backup.py # 不传参，按当前时间自动生成备份名 python pytest/deploy/backup.py my_backup # 指定备份名，方便归档识别

⚠️ 注意：脚本是"停服 + 移动目录"的硬拷贝方式，执行期间集群短暂不可用，请务必安排在维护窗口或测试环境里跑。

把备份变成长期策略：节奏、调优与排障

节奏上建议按业务可容忍的丢失范围分层：全量备份每周一次、保留四周以上，作为灾难恢复的基线；增量备份每日一次、保留七天，覆盖日常写入；核心大表在高风险动作（大 DDL、发版、数据订正）前单独再做一次专项备份。

调优空间主要在三个真实可控的点上：备份窗口放在业务低峰，让网络和磁盘优先服务在线查询；日常任务用"type" = "INCREMENTAL"只传变化部分，全量控制在每周一次的量级；timeout给足（下限 600 秒，大快照适当再放大），避免任务跑到一半被超时判死。

排障时按下面这张表走，基本能覆盖大部分翻车现场：

备份方案的价值不在于攒了多少快照，而在于真出事时能不能一步回到某个确定的点。三段 SQL 解决单次备份恢复，脚本解决整集群撤离，再配上前面那套验证闭环，数据安全的底线就立住了。想继续深入，建议直接读 regression-test/suites/backup_restore/ 里的完整用例矩阵和 pytest/deploy/ 下的部署脚本，每条流程都能找到对应的可运行实现。

【免费下载链接】dorisApache Doris is an easy-to-use, high performance and unified analytics database.项目地址: https://gitcode.com/gh_mirrors/dori/doris