Omarchy 系统快照完全指南：利用 Snapper 与 Limine 实现更新前自动备份、启动回滚与恢复

本指南围绕 Omarchy 的系统快照（System Snapshots）机制展开，讲解如何利用 Snapper 在每次系统更新前自动为根文件系统拍摄快照，如何在 Limine 启动菜单中按时间与版本选择快照启动，以及如何在快照环境中一键把系统恢复回去。读完本文，你将掌握 omarchy-snapshot 的完整用法、快照保留与清理策略、恢复操作的边界，以及"Direct Boot"直启模式与快照回滚之间的取舍关系。

Omarchy 将"更新前快照 + 启动菜单回滚"设计为系统更新的安全网：坏掉的升级可以在一两分钟内回滚，而不是靠手动备份或重装兜底。该设计的详细工作原理记录在 manual/47-system-snapshots.md，本文以它为骨架，并结合仓库中 bin/omarchy-snapshot、default/snapper/root、etc/limine-entry-tool.d/omarchy-defaults.conf 等源码与配置进行纵深印证。

快照机制总览：更新即自动备份

Omarchy 的快照哲学可以概括为一句话：系统更新与系统备份天然绑定。每次执行 Omarchy 更新流程时，系统都会在改动任何包之前先对根文件系统拍摄一张 Snapper "number" 类型快照，之后用户无论何时都可以从启动菜单把系统回滚到该快照点。

这套"先备份、后更新"的顺序在 docs/update-process.md 的更新流水线中处于显式位置：

omarchy-update
  ├─ ensure transcript logging ...
  ├─ omarchy-update-lock
  ├─ omarchy-update-requires-free-space
  ├─ confirm unless -y
  ├─ omarchy-update-pkg-prune            # 先裁剪 pacman 缓存
  ├─ create snapper snapshot             # 更新前创建快照
  ├─ omarchy-update-stay-awake start
  ├─ run package updates, migrations, hooks, and log analysis
  └─ ...

该文档同时说明了快照失败时的分级语义：未安装 Snapper 时更新静默跳过快照并继续；Snapper 已安装但未配置时快照会大声失败（报错指向 install/config/snapper.sh），然后更新继续。这保证更新路径永远可用，同时不让用户误以为"已成功备份"。

也就是说，在正常使用中你几乎不需要手动拍快照——每次通过 omarchy update 更新系统，机器就已经留下了一个可回滚的还原点。如果你需要自主创建额外快照，或手动触发恢复，则使用下面要讲的 omarchy-snapshot 命令。

手动创建与恢复：omarchy-snapshot 实战

omarchy-snapshot 是仓库中直接提供的用户命令（见 bin/omarchy-snapshot），用法与参数如下：

omarchy-snapshot <create|restore>

命令需要 sudo 权限（脚本头部声明了 omarchy:requires-sudo=true）。注意两点边界行为：

• 若系统未安装 Snapper（omarchy-cmd-missing snapper 为真），命令直接以退出码 127 结束——注释写明这一约定正是为了让 omarchy-update 在缺少 Snapper 时直接忽略快照步骤；
• 若 Snapper 已安装但没有任何快照配置（解析 sudo snapper --csvout list-configs 得到空列表），命令会以黄色警告提示"未找到 Snapper 配置，未创建快照"并退出 1，同时给出修复指引：执行仓库中的 install/config/snapper.sh 完成配置。这一设计刻意避免"静默成功"造成用户误以为已有备份。

create：为所有已配置的快照配置拍摄快照

omarchy-snapshot create 的实际执行逻辑（bin/omarchy-snapshot）分三步：

1. 通过 omarchy-version 读取当前 Omarchy 版本作为快照描述（读取失败则回退为 unknown）。由于描述只是标签，任何失败都不会中止快照拍摄；
2. 遍历系统中每个 Snapper 配置，依次执行 sudo snapper -c <config> create -c number -d "$DESC" 创建 number 类型快照；
3. 对每个配置执行 sudo snapper -c <config> cleanup number，按保留策略清理过期快照。

结束后会提示 "Snapshots can be selected during boot."，告诉你快照已经可以被启动菜单选中。

restore：调用底层恢复工具

omarchy-snapshot restore 的逻辑非常简短，本质是对外部工具的封装：

sudo limine-snapper-restore

