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_nameNone): 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 秒大快照适当再放大避免任务跑到一半被超时判死。排障时按下面这张表走基本能覆盖大部分翻车现场现象先查哪里备份任务失败仓库连通性endpoint、凭证、网络参考专项用例 test_backup_connectivity_failed.groovy再看 FE 日志 fe.log恢复时找不到快照backup_timestamp与仓库内记录不一致用SHOW SNAPSHOT IN repo_backup;重新对时间恢复结果和预期对不上确认选中的快照是 FULL 还是 INCREMENTAL必要时改用表名 AS 新表名落到新表对比任务中途卡住或被取消SHOW BACKUP;/SHOW RESTORE;查看状态对照 test_backup_cancelled.groovy 的取消场景备份方案的价值不在于攒了多少快照而在于真出事时能不能一步回到某个确定的点。三段 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考