三步跑通ThingsBoard多租户备份：定时任务+恢复演练+行数核对完整方案

三步跑通ThingsBoard多租户备份定时任务恢复演练行数核对完整方案【免费下载链接】thingsboardOpen-source IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard凌晨三点一位租户反馈设备历史曲线断档排查发现当天全库备份因磁盘满静默失败——手动 pg_dump 一次要十几分钟还总漏核对。用这套方案做完ThingsBoard 每天凌晨自动完成整库备份逐租户核对实体行数并真实导入临时库做恢复演练备份是否能用当天就有结论。环境与前置条件项目要求运行方式docker compose 部署Postgres 服务来自 docker/docker-compose.postgres.yml数据库库名thingsboard账号/密码以 compose 文件中的POSTGRES_DB、POSTGRES_PASSWORD为准宿主机已安装bash、cron备份目录建在仓库外如/opt/tb-backup主配置application/src/main/resources/thingsboard.yml注意 EDQS 本地模式下 RocksDB 数据目录edqs.local.rocksdb_path它不在 pg_dump 覆盖范围内租户模块租户 CRUD 见 dao/src/main/java/org/thingsboard/server/dao/tenant/TenantDao.java卷持久化数据卷参考 docker/docker-compose.volumes.yml数据层先搞清楚租户数据存在哪ThingsBoard 的租户隔离是行级的device、asset、customer等业务表都带tenant_id列见 dao/src/main/resources/sql/schema-entities.sql时序数据统一落在ts_kv/ts_kv_latest里、按entity_id定位而不是每个租户一张表。所以备份粒度是整库 dump租户维度的核对放在校验阶段做-- 实体表结构schema-entities.sql 节选 CREATE TABLE IF NOT EXISTS device ( id uuid ..., tenant_id uuid NOT NULL, -- 租户隔离列 ... ); -- ts_kv_latest 按 (entity_id, key) 为主键实体归属于租户提示如果 EDQS 以 local 模式启用edqs.mode: local还要把rocksdb_path指向的目录一并打包否则设备时序查询层的数据不在备份里。数据层结论一次pg_dump覆盖全部租户下面交给定时任务。调度层凌晨两点自动全量备份备份脚本放在仓库外的/opt/tb-backup/核心是dump 逐租户计数留底#!/usr/bin/env bash # /opt/tb-backup/tb_backup.sh set -euo pipefail DBthingsboard STAMP$(date %Y%m%d-%H%M%S) OUT/opt/tb-backup/dumps mkdir -p $OUT PG_CTR$(docker ps --format {{.Names}} | grep -i postgres | head -1) docker exec -e PGPASSWORDpostgres $PG_CTR \ pg_dump -U postgres -Fc $DB $OUT/tb_$STAMP.dump # 留底每个租户的设备数恢复后逐行比对 docker exec -e PGPASSWORDpostgres $PG_CTR psql -U postgres -d $DB -tA \ -c SELECT tenant ||id|| devices||count(*) FROM device GROUP BY 1 \ $OUT/counts_$STAMP.txt md5sum $OUT/tb_$STAMP.dump $OUT/tb_$STAMP.md5用 crontab 接管调度即可# crontab -e 0 2 * * * /opt/tb-backup/tb_backup.sh /var/log/tb-backup.log 21调度层跑通后还要回答一个问题dump 文件完好不等于数据可用进入校验层。校验层恢复不出来等于没备选恢复演练 行数比对两招。演练脚本把最新 dump 灌进一个临时库核对后直接删库全程不影响生产#!/usr/bin/env bash # /opt/tb-backup/verify_restore.sh 用法: verify_restore.sh dump文件 DUMP$1 TMP_DBtb_restore_test PG_CTR$(docker ps --format {{.Names}} | grep -i postgres | head -1) docker exec -e PGPASSWORDpostgres $PG_CTR createdb -U postgres $TMP_DB docker exec -i -e PGPASSWORDpostgres $PG_CTR \ pg_restore -U postgres -d $TMP_DB $DUMP # 与备份时留底的 counts_*.txt 逐租户比对 docker exec -e PGPASSWORDpostgres $PG_CTR psql -U postgres -d $TMP_DB -tA \ -c SELECT tenant ||id|| devices||count(*) FROM device GROUP BY 1 \ | diff (cat /opt/tb-backup/dumps/counts_*.txt | tail -1) - \ echo VERIFY_OK $DUMP || echo VERIFY_FAIL $DUMP docker exec -e PGPASSWORDpostgres $PG_CTR dropdb -U postgres $TMP_DB提示把verify_restore.sh也加进 crontab如每日 3 点校验前一天的 dump并在grep VERIFY_FAIL /var/log/tb-backup.log上接监控告警监控侧配置可参考 monitoring/src/main/conf/tb-monitoring.conf 的写法。FAQ最常踩的三个坑Q脚本里找不到 postgres 容器pg_dump没输出APG_CTR取的是docker ps里名字含 postgres 的容器。换过部署方式如独立部署的 RDS时改成直连pg_dump -h host -U postgres -Fc thingsboard。Qmkdir: cannot create directory /opt/tb-backupPermission deniedAcron 以哪个用户跑就以哪个用户建目录。确认crontab -l所属用户用sudo -u 该用户 mkdir -p建好并授权再执行脚本。Q恢复演练时pg_restore报错退出A-Fc自定义格式必须用pg_restore还原不能用psql -f报错多为目标库版本高于源库。演练库createdb的报错已存在可先dropdb再重试。进阶方向数据量涨到几十 GB 后换成pg_basebackup WAL 归档做增量链路dump 文件再经rclone/aws s3同步到异地保留策略建议日备 30 天 月备 12 个月。整篇方案只有两个脚本加两条 cron备份自动跑、结果自动验出问题时你拿到的是哪一行数据丢了而不是一个无法判断好坏的压缩包。【免费下载链接】thingsboardOpen-source IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考