它把恢复动作委托给 Limine Snapper 集成套件中的 limine-snapper-restore。因此，命令式恢复与"启动进快照后点通知恢复"走的是同一套底层恢复流程（见下文）。

Snapper 保留策略：根快照仅留 5 个，无时间线

Omarchy 出厂自带的 Snapper 配置模板是 default/snapper/root，其策略与"为更新回滚服务"的定位高度吻合：

# Omarchy snapshots root only for pre-update recovery — kept to 5, no timeline
SUBVOLUME="/"
FSTYPE="btrfs"

NUMBER_CLEANUP="yes"
NUMBER_MIN_AGE="0"
NUMBER_LIMIT="5"
NUMBER_LIMIT_IMPORTANT="5"

TIMELINE_CREATE="no"

配置项	值	含义
SUBVOLUME="/"	根子卷	快照仅覆盖根文件系统，不含 /home
FSTYPE="btrfs"	btrfs	快照依赖 Btrfs 子卷能力
NUMBER_LIMIT="5"	5	number 类型快照最多保留 5 个，超出即被 cleanup number 清理
NUMBER_CLEANUP="yes"	yes	允许按数量清理旧快照
TIMELINE_CREATE="no"	no	关闭时间线快照（定时自动快照），避免后台频繁占用磁盘

与模板配套的服务开关在 install/config/snapper.sh 中完成：禁用 snapper-timeline.timer，启用 snapper-cleanup.timer 与 limine-snapper-sync.service，并把 SNAPPER_CONFIGS="root" 写入 /etc/conf.d/snapper。也就是说，Omarchy 只保留"更新点回滚"所需的 number 快照，不鼓励无人看守的时间线快照。

从 Limine 启动菜单回滚系统

快照的价值只有在能"进去"和"出来"时才成立，而 Omarchy 的入口就是 Limine 启动加载器。

选择快照启动

重启后在 Limine 启动菜单中，进入 Snapshots 分组，会看到按日期时间命名的历史快照列表（例如 2025-08-22 22:01:04 这样的条目），选择要回滚的时间点即可启动到该快照。识别依据有两个：

• 快照条目名称中的日期时间；
• 快照创建时刻的 Omarchy 版本，显示在启动界面的左下角。

快照条目的生成与同步

启动菜单里的快照分组不是手工维护的静态配置，而是由 limine-snapper-sync 服务将 Snapper 快照同步进 Limine 条目而来。相关参数集中在 etc/limine-entry-tool.d/omarchy-defaults.conf：

CUSTOM_UKI_NAME="omarchy"
FIND_BOOTLOADERS=yes
BOOT_ORDER="*, *fallback, Snapshots"
MAX_SNAPSHOT_ENTRIES=6

其中 BOOT_ORDER="*, *fallback, Snapshots" 把 Snapshots 分组排在常规启动项与 fallback 之后；而 MAX_SNAPSHOT_ENTRIES=6 是一个有意思的工程细节——模板默认只保留 5 个 number 快照，但 limine-snapper-sync 有可能在 cleanup number 执行前恰好看到"第 6 个刚创建"的快照，若上限写死为 5 会产生 "Snapshot limit mismatch" 报错。放一个余量即避免了这个创建窗口期的误报。仓库测试 test/shell.d/snapper-test.sh 对此有专门断言（校验 NUMBER_LIMIT="5"、TIMELINE_CREATE="no" 与 MAX_SNAPSHOT_ENTRIES=6 的配套关系）。

进入快照并触发恢复

当你从启动菜单选好快照并进入系统后，桌面会弹出通知，告知你"当前正处于某个可启动快照中"；点击该通知即会启动恢复流程。如果你没有图形界面操作条件，也可以直接执行命令：

omarchy-snapshot restore

恢复的边界：只还原系统，不碰 /home

理解这套快照机制的能力边界非常关键。恢复动作会还原根文件系统（SUBVOLUME="/"），但不会还原 /home。由此可以推导出两条清晰的适用边界：

• 适用场景：回滚一次坏掉的系统更新——例如新版本内核、驱动或桌面组件导致无法启动或无法进入桌面；
• 不适用场景：找回误删的个人文件——/home 下的数据不在快照覆盖范围内。

同样需要留意的连带效应是：~/.config 目录位于 /home 下，因此恢复快照时你当前的配置会被原样保留。文档明确提示了这一风险：如果你回滚的是某个"库或应用的新版本"（该版本可能已经把配置文件写成了新格式），而旧版本无法理解新格式配置，那么你需要手动处理这些配置兼容问题，系统不会替你回滚 /home 中的配置。

