StarRocks 备份与恢复实战：基于 MinIO 的 S3 存储方案
为什么需要备份
StarRocks 作为一款 OLAP 分析型数据库，承载着大量业务报表和数据分析结果。虽然数据通常有上游数据源可以重跑，但以下场景备份依然必不可少：
- 误操作恢复：DDL 误删表、数据误更新等
- 版本升级回滚：大版本升级前做快照，出问题可快速回溯
- 跨集群迁移：从测试环境到生产环境的数据同步
- 灾备合规：满足数据安全审计要求
StarRocks 从 2.3 版本开始支持基于 Broker 的备份恢复能力，到 2.5 版本功能趋于完善。
备份恢复原理
StarRocks 的备份恢复依赖Broker 组件作为中间桥梁，将数据以快照（Snapshot）形式导出到外部存储。架构如下：
FE (元数据调度) → Broker (数据传输) → S3/HDFS 存储 ↑ BE (数据文件) ───┘支持的存储后端：
- S3 兼容的对象存储（MinIO、AWS S3、阿里云 OSS 等）
- HDFS
版本差异：
| 版本 | 支持范围 | 限制 |
|---|---|---|
| 2.3 | 表级备份，仅支持 Duplicate/Aggregate/Unique 模型 | 不支持主键表、不支持物化视图、不支持整库备份 |
| 2.5+ | 支持主键表、支持整库备份恢复 | — |
| 3.3+ | 功能趋于稳定 | 主键表部分场景仍有注意事项 |
注意：备份恢复目前不支持主键模型（Primary Key）的表，这是需要关注的限制。
环境准备
本文以 MinIO 作为 S3 兼容存储后端。MinIO 是一个开源的对象存储服务，部署简单，兼容 S3 协议。
启动 MinIO（Docker 方式）
dockerrun-d\--nameminio\-p9000:9000-p9001:9001\-eMINIO_ROOT_USER=admin\-eMINIO_ROOT_PASSWORD=admin123456\-v/data/minio:/data\minio/minio server /data --console-address":9001"访问http://your_ip:9001进入 MinIO 控制台，创建一个 Bucket 命名为srbackup。
确保 Broker 服务正常运行
# 检查 Broker 状态mysql-h127.0.0.1-P9030-uroot-e"SHOW PROC '/brokers';"如果 Broker 未启动：
/data/StarRocks-3.1.7/apache_hdfs_broker/bin/start_broker.sh--daemon创建备份仓库
备份仓库（Repository）是 StarRocks 中备份数据的存储目标，创建后可通过SHOW REPOSITORIES查看。
CREATEREPOSITORY`srbackup`WITHBROKER`broker1`ONLOCATION"s3a://srbackup"PROPERTIES("fs.s3a.access.key"="your_access_key","fs.s3a.secret.key"="your_secret_key","fs.s3a.endpoint"="http://192.168.1.100:9000","fs.s3a.connection.ssl.enabled"="false");参数说明：
| 参数 | 说明 |
|---|---|
REPOSITORY | 仓库名称，后续备份恢复时引用 |
BROKER | Broker 名称，需与SHOW PROC '/brokers'中一致 |
LOCATION | S3 Bucket 路径，格式s3a://bucket_name |
fs.s3a.access.key | S3 Access Key |
fs.s3a.secret.key | S3 Secret Key |
fs.s3a.endpoint | S3 服务端点地址 |
fs.s3a.connection.ssl.enabled | 是否启用 SSL（MinIO 本地部署通常设为 false） |
查看已创建的仓库：
SHOWREPOSITORIES;执行备份
表级备份
BACKUPSNAPSHOTa003.backup_1TOsrbackupON(tab1,tab2,tab3)PROPERTIES("type"="full");说明：
SNAPSHOT后跟快照名称，建议包含库名和版本号，如db_name.backup_20260701ON (...)指定要备份的表名列表type = "full"表示全量备份（目前仅支持全量模式）
查看备份进度
-- 查看备份任务状态SHOWBACKUPFROMa003;-- 查看仓库中的快照列表SHOWSNAPSHOTONsrbackup;SHOW BACKUP输出关键字段：
Status：CANCELLED/DOING/FINISHEDTaskMsg：错误时会显示详细错误信息CreateTime/FinishTime：可据此计算备份耗时
执行恢复
在目标集群创建相同的仓库
恢复时需要指定backup_timestamp，可从SHOW SNAPSHOT ON srbackup的Snapshot名称中获取。
-- 1. 先在目标集群创建指向同一 S3 的仓库CREATEREPOSITORY`srbackup`WITHBROKER`broker1`ONLOCATION"s3a://srbackup"PROPERTIES("fs.s3a.access.key"="your_access_key","fs.s3a.secret.key"="your_secret_key","fs.s3a.endpoint"="http://192.168.1.100:9000","fs.s3a.connection.ssl.enabled"="false");-- 2. 查看可用快照，获取 backup_timestampSHOWSNAPSHOTONsrbackup;-- 3. 执行恢复RESTORESNAPSHOTa003.backup_1FROMsrbackupON(tab1,tab2,tab3)PROPERTIES("backup_timestamp"="2022-10-28-11-25-16-351");-- 4. 查看恢复进度SHOWRESTORE;backup_timestamp获取方式：
执行SHOW SNAPSHOT ON srbackup后，输出的快照名称格式为backup_name.backup_timestamp，取.后面的时间戳部分即可。
删除备份快照
-- 删除指定快照DROPSNAPSHOTa003.backup_1ONsrbackup;常见问题与注意事项
1. 主键表不支持备份恢复
这是最需要注意的限制。2.3 版本明确不支持，2.5+ 版本有所改善但部分场景仍有问题。建议在生产使用前在测试环境充分验证。
2. 备份期间的影响
备份操作会占用 FE 和 BE 的计算资源及网络带宽，建议在业务低峰期执行，尤其是大表全量备份。
3. 恢复前需确保表不存在
RESTORE 操作要求目标库中不存在同名表，否则恢复会失败。如需覆盖，先手动 DROP 目标表。
4. 跨版本兼容性
备份文件与 StarRocks 版本相关，跨主版本恢复（如从 2.3 恢复到 3.1）可能存在兼容性问题。建议在同版本或相邻版本间做备份恢复。
5. 备份存储容量规划
全量备份会复制所有数据文件到 S3，需根据数据量预估存储空间。建议在 MinIO Bucket 上配置生命周期策略，自动清理过期快照。
自动化备份脚本
以下是一个简单的 Shell 备份脚本，配合 crontab 实现定期备份：
#!/bin/bash# starrocks_backup.shFE_HOST="127.0.0.1"FE_PORT="9030"USER="root"PASSWORD="your_password"DB_NAME="a003"BACKUP_NAME="${DB_NAME}.backup_$(date+%Y%m%d)"mysql-h${FE_HOST}-P${FE_PORT}-u${USER}-p${PASSWORD}-e" BACKUP SNAPSHOT${BACKUP_NAME}TO srbackup ON (tab1, tab2, tab3) PROPERTIES ('type' = 'full'); "echo"Backup${BACKUP_NAME}submitted at$(date)"# crontab：每周日凌晨 3 点执行03* *0/path/to/starrocks_backup.sh>>/var/log/sr_backup.log2>&1总结
StarRocks 的备份恢复功能整体比较简单，核心流程就是：建仓库 → 打快照 → 查看状态。关键注意点：
- 提前规划 S3 存储（MinIO 轻量够用）
- 注意主键表的兼容性限制
- 跨版本恢复前做好测试
- 配合 crontab 实现自动化，降低人工操作风险
备份是运维的最后一道防线，有了它你才敢放心折腾。
)
 agent和组件)