尧图网站建设 
ThingsBoard多租户备份完整指南从租户隔离原理到恢复验证一次讲透【免费下载链接】thingsboardOpen-source IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboardThingsBoard生产环境跑在多租户模式下时某个租户误删设备或误改规则链可能牵连上千台在线设备的数据。没有备份就是直接损失而整库备份又太重、单租户备份找不到表是新手最常卡住的两个点。读完这篇你能用 3 条命令完成全库备份能按租户 ID 精准圈出单个租户的设备与时序数据还会知道拿什么指标判断备份真的可用。租户数据是怎么隔离的先看懂 tenant_id做备份之前先搞清楚一个租户的数据到底散落在哪些表里。ThingsBoard 的 SQL 后端采用共享表 tenant_id 列的模式而不是给每个租户建一套独立表。核心机制可以看 dao/src/main/resources/sql/schema-entities.sqldevice、asset、dashboard、rule_chain、customer等表都带tenant_id uuid字段租户归属就靠这一列区分。时序数据则单独存放和实体表通过entity_id关联表名内容定位租户数据的依据device/asset设备、资产元数据tenant_id直接过滤ts_kv历史时序按ts时间分区entity_id∈ 该租户的设备/资产ts_kv_latest每个键的最新值同上attributes设备属性同上租户本身的增删改查集中在 dao/src/main/java/org/thingsboard/server/dao/tenant/其中TenantDao是入口需要查某个租户的 UUID 时从这里查库即可。理解了这一点备份策略就清晰了实体数据按tenant_id圈时序数据按entity_id圈。分步操作Docker pg_dump 完成多租户备份第 1 步准备带 PostgreSQL 的运行环境推荐直接用官方 Docker Compose 起一套 PostgreSQL 后端默认是 Cassandra备份方式完全不同。在仓库根目录执行git clone https://gitcode.com/GitHub_Trending/th/thingsboard cd thingsboard/docker docker compose -f docker-compose.yml -f docker-compose.postgres.yml up -ddocker-compose.postgres.yml定义了thingsboard_postgres_1这个容器后续所有备份命令都围绕它。等 core 服务健康检查通过后登录 Web 界面默认端口 8080初始账号 sysadminthingsboard.org创建一个租户并接入几台测试设备让库里先有真实数据可备。第 2 步全量备份并建立行数基线# 整库备份-Fc 自定义格式支持后续按表选择恢复 docker exec -i thingsboard_postgres_1 pg_dump -U postgres -Fc thingsboard tb_full_$(date %F).dump # 记录租户设备数作为校验基线 docker exec -i thingsboard_postgres_1 psql -U postgres -d thingsboard -tA \ -c SELECT count(*) FROM device WHERE tenant_id租户UUID注意用-i而不是-t-t是给交互式终端加伪终端的配合重定向会把输出搞没这是新手最容易踩的坑后面常见坑里会再提一次。第 3 步按租户 ID 圈出单租户数据单租户备份的本质是一次按条件过滤的导出。先用租户 ID 查出设备清单再拿设备 ID 过滤时序表-- 单租户数据提取先拿设备ID再圈时序 SELECT count(*) FROM ts_kv WHERE entity_id IN (SELECT id FROM device WHERE tenant_id 租户UUID);实际导出时把SELECT换成COPY ( ... ) TO STDOUT或者对device、ts_kv两张表分别pg_dump --tabledevice后按上述条件过滤恢复即可。租户的仪表盘、规则链同理都是tenant_id直连过滤。第 4 步挂上定时任务自动备份在宿主机 crontab 里加一行把脚本路径换成你的实际路径0 2 * * * /opt/backup/thingsboard_backup.sh /var/log/tb_backup.log 21thingsboard_backup.sh的内容就是第 2 步那两条命令加上备份文件存在且非空的判空检查备份目录建议按日期建子目录并保留最近 30 份。验证与常见坑怎么确认备份真的可用验证方法只有一个金标准恢复出来数一数。起一个空的测试库或本地 psql 临时实例用pg_restore把.dump文件灌进去对照第 2 步记录的基线跑同样的count(*)数字一致即通过对单租户备份额外抽查ts_kv中 1~2 台设备的时序条数。恢复完成后再从 Web 界面确认对应租户的仪表盘有数据可参考上方最新值组件的样子比单纯看行数更可信。两个最常见的坑坑现象处理ts_kv_租户ID按租户拆表的假设部分资料假设时序表按租户命名直接pg_dump -t ts_kv_xxx当前 SQL 后端只有一张按时间分区的ts_kv必须按entity_id IN (...)过滤docker exec -t 重定向备份文件是 0 字节或乱码重定向场景一律用-i去掉-t上生产前的三条建议备份和数据库分开存.dump文件落到另一个卷或对象存储同盘备份等于没备。保留策略写进脚本每日备份留 30 天、每周备份留 12 个月用find -mtime 30 -delete一句话就能实现。每月做一次真实恢复演练备份的价值由恢复测试定义只看备份成功的日志是不严谨的。带走清单备份前记住两把钥匙——实体表用tenant_id时序表用entity_id命令用-i不用-t每次备份后跑一次count(*)对基线。下一步先在测试租户上完整走一遍备份 → 恢复 → 数数流程通过后再挂 cron。【免费下载链接】thingsboardOpen-source IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ThingsBoard多租户备份完整指南：从租户隔离原理到恢复验证一次讲透
ThingsBoard多租户备份完整指南从租户隔离原理到恢复验证一次讲透【免费下载链接】thingsboardOpen-source IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboardThingsBoard生产环境跑在多租户模式下时某个租户误删设备或误改规则链可能牵连上千台在线设备的数据。没有备份就是直接损失而整库备份又太重、单租户备份找不到表是新手最常卡住的两个点。读完这篇你能用 3 条命令完成全库备份能按租户 ID 精准圈出单个租户的设备与时序数据还会知道拿什么指标判断备份真的可用。租户数据是怎么隔离的先看懂 tenant_id做备份之前先搞清楚一个租户的数据到底散落在哪些表里。ThingsBoard 的 SQL 后端采用共享表 tenant_id 列的模式而不是给每个租户建一套独立表。核心机制可以看 dao/src/main/resources/sql/schema-entities.sqldevice、asset、dashboard、rule_chain、customer等表都带tenant_id uuid字段租户归属就靠这一列区分。时序数据则单独存放和实体表通过entity_id关联表名内容定位租户数据的依据device/asset设备、资产元数据tenant_id直接过滤ts_kv历史时序按ts时间分区entity_id∈ 该租户的设备/资产ts_kv_latest每个键的最新值同上attributes设备属性同上租户本身的增删改查集中在 dao/src/main/java/org/thingsboard/server/dao/tenant/其中TenantDao是入口需要查某个租户的 UUID 时从这里查库即可。理解了这一点备份策略就清晰了实体数据按tenant_id圈时序数据按entity_id圈。分步操作Docker pg_dump 完成多租户备份第 1 步准备带 PostgreSQL 的运行环境推荐直接用官方 Docker Compose 起一套 PostgreSQL 后端默认是 Cassandra备份方式完全不同。在仓库根目录执行git clone https://gitcode.com/GitHub_Trending/th/thingsboard cd thingsboard/docker docker compose -f docker-compose.yml -f docker-compose.postgres.yml up -ddocker-compose.postgres.yml定义了thingsboard_postgres_1这个容器后续所有备份命令都围绕它。等 core 服务健康检查通过后登录 Web 界面默认端口 8080初始账号 sysadminthingsboard.org创建一个租户并接入几台测试设备让库里先有真实数据可备。第 2 步全量备份并建立行数基线# 整库备份-Fc 自定义格式支持后续按表选择恢复 docker exec -i thingsboard_postgres_1 pg_dump -U postgres -Fc thingsboard tb_full_$(date %F).dump # 记录租户设备数作为校验基线 docker exec -i thingsboard_postgres_1 psql -U postgres -d thingsboard -tA \ -c SELECT count(*) FROM device WHERE tenant_id租户UUID注意用-i而不是-t-t是给交互式终端加伪终端的配合重定向会把输出搞没这是新手最容易踩的坑后面常见坑里会再提一次。第 3 步按租户 ID 圈出单租户数据单租户备份的本质是一次按条件过滤的导出。先用租户 ID 查出设备清单再拿设备 ID 过滤时序表-- 单租户数据提取先拿设备ID再圈时序 SELECT count(*) FROM ts_kv WHERE entity_id IN (SELECT id FROM device WHERE tenant_id 租户UUID);实际导出时把SELECT换成COPY ( ... ) TO STDOUT或者对device、ts_kv两张表分别pg_dump --tabledevice后按上述条件过滤恢复即可。租户的仪表盘、规则链同理都是tenant_id直连过滤。第 4 步挂上定时任务自动备份在宿主机 crontab 里加一行把脚本路径换成你的实际路径0 2 * * * /opt/backup/thingsboard_backup.sh /var/log/tb_backup.log 21thingsboard_backup.sh的内容就是第 2 步那两条命令加上备份文件存在且非空的判空检查备份目录建议按日期建子目录并保留最近 30 份。验证与常见坑怎么确认备份真的可用验证方法只有一个金标准恢复出来数一数。起一个空的测试库或本地 psql 临时实例用pg_restore把.dump文件灌进去对照第 2 步记录的基线跑同样的count(*)数字一致即通过对单租户备份额外抽查ts_kv中 1~2 台设备的时序条数。恢复完成后再从 Web 界面确认对应租户的仪表盘有数据可参考上方最新值组件的样子比单纯看行数更可信。两个最常见的坑坑现象处理ts_kv_租户ID按租户拆表的假设部分资料假设时序表按租户命名直接pg_dump -t ts_kv_xxx当前 SQL 后端只有一张按时间分区的ts_kv必须按entity_id IN (...)过滤docker exec -t 重定向备份文件是 0 字节或乱码重定向场景一律用-i去掉-t上生产前的三条建议备份和数据库分开存.dump文件落到另一个卷或对象存储同盘备份等于没备。保留策略写进脚本每日备份留 30 天、每周备份留 12 个月用find -mtime 30 -delete一句话就能实现。每月做一次真实恢复演练备份的价值由恢复测试定义只看备份成功的日志是不严谨的。带走清单备份前记住两把钥匙——实体表用tenant_id时序表用entity_id命令用-i不用-t每次备份后跑一次count(*)对基线。下一步先在测试租户上完整走一遍备份 → 恢复 → 数数流程通过后再挂 cron。【免费下载链接】thingsboardOpen-source IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考