外观
大版本升级：从 OMV 7 到 OMV 8
完成后，一台运行 OMV 7（Debian 12）的机器被原地升级成 OMV 8（Debian 13），数据盘上的数据、共享和配置保留，插件按 OMV 8 的版本重新就位。
OMV 7 已于 2026 年 6 月停止支持（见 OMV 7 停止支持），还在用的应该尽快规划升级。大版本升级是整个系统的发行版升级，是 NAS 上风险最高的常规维护，下面的准备工作一项都别省。
先选路线：原地升级还是重装
| 原地升级 | 备份后全新安装 OMV 8 | |
|---|---|---|
| 做法 | 在 OMV 7 上运行 omv-release-upgrade | 用 ISO 装到系统盘，挂载已有数据盘，重建配置 |
| 优点 | 配置、用户、插件设置保留 | 系统最干净，没有历史包袱，也是一次完整的恢复演练 |
| 缺点 | 出问题的方式多，插件和第三方软件源可能残留旧状态 | 要手工重建共享、用户、服务，UID 要对上 |
| 适合 | 配置复杂、插件不多、系统比较干净的 | 系统改动很多、装过很多第三方东西的 |
重装的步骤见用 ISO 安装 OMV和系统盘坏了：重装并接回数据盘。OMV 8 只支持 64 位（amd64、arm64），32 位机器两条路线都走不通，只能换硬件。
官方说明在哪里
- 官方文档的 APT 与更新页只有一段话：
omv-release-upgrade只包含在下一个大版本之前的最后几个小版本里，用来把系统迁移到下一个大版本，通常也包含 Debian 的发行版升级。 - OMV 的更新记录里，
7.7.24-6（2025-12-07）加入了迁移到 OMV 8 的omv-release-upgrade。所以要先把 OMV 7 更新到这个版本或更高版本，才有这个命令。 - OMV 8 发布时（2025-12-24）的报道转述：OMV 7 系统可以用
omv-release-upgrade命令行工具直接升级，见 Linuxiac 的报道。 - 截至 2026-10-23，官方文档和 omv-extras wiki 都没有专门的 7 到 8 升级步骤页。本篇依据 OMV 7.x 分支里的升级脚本源码编写，没有在实机上执行过升级，所以下面凡是「脚本做了什么」都是读代码的结论。
脚本做了什么
在 OMV 7 的 shell 以 root 身份运行 omv-release-upgrade，它按顺序做这些事：
- 检查：
uname -m必须是x86_64、amd64、aarch64或arm64；系统里不能装有桌面环境，否则拒绝运行。 - 弹出一个英文确认框：「Do you really want to upgrade your system to release version 8 (Synchrony)? Please ensure that all your installed plugins are available for this release.」选是才继续。
- 先运行一次
omv-upgrade，把 OMV 7 更新到最新。 - 运行升级前脚本（任何一个失败就中止）。按文件名和内容，主要是：如果还没做过
/usr合并就安装usrmerge；清理本地上传包仓库；暂停 cron、anacron、monit 和插件索引的重建；删除内核 backports 的源和优先级配置；重写/etc/apt/sources.list.d/openmediavault.list指向synchrony，删除openmediavault-debian-security.list和openmediavault-os-security.list，把/etc/apt/sources.list里的bookworm改成trixie；把配置数据库复制成config.xml.7x.bak（已有则不覆盖）。 apt-get update，然后apt-get dist-upgrade，带--force-confdef、--force-confold、--no-install-recommends、--allow-change-held-packages、--auto-remove等参数。- 运行升级后脚本（失败不中止）。按文件名和内容：恢复 cron、anacron、monit，移除
cpufrequtils，把 cpupower、nginx、php-fpm 标记为待部署，执行omv-salt deploy run --append-dirty，清理不再需要的包，重建软件包索引，重启omv-engined。 - 再运行一次
omv-upgrade，最后提示「The upgrade has completed successfully. Please reboot the system.」
它不做的事：不检查磁盘空间，不检查被 hold 的包，不检查插件是否兼容（只有确认框里的一句提醒），不修改 omv-extras、Docker、Proxmox 内核等第三方软件源。这几项要你自己处理。
大版本升级会替换整个系统，没有降级路径
- 影响范围：Debian 12 升到 13，几乎所有软件包都会升级，服务在升级期间反复重启，最后必须重启整机。耗时取决于网络和硬件，本站没有可靠的数字。数据盘上的文件不会被格式化，但升级出问题时可能整台机器进不了系统，这不等于数据有备份。
- 前置条件：系统盘有升级前的完整备份（镜像，或 PVE 快照）；重要数据另有一份独立备份；确认是 64 位；检查过插件；有本机控制台；
config.xml自己另存了一份。 - 怎么回退：没有降级。唯一可靠的退路是恢复升级前的系统盘备份。不要自己手工把软件包降回 Debian 12 的版本。
升级前检查清单
| 检查项 | 怎么检查 |
|---|---|
| OMV 7 已更新到最新，并重启过 | 运行 omv-upgrade，重启后用下面的命令看版本 |
omv-release-upgrade 存在 | command -v omv-release-upgrade 有输出 |
| 是 64 位用户空间 | dpkg --print-architecture 输出 amd64 或 arm64 |
| 系统盘空间够 | df -h / 留足余量；脚本不检查，官方没给数字 |
| 系统盘有备份 | 备份系统盘，最好已演练过恢复 |
| 配置副本另存一份 | 见OMV 配置怎么留底 |
| 数据有独立备份 | 升级不会动数据盘，但这是你最后的保险 |
| 已装插件逐个确认 | 见下一节 |
| 第三方软件源有记录 | /etc/apt/sources.list.d/ 下 Docker、Proxmox 内核、Armbian 等的文件，升级后要检查 |
| 没有待应用更改、没有长任务 | 无黄色提示条，备份、scrub、RAID 同步都已结束 |
| 有本机控制台 | 显示器键盘、IPMI 或 PVE 控制台 |
查看 OMV 版本和已装的 OMV 软件包，以 root 身份在 OMV 的 shell 执行（只读命令）：
sh
dpkg-query -W -f='${Version}\n' openmediavault
dpkg-query -W -f='${Package} ${Version}\n' 'openmediavault-*'第一条的版本要不低于 7.7.24-6。
dpkg --print-architecture 比 uname -m 更可靠：有些单板机是 64 位内核加 32 位用户空间，uname -m 显示 aarch64，能通过脚本的检查，但 OMV 8 的软件源没有 armhf。
插件检查
对照上面第二条命令列出的插件，逐个看 插件与应用里的状态，变化汇总见 OMV 8 插件变化。需要特别留意的：
| 插件 | OMV 8 上的情况 | 升级前怎么办 |
|---|---|---|
openmediavault-s3（MinIO） | 官方已于 2026-01 移除 | 数据先导出并备份；以后改用容器 |
openmediavault-forkeddaapd | 已由 openmediavault-owntone 取代 | 确认已迁移到 OwnTone |
openmediavault-flashmemory | 已归档，由 openmediavault-writecache 取代，synchrony 软件源里没有它 | 升级后立即安装 writecache，U 盘或 SD 卡做系统盘的必装，见 writecache 插件 |
diskclone、downloader 等 omv-extras 插件 | 截至 2026-10-22，synchrony 软件源里没有它们的版本 | 记下配置，找替代，不要依赖 |
升级前卸载不再需要的插件，同时记录它们的设置，因为卸载会清除配置。omv-extras 的 fail2ban 插件有一个未关闭的 issue（#42）：旧版插件的卸载脚本在升级中途找不到 OMV 的辅助函数，导致升级中断。维护者的态度是不改各个插件的卸载脚本。
升级后插件会按 OMV 8 的软件源重新安装或更新。omv-extras 本身要换成 OMV 8 的版本，见安装 omv-extras。
升级步骤
备份，按上面的清单。
在 OMV 7 上运行
omv-upgrade（或在界面里更新），重启，确认版本和命令都就位。到本机控制台操作。只能用 SSH 的话，先装好
tmux（apt-get install tmux）并在里面运行，避免断线中断升级。以 root 身份运行：
shomv-release-upgrade阅读确认框，选是，不要中断。看到「The upgrade has completed successfully. Please reboot the system.」之后重启：
shreboot
升级之后
- 登录 Web 界面，浏览器硬刷新（Ctrl+Shift+R）。确认版本已经是 8.x。
- 如果出现黄色提示条，点 应用。
- 逐项检查：磁盘和文件系统都已挂载、共享可访问、SMB 和 NFS 等服务正常、容器在运行、计划任务和备份任务还在、
系统 → 通知（System → Notification）发测试邮件能收到、SMART 正常、UPS 状态正常。 - 检查
系统 → 电源管理 → 设置（System → Power Management → Settings）：OMV 8 把cpufrequtils换成了linux-cpupower，CPU 频率调节要重新确认，见电源管理。 apt-get update不应报错。检查 omv-extras 和 Docker 的软件源是否还指向旧的bookworm。- 打开
系统 → 插件（System → Plugins），缺失的插件重新安装。 - 重新做一次系统盘备份，并保留升级前的备份，直到你确认一切正常。
升级脚本复制的 config.xml.7x.bak，会在你升级后第一次点 应用 时被删除：应用成功后 OMV 按 config.xml.* 通配清理修订文件，这个文件也匹配（源码已确认）。在那之前如果它还在，omv-firstaid 的「恢复配置备份」还可能把它当成最新的备份，恢复出来的是 OMV 7 的配置库，不要这样做（这一点按源码推断，未实机验证）。所以前面才要求你自己另存一份，见OMV 配置怎么留底。
常见问题
升级后 Web 界面 502 Bad Gateway。 见 502 Bad Gateway 与 Failed to connect to socket。论坛上有用户报告，升级后 PHP 8.4-FPM 没有就绪时会出现，并用 omv-extras 维护者提供的非官方修复脚本 fix7to8upgrade 解决（本站无法读取论坛原帖，属于待核实的说法）。这个脚本在 installScript 仓库里，它会删除并改写 apt 源、下载 .deb 与 omv-mkaptidx 并执行。读懂它再决定要不要运行，把它当最后手段，本站不提供一键命令。
升级中途被中断，或 dpkg 报错。 不要强行重启。以 root 身份依次执行 dpkg --configure -a、apt-get --fix-broken install、omv-upgrade。如果中断后 omv-release-upgrade 命令和界面都用不了，先别乱试，去看上面 fail2ban 的 issue 里的说明，不行就恢复备份。
提示 omv-extras 的软件源或密钥有问题。 有用户在论坛报告，更新 omv-extras 后重试可以解决（待核实）。见安装 omv-extras。
树莓派或 ARM 设备升级失败。 32 位用户空间无法升级。需要在 64 位系统上重新安装，见在树莓派等 ARM 设备上安装。
能不能回到 OMV 7？ 不能降级，只能恢复备份。
检查结果
- 版本是 8.x：
dpkg-query -W -f='${Version}\n' openmediavault。 apt-get update无报错，omv-upgrade之后没有待升级的包。- 磁盘、共享、服务、容器、备份任务、通知都检查过。
- 升级后的系统盘备份已经做好。
参考资料
- OMV 7.x 分支中的升级脚本：
omv-release-upgrade及usr/share/openmediavault/release-upgrade/下的pre.d、post.d脚本。 - 官方文档：APT 与更新、版本表。
- 版本背景见版本演进：OMV 与 Debian 的对应关系，8.0 的变化见 OMV 8.0 Synchrony。