外观
健康检查清单
这是整本指南里维护部分的汇总：一份可以复制到笔记里、照着勾选的清单。完成后，你每天花几十秒、每周十分钟、每月半小时，就能在问题伤到数据之前发现它。
清单里每一项都写了去哪里看。大部分细节在前面的文章里，这里只给入口和判断标准。
先让 OMV 替你盯着
检查清单是补充，不是替代。先把能自动通知的都打开，让问题自己找上门。OMV 默认已经在做的事：
| 事项 | 频率 | 邮件通知 |
|---|---|---|
| S.M.A.R.T. 监控硬盘 | 持续，检查间隔默认 1800 秒 | 系统 → 通知 → 事件（System → Notification → Events）里的 S.M.A.R.T. |
| Btrfs 文件系统错误检查 | 每天 | 杂项 |
| Btrfs scrub | 每月 | 杂项 |
| 有未应用的配置更改 | 每天提醒 | 杂项 |
| 需要重启系统 | 每天提醒 | 更新管理 |
| 可升级的软件包 | 每天或每周 | 更新管理 |
| 内核日志里的块设备 I/O 错误 | 实时（8.5.10 起），同一类邮件至少间隔 5 分钟 | 杂项 |
| 账户因连续登录失败被临时锁定（3 分钟） | 实时，另有每日汇总 | 验证 |
| SSL 证书快到期 | 每天检查，默认到期前 7 天开始提醒 | 杂项 |
| 系统监测：进程、平均负载、CPU 使用量、内存使用量、文件系统 | 持续 | 名称以「监测 -」开头的五项 |
这些全部依赖邮件。 没有配置好 SMTP，或者事件没有勾选，就等于没有。先做这一步：配置邮件通知，并且发一封测试邮件，确认真的收到。更进一步的硬盘故障预警见硬盘故障预警。
每天（30 秒）
打开 仪表盘（Dashboard），详见仪表盘、系统信息与性能统计。
- [ ] S.M.A.R.T. 状态全部正常，没有黄色或红色的盘
- [ ] 硬盘温度没有明显偏高，也没有突然升高
- [ ] 文件系统用量都有余量
- [ ] 服务里你用到的服务都在运行
- [ ] 没有有可用更新、需要重启系统的提示，或者你有意推迟
- [ ] 页面顶部没有黄色的待应用的配置更改提示条
- [ ] 邮箱里没有 SMART、备份失败、UPS、Btrfs 错误之类的通知
每周（10 分钟）
| 检查项 | 去哪里看 | 不正常怎么办 |
|---|---|---|
| 每个备份任务最近一次成功了 | 诊断 → 系统日志（Diagnostics → System Logs）里的 Rsync - 任务、/var/log/omv-backup.log、restic 和 borg 的日志、邮件 | 失败的任务马上查原因，见备份章 |
| 登录失败、内核错误 | 诊断 → 系统日志：验证、内核 | 反复的登录失败检查暴露面；I/O 错误立刻看硬盘，见查看系统日志 |
| 安装更新 | 系统 → 更新管理 → 更新（System → Update Management → Updates） | 按自己的节奏，更新前先看系统更新的清单 |
| 短时自检结果 | 存储器 → S.M.A.R.T. → 设备（Storage → S.M.A.R.T. → Devices），选中硬盘后看详细信息里的 自检日志 | 失败的盘按S.M.A.R.T.处理 |
| RAID 或阵列状态 | 存储器 → RAID 管理（Storage → Multiple Device）、ZFS、SnapRAID 的页面 | 降级见RAID 降级 |
| 容器都在运行 | 服务 → Compose → Containers（Services → Compose → Containers），或仪表盘的小部件 | 见容器启动失败 |
| Docker 占用的空间 | Compose 的镜像、卷页面 | 清理不用的镜像，见更新与备份容器 |
| 快照数量和占用 | 存储器 → 共享文件夹 → 所有快照（Storage → Shared Folders → All Snapshots） | 调整保留数量，见快照 |
每月（30 分钟）
| 检查项 | 去哪里看 | 不正常怎么办 |
|---|---|---|
| 硬盘关键属性有没有恶化 | 存储器 → S.M.A.R.T. → 设备 里的 属性：重分配扇区（5）、报告的不可纠正错误（187）、待处理扇区（197）、离线不可纠正扇区（198）、UDMA CRC 错误（199） | 数值在涨就准备换盘，别等它坏 |
| 校验和 scrub 在运行且没有错 | Btrfs：OMV 默认每月自动 scrub；ZFS、SnapRAID、md 阵列看各自的计划和结果 | 发现错误先备份，再按各自的维护文章处理 |
| 空间趋势 | 诊断 → 性能统计 → 文件系统用量（Diagnostics → Performance Statistics → File System Usage）的月、年图 | 到 75% 左右就规划扩容 |
| 内存、负载趋势 | 诊断 → 性能统计 的内存、平均负载 | 持续走高去查进程，见CPU 或负载居高不下 |
| 做一次文件级恢复 | 随便取回一个备份里的文件并打开 | 取不回来，说明备份有问题，马上处理，见恢复演练 |
config.xml 副本是最新的 | 你保存副本的位置 | 见OMV 配置怎么留底 |
| 账号和共享权限 | 用户 → 用户（Users → Users）、存储器 → 共享文件夹 | 删除不再用的账号和共享 |
| 插件是否有更新、有没有被弃用 | 系统 → 插件（System → Plugins） | 见插件体系 |
| UPS 电池状态 | 诊断 → 服务 → UPS（Diagnostics → Services → UPS） | 有更换提示就换，见接入 UPS |
每季度（1 小时）
- [ ] 容器级恢复演练：恢复一个一次性演练应用，见恢复演练
- [ ] 发一封测试通知邮件，确认告警链路还通
- [ ] 重启一次，在维护窗口里确认所有磁盘自动挂载、服务和容器都自动起来，没有需要手动处理的
- [ ] 检查暴露面：路由器的端口映射、防火墙规则、两步验证、SSH 配置，对照安全检查清单
- [ ] 检查系统盘的健康：SMART，U 盘或 SD 卡还要看写入寿命，确认 writecache 在工作
- [ ] 清理旧的备份、快照和容器镜像，释放空间
- [ ] 确认异地副本还在更新：轮换的 USB 盘换过了吗？云备份最近一次成功是什么时候？
每年，以及大变更之后
- [ ] 系统级恢复演练：把系统盘备份恢复到一块测试盘，见恢复演练
- [ ] 做一次真实的 UPS 断电测试，并评估电池是否该换
- [ ] 评估硬盘的年龄和通电时间，准备好备用盘
- [ ] 检查 OMV 版本是否还在支持期内，规划下一次大版本升级，版本时间表见版本演进
- [ ] 轮换密码、密钥和令牌：管理员密码、SSH 密钥、API 令牌、备份口令（换备份口令要先确认旧备份还能用旧口令打开）
- [ ] 重新读一遍这份清单，把和你的环境不再相符的地方改掉
加盘、换盘、升级、改网络、换路由器这些大变更之后，把每天的检查和备份确认再做一遍。
记录
把检查记在一个地方，下面的表可以直接用：
| 日期 | 周期 | 检查人 | 发现的问题 | 处理结果 |
|---|---|---|---|---|
写下来有两个用处：出问题时能回头看「上一次正常是什么时候」，和一个人维护时不靠记忆。
检查结果
- 邮件通知已配置，你收到过测试邮件。
- 你把上面的清单复制进了自己的笔记，并且在日历里设了提醒：每周、每月、每季度、每年。
- 每个周期至少做过一遍，每一项你都知道去哪里看。
- 发现的问题都有处理记录。
常见问题
项目太多，做不完怎么办？ 先只做「每天」和「每周」，其余的随时间补上。最重要的两件事是：邮件通知能收到，和备份真的能恢复。
能不能全部自动化？ 一部分可以，见外部监控：Prometheus、Grafana 与 SNMP和通知扩展：Telegram 等第三方通知，但「恢复演练」这类需要判断的事，必须有人做。
一个人维护多台怎么办？ 用同一份清单，把「去哪里看」换成各台机器的入口，统一记在一个表格里。
参考资料
- 内置检查的依据：OMV 源码
etc/cron.daily/、etc/cron.weekly/、etc/cron.monthly/下的openmediavault-*脚本，和srv/salt/omv/deploy/rsyslog/。 - 各项的细节见本章前面的文章和备份与恢复。