3步搭好 ThingsBoard 多租户备份附恢复演练脚本【免费下载链接】thingsboardOpen-source IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard上个季度一次生产环境升级后某租户的历史时序数据全部丢失——排查发现上一版备份只是把 data 目录整包 tar 了一下表结构变更后根本导不回去几个 TB 的备份等于没做。这是跳过 ThingsBoard 多租户备份最典型的代价备份文件在但真出事时不可用。下面给你一套备份 → 调度 → 校验的闭环30 分钟能搭完并且每个环节都有可验证的结果。动手之前的三件事10分钟确认环境与前置条件确认项确认方式合格标准数据库类型与权限查thingsboard库的连接配置确认账号PostgreSQL 或 TimescaleDB备份账号有pg_dump权限租户表命名规则用information_schema列一遍ts_%、attributes、device等表时序数据在ts_kv族按年分区表 ts_kv_latest最新值表attributes、device、customer等实体表都带tenant_id列可按租户行级过滤调度入口crontab -l/systemctl list-timerscrontab 或 systemd timer 任选其一不必依赖平台内置调度核心配置在 application/src/main/resources/thingsboard.yml数据库连接段里的账号要和 Docker 编排侧保持一致可对照 docker/docker-compose.yml 里的 postgres 服务。租户数据的存取逻辑都在 DAO 层dao/src/main/java/org/thingsboard/server/dao/tenant/ 下的TenantDao可以帮你核对哪些表属于租户、哪些要按tenant_id过滤。你要保护的就是这类控制台里的数据三步搭好备份 → 调度 → 校验闭环第1步按租户行级导出12行脚本这段脚本解决只导这一个租户的数据租户私有表整表 dump共享表按tenant_id行级导出避免把别的租户数据卷进来。#!/usr/bin/env bash set -euo pipefail TID$1; DBthingsboard OUTbackups/${TID}_$(date %Y%m%d_%H%M%S); mkdir -p $OUT # 租户私有表整表导出 docker exec tb_postgres pg_dump -U postgres -d $DB \ -t tenant -t customer -t device -t rule_chain \ --data-only -f /tmp/tb_tenant.sql docker cp tb_postgres:/tmp/tb_tenant.sql $OUT/ # 共享表按 tenant_id 行级导出 docker exec tb_postgres psql -U postgres -d $DB -c \ COPY (SELECT * FROM attributes WHERE tenant_id$TID) TO STDOUT $OUT/attributes.csvts_kv按年分区表数据量最大建议另起循环按年份分区逐张导出并归档到同一目录。执行完你应该看到backups/租户ID_日期目录下有tb_tenant.sql、attributes.csv等文件且非空。第2步crontab 一行搞定每日备份30 2 * * * /opt/tb-backup/backup_all_tenants.sh /var/log/tb-backup.log 21backup_all_tenants.sh的逻辑一句话带过从库里查出所有租户 ID循环调用第 1 步脚本最后find -mtime 30 -delete清掉 30 天前的旧备份。✅ 次日 2:30 后你应该看到/var/log/tb-backup.log末尾新增一行日志且backups下出现当天新目录。第3步10行代码验证备份完整性这段校验解决备份文件在 ≠ 数据全源库行数与导出文件行数直接比对差一行就判失败。SRC$(docker exec tb_postgres psql -U postgres -d $DB -tAc \ SELECT COUNT(*) FROM attributes WHERE tenant_id$TID) F$(wc -l $OUT/attributes.csv) if [ $SRC -eq $((F-1)) ]; then echo OK $TID else echo FAIL $TID /var/log/tb-backup-error.log fi输出OK 租户ID才算这次备份合格FAIL行写进错误日志配合 monitoring/src/main/resources/tb-monitoring.yml 所在的监控模块可以配成告警失败当天就能发现。恢复演练确认备份真的能用没做过恢复演练的备份等于没有备份。演练不用碰生产库一个临时库就够建库 → 导入 → 比行数。TESTtb_restore_drill_$(date %s) Fbackups/${TID}_20250601_023000 docker exec tb_postgres psql -U postgres -c CREATE DATABASE $TEST docker exec -i tb_postgres psql -U postgres -d $TEST \ -c COPY attributes FROM STDIN WITH CSV HEADER $F/attributes.csv docker exec tb_postgres psql -U postgres -d $TEST -tAc \ SELECT COUNT(*) FROM attributes docker exec tb_postgres psql -U postgres -c DROP DATABASE $TEST最后查出的行数应与第 3 步记录的源库行数一致然后删掉临时库。这就是租户在界面上看到的数值来源演练一次比检查十次文件更有说服力建议把每季度对抽样租户做一次恢复演练写进运维 SOP记录演练日期与行数比对结果一次真实事故里能救命的只有演练过的那个备份。踩坑与调优清单高频问题的现象-原因-处理备份窗口超过 4 小时→ts_kv按年分区表太大且pg_dump单线程 → 按年份分区拆任务、多租户用xargs -P 4并行窗口挪到业务低峰。数据盘被备份撑满库直接挂→ 备份目录和库数据在同一卷 → 备份放独立卷参考 docker/docker-compose.volumes.yml 的卷挂载方式再同步到异地 S3保留策略用每日 30 天 每月 12 个月。REST API 拉租户列表 401→ JWT 过期或账号不是系统租户 → 别走 API直接SELECT id FROM tenant查库少一整类鉴权问题。恢复后行数比源库少→ 只 dump 了ts_kv主表漏了按年分区表 → 用information_schema枚举所有ts_kv%表放进导出清单。存储策略和并行化点到为止卷、S3、xargs三件套够用不必上更重的方案。备份能恢复才算合格。先跑通三步闭环再做一次真实恢复演练写进 SOP。想深挖租户数据模型从 dao/src/main/java/org/thingsboard/server/dao/tenant/ 看起。【免费下载链接】thingsboardOpen-source IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考