可用性前提：仅限 Limine 安装

快照选择与恢复能力只对使用 Limine 启动加载器的安装可用——Limine 自 Omarchy 2.0 起是默认启动器。如果你处于 GRUB 或 systemd-boot 环境，则无法使用这套机制。仓库的 limine 相关配置（默认菜单外观见 default/limine/limine.conf，快照分组与同步参数见上文）都是围绕 Limine + Snapper 集成设计的，这解释了为何该能力无法在其他启动器上平移。

在故障排查流程中，快照回滚被当作第一优先级手段：manual/45-troubleshooting.md 建议先回滚到最近更新前的版本，失败后再考虑 omarchy-debug 上报与 omarchy-reinstall 重装默认配置。在 manual/30-updates.md 中也有对应提示：直接使用 pacman -Syu 会绕过 Omarchy 的快照、迁移等配套流程，因此 Omarchy 会拦截裸跑的系统升级并引导用户回到 omarchy update。

Skipping the boot menu：Direct Boot 直启模式

如果你从不使用启动菜单，希望开机直接进入 Omarchy 解密屏（LUKS 密码界面），可以在 Omarchy 菜单中运行 Setup > Direct Boot。这一菜单项在 default/omarchy/omarchy-menu.jsonc 中有明确定义：

"setup.direct-boot": {"icon":"","label":"Direct Boot","action":"omarchy-launch-floating-terminal-with-presentation omarchy-setup-direct-boot"}

其作用机制是：新增一条直接指向 Omarchy 的 EFI 启动项，使固件直接启动 Omarchy 而不再停留在 Limine 界面。

但直启模式与快照回滚存在固有取舍，文档明确了两点代价：

1. 开启 Direct Boot 后，需要进入快照回滚时，你必须先进入 BIOS 启动菜单手动选择 Limine，才能看到快照列表；
2. 再次运行 Setup > Direct Boot 会移除该 EFI 条目，恢复为经 Limine 引导的方式。

此外，某些固件对自定义 EFI 条目不友好，因此该设置在 American Megatrends（AMI）与 Apple 固件上会被拒绝执行——如果你在这类硬件上找不到 Direct Boot 选项，这不是故障，而是刻意的能力限制。

运维视角：保留策略调优与迁移收敛

对想进一步定制快照策略的读者，仓库给出的运维线索如下：

• 调保留数量：编辑 /etc/snapper/configs/root（出厂模板即 default/snapper/root），修改 NUMBER_LIMIT / NUMBER_LIMIT_IMPORTANT。调大意味着可回滚点更多、磁盘占用更高；cleanup number 由启用的 snapper-cleanup.timer 定期执行。同时记得 limine-snapper-sync 的上限参数 MAX_SNAPSHOT_ENTRIES 需与保留数量留有创建窗口余量，否则会出现快照条目与保留策略不一致的告警。
• 迁移收敛：仓库的迁移（migrations）与测试持续"纠正"快照相关配置，例如 test/shell.d/snapper-test.sh 验证了 Snapper 服务迁移只在服务损坏时幂等地修复，且不会覆盖用户自定义的保留数量；安装 ISO 侧也不重复配置 Snapper，统一委托给打包好的系统设置脚本执行。仓库还包含 test/shell.d/snapshot-create-test.sh、test/shell.d/snapper-timeline-leak-test.sh 等针对快照创建与时间线清理的专项测试，可作为理解与回归验证该机制的入口。
• 手动重装配置：若 Snapper 配置丢失或损坏，可随时重新执行 sudo bash -euo pipefail install/config/snapper.sh（见 bin/omarchy-snapshot 报错给出的指引），它会重建 /etc/snapper/configs/root、写入 /etc/conf.d/snapper 并纠正相关服务状态。

综合来看，Omarchy 的快照方案是一套"小而专"的更新保护机制：只在更新点拍摄根文件系统快照、默认保留 5 份、经由 Limine 启动菜单完成选择与恢复、明确不覆盖 /home。它解决的是"系统更新坏了如何快速回到上一个可用状态"这一高发问题，而不是通用备份方案——理解这一点，才能正确地把快照回滚纳入自己的故障恢复流程。