备份与快照恢复策略

备份是 HA 玩家的第一纪律

玩 HA 久了会形成一种共识：配置可以慢慢调，自动化可以慢慢写，唯独备份不能等。理由很简单——你投入的时间会越积越多，而所有这些心血都存在一台随时可能出问题的机器上。磁盘会坏，升级会翻车，熊孩子会拔电源，一次没备份的灾难就能让几个月的调校成果归零。本篇讲清楚三件事：备份什么、怎么备份、坏了怎么恢复。

备份这件事在 HA 圈子里甚至有句半开玩笑的话：判断一个人是不是老玩家，看他备份方案健不健全就行了。新手总觉得灾难离自己很远，等真的赶上一回就什么都懂了。希望读到这里的你属于前者。

备份到底在备份什么

先厘清范围，避免把时间花在不该备份的东西上：

一句话总结：配置类数据天天备，历史类数据定期备，程序文件不用备。把这套尺度放在心里，备份方案就不会跑偏。

顺带回答一个高频疑问：备份文件要放在 HA 本机吗？要，但绝不能只放在本机。本机副本的意义是恢复快——出问题时不用先找另一台机器下载备份；本机之外的副本的意义是保命——主机彻底报废时它是你唯一的指望。两者都不可省略。

再强调一个小细节：备份文件里包含令牌和密码（这正是它能完整重建系统的原因），所以传输和存放时按敏感文件对待——别往公开网盘或公开仓库丢，哪怕你觉得没啥，养成良好的数据习惯总没坏处。这一条也解释了为什么很多人选择 NAS 上的加密目录来存放 HA 备份。

HAOS：开箱即用的快照系统

HAOS 的备份功能是三种形态里最完善的，位置在系统设置的备份页面。它可以把整个 HA 实例打包成一个快照文件，内容包括：

• 全部配置和 .storage 数据
• 所有集成的登录状态
• 仪表盘和自动化
• 可选包含的 Add-on 数据和历史数据库

快照是全量的、自包含的——一个文件就能在另一台机器上重建整个 HA，这是它最大的特点，也是其它形态羡慕不来的能力。

操作上就是创建备份、等待打包、下载到本地或指定位置。恢复时同样在备份页面选择一个快照导入，点一下就开始还原，全程不需要碰命令行。版本大升级之前备份一次，是 HAOS 用户的基本动作。

希望大家至少把这些时刻触发备份：大版本升级前、大批量改动前、安装新的集成或 Add-on 前。频次上不用每天，一周或改动时备份足以应对绝大多数情况。

一个贴心的细节：HAOS 的备份页面会显示每次备份包含的内容摘要，养成扫一眼的习惯，确认想要的都勾上了。另一个常见姿势是给备份起个有意义的名字，比如「升级前快照」「装 Node-RED 前」，三个月后翻列表你会感谢当时起名的自己。

Container：自己动手丰衣足食

Container 用户没有内置快照系统，但这件事并不难，核心动作只有一个：把配置目录复制走。两种常见做法：

做法一：NAS 同步工具。配置目录本来就在 NAS 上，用群晖的 Cloud Sync 或其它同步工具，把目录定时同步到另一处（另一台 NAS、网盘或对象存储）。配置文件小，同步几乎不占带宽。具体工具的配置方法可以参考群晖 DSM 实用指南。

做法二：定时任务打包。写个简单的定时脚本，把配置目录打成一个压缩包，保存若干天的滚动副本。脚本逻辑非常短：压缩、加日期名、删旧文件，三行核心命令。跑在宿主机的 cron 或容器管理工具里即可。

给一个可直接改用的脚本骨架（注意脚本里的英文符号不要乱改）：

#!/bin/bash
# HA 配置目录打包脚本
BAK_DIR=/备份存放目录
HA_DIR=/你的HA配置目录
DATE=$(date +%Y%m%d)
tar -czf "$BAK_DIR/ha-$DATE.tar.gz" -C "$HA_DIR" .
# 删除 7 天前的副本
find "$BAK_DIR" -name "ha-*.tar.gz" -mtime +7 -delete

配好之后，每天半夜跑一次，你的备份就永远是新鲜的。要是宿主机连 cron 都没有，在群晖的任务计划里写同样的命令也行，差别只在敲门方式不同。

不止备份脚本，HA 自身也能在 HAOS 上设置自动备份计划：系统设置里可以配置定期备份的频率和保留份数，适合不想写脚本的用户。两种方式选一个即可，别重复备份浪费空间。

不管用哪种做法，记住一个要求：至少留一份在别的物理位置。全部副本都在同一台 NAS 上，磁盘损坏时全家一起沉。这也是自建 NAS 完全指南里反复强调的数据保护原则，在 HA 这儿同样适用。

给个具体的保留策略当样板：每日自动备份保留最近 7 份，每周备份保留 4 份，每月备份保留 3 份。这样无论你想回到昨天、上周还是上个月的状态，手上都有合适的副本，而总占用空间仍然小到可以忽略。

恢复演练：别等出事才第一次操作

备份方案做完，抽一个小时做一次完整的恢复演练——这是区分老手和新手的分水岭。演练步骤：

1. 找一台测试机或新容器，什么也不配置。
2. 按正常流程装一个空的 HA。
3. 把最近一份备份恢复进去。
4. 检查设备、自动化、仪表盘是否齐全。

演练能帮你暴露三个隐形问题：备份文件其实是坏的、恢复流程某个步骤你并不会操作、新环境的网络或 USB 配置和备份不兼容。这三件事任何一个等出事当天才发现，都会让停电的夜晚雪上加霜。一年做一次演练，花的时间不够看一集电视剧，但能让你在真正的故障面前像个老手一样从容。

升级前备份：一条铁律

HA 每月一个版本，升级本身就带更新风险。把流程固定下来：

1. 看一眼更新说明，有没有影响你的集成。
2. 做一次完整备份，确认下载到本地。
3. 执行升级，观察启动日志。
4. 快速检查核心功能：设备在线、自动化正常、手机 App 能连。

这四步走完再去做别的，比升级后手忙脚乱翻论坛有效率得多。哪怕升级失败，回滚也是分钟级的事——有备份的人看升级失败叫小波折，没备份的人那叫灾难。把这条铁律传达给同样在玩 HA 的朋友，算是对社区的一点回报。

异地与版本管理

随着备份文件变多，再来两个讲究：

• 滚动保留：保留最近几份每日备份加上每月一份长期备份，既省空间又不丢失历史。
• 改名归档：文件名带上日期和简短说明（比如升级前、大改前），将来想找特定节点一目了然。备份文件本身带时间戳，但多个来源混合存放时自己命名更清楚。

什么情况会用到备份

说得再热闹，不如列一下真实世界里的触发场景，帮你判断自己的备份方案是否够用：

• 系统升级之后集成大面积掉线，需要回滚到旧版本。
• 硬盘突然故障，整台 HA 主机需要重建。
• 手滑改错配置，系统起不来，需要回到改之前。
• 想把 HA 从旧机器迁到新机器。
• 玩家最怕的误操作：手滑删掉整个 .storage 目录。

这些场景里只有最后一条是当场无解的——其它的，只要备份在，都是十几分钟的事。希望这份清单能给你足够的动力去把备份做扎实。

恢复之后要做的事

备份恢复完成不等于万事大吉，还有几样习惯性的检查动作：

• 核对集成状态：云端类集成可能需要重新登录或刷新令牌，逐个点一遍比较安心。
• 检查自动化日志：恢复后让几条规则跑一下，确认触发和动作都正常。
• 确认协调器连接：换了主机或容器路径变化，Zigbee 协调器可能需要重新指定，这是迁移事故率最高的一环。
• 家人入口：确认家人的手机 App 都能重新连上，不然第一个找上门的就是他们。

做完这四件事，才算一次完整的恢复。把它们写成自己的恢复清单，出事时照着打勾，比靠记忆和肾上腺素靠谱。

延伸阅读

• 自建 NAS 完全指南：多盘位冗余和异地同步的整体方案
• 软路由入门指南：定时任务与脚本在软路由上的运行方式