不再手动导库：ThingsBoard 多租户备份与恢复验证三步落地指南

不再手动导库ThingsBoard 多租户备份与恢复验证三步落地指南【免费下载链接】thingsboardOpen-source IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard这是关于 ThingsBoard 多租户备份的实战指南先搞懂数据按租户怎么隔离再用三个脚本搭起凌晨自动跑的备份流水线最后加记录数校验和恢复演练让你在任何一份备份文件面前都知道它能不能真救急。一、多租户备份最容易踩的坑先别写脚本把三个最常见的失败场景摆出来后面每一步设计都在躲它们。坑一手动导出漏表。租户时序数据按 Tenant ID 拆到 ts_kv_ 系列分表里而 attributes、user 这类是共享表。只导自己那张表很容易漏要么备份不完整要么忘加 tenant_id 过滤一次性把别的租户数据也捞了进去。坑二备份损坏无人发现。磁盘写满时 tar 出来的文件只有几 KB但退出码照样是 0。没人盯着看三个月后真要用时才发现打开是个坏包。坑三备份从没恢复过。没做过恢复演练的备份只是心理安慰。版本升级、表结构变化、权限差异都可能让旧 dump 在关键时刻打不开只有演练能提前暴露这些问题。二、动手前的 3 项确认这节不配置任何东西只回答三个问题库在哪、租户清单从哪来、备份放哪。1. 运行环境。如果是 docker compose 部署看仓库 docker/docker-compose.postgres.yml 里的 postgres 服务镜像是 postgres:16容器按默认命名规则一般叫 thingsboard_postgres_1后文脚本都按这个写。裸机部署就把 docker exec 换成本机 psql。数据库类型sql 或 nosql在 application/src/main/conf/thingsboard.conf 中定义动手前先确认自己用的是哪一种。2. 租户清单来源。别手抄租户 ID直接从数据库 tenant 表读 id 列。代码侧的对应关系可以看仓库 dao/src/main/java/org/thingsboard/server/dao/tenant/ 目录下的 TenantDao 接口各业务表的 tenant_id 都源于它的读写。3. 备份存放位置。备份目录不要和数据库放同一块盘本地备份至少落在独立挂载点。异地留存放第三步处理。三、三步搭好自动备份第一步按租户导出数据先写单租户导出脚本。思路是用 Tenant ID 锁定分表共享表用 --where 过滤 tenant_id再把 tenant、user 这些元数据表一起打进同一个目录恢复时可以整包还原。#!/bin/bash # backup_tenant.sh: 单租户数据导出 TENANT_ID$1 OUT./backups/tenant_${TENANT_ID}_$(date %F_%H%M) mkdir -p $OUT docker exec -t thingsboard_postgres_1 pg_dump -U postgres \ -d thingsboard -t ts_kv_${TENANT_ID}* $OUT/ts_kv.sql docker exec -t thingsboard_postgres_1 pg_dump -U postgres \ -d thingsboard --data-only -t attributes \ --where tenant_id${TENANT_ID} $OUT/attributes.sql docker exec -t thingsboard_postgres_1 pg_dump -U postgres \ -d thingsboard -t tenant -t user $OUT/meta.sql脚本第一个参数就是租户 ID方便外层循环反复调用。第二步配好定时任务外层脚本负责取全量租户 ID、循环调用第一步。清单直接从库里 SQL 取比调 REST 接口稳不依赖 token 是否过期。#!/bin/bash # backup_all_tenants.sh: 遍历所有租户逐一导出 TENANT_IDS$(docker exec -t thingsboard_postgres_1 psql -U postgres \ -d thingsboard -tA -c SELECT id FROM tenant) for tid in $TENANT_IDS; do ./backup_tenant.sh $tid done再注册 crontab每天凌晨 2 点执行stdout 和 stderr 都落到日志文件0 2 * * * /opt/tb-backup/backup_all_tenants.sh /var/log/tb_backup.log 21租户多、耗时长时可以把循环换成 xargs -P 并行但先量一下单次导出对库的压力再放开并发。第三步压缩归档与异地留存导出完成后立刻压缩并推送异地留存策略一次定死每日备份留 30 天月度备份留 12 个月超期的自动删掉别等磁盘写满才发现。# 归档后推送到远端存储并清理过期备份 tar -czf $OUT.tar.gz -C ./backups $(basename $OUT) rclone copy $OUT.tar.gz s3:tb-backups/ --progress find ./backups -name *.tar.gz -mtime 30 -delete四、怎么证明这份备份真的能救急没验证过的备份不算备份。校验分两层每日的记录数一致性校验加每月一次的恢复演练。记录数校验在备份完成后当场做导出前统计该租户 ts_kv 表行数把 dump 恢复到测试库后再统计一次两边相等才算这一份合格否则写入错误日志# 备份前后行数必须一致否则记错误日志 PRE$(docker exec -t thingsboard_postgres_1 psql -U postgres \ -d thingsboard -tA -c SELECT count(*) FROM ts_kv_${TENANT_ID}) POST$(docker exec -t thingsboard_test_postgres_1 psql -U postgres \ -d thingsboard_test -tA -c SELECT count(*) FROM ts_kv_${TENANT_ID}) [ $PRE $POST ] echo OK: $TENANT_ID \ || echo FAILED: $TENANT_ID /var/log/tb_backup_err.log恢复演练更重一点每月挑一个租户整包还原到干净的测试库确认能登录、设备列表在、时序数据完整。这一步验证的不只是数据还有账号权限和版本兼容性这条完整恢复路径。错误日志落盘后把它接进监控模块配置告警tb_backup_err.log 出现一行就推给值班人别让失败静默过夜。五、FAQQ1执行时间窗怎么选看写入量的时间曲线挑设备上报的低谷多数场景是凌晨。时序写入多的平台默认凌晨 2 点较稳单次导出慢就提前开始。Q2对线上性能有影响吗pg_dump 是顺序读压力不大但大分表会产生 IO 竞争。用 nice -n 19 或 ionice 降优先级租户多时错开时间窗分批跑避免并发导出挤占同一时间。Q3存储膨胀怎么控三件事留存窗口先定死上面那行 find -delete 是底线大租户改月度全量加周增量目录容量挂进容量监控涨到 80% 先告警。Q4权限与密钥怎么管数据库密码、rclone 密钥一律不进脚本放进环境变量文件仓库 docker/ 目录下的 .env 文件可以参考这种组织方式备份账号只给 SELECT 和 dump 所需的最小权限。写在最后三个脚本、记录数校验、月度恢复演练就是 ThingsBoard 多租户备份的完整闭环每个环节都有可验证的出口。下一步建议先把错误日志的告警通道接通再给时序数据大的租户切增量备份时间窗和存储占用都能砍掉一半。【免费下载链接】thingsboardOpen-source IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考