Omarchy snapshots: create a recovery point and restore the system

A system snapshot is useful when an update breaks covered system state. It is not the right recovery source for a deleted project file, a lost laptop or a failed system disk. The official snapshot guide describes the Limine restore workflow and preservation of /home. This page adds preparation, coverage inspection, failure-stage decisions and post-restore checks.

Follow the chain of responsibilities

Btrfs preserves a subvolume's point-in-time state
  → Snapper manages named configurations and snapshots
  → boot integration exposes suitable recovery entries in Limine
  → restoration tool makes a chosen system state the normal system

These are separate capabilities. A snapshot appearing in Snapper does not by itself prove a boot entry is available. Booting a snapshot to inspect it is not the same as completing a restore. The documented workflow here depends on configured Limine integration; do not substitute generic GRUB instructions or snapper rollback from another distribution.

Know what will and will not return to an earlier date

State	Default workflow’s intended boundary	Consequence
Covered root system	Earlier state can be restored	Packages/system settings may return to the earlier version
/home documents and personal configs	Preserved in the official workflow	Your latest work remains; a broken new personal config can remain too
Separate/nested subvolumes	Depends on their own configuration	Do not assume a parent snapshot includes them recursively
Data on another disk, remote service or mounted share	Outside an ordinary local root snapshot	Needs its own recovery method
Disk lost or physically failed	Local snapshots may be lost with it	Independent file backups still matter

The Btrfs subvolume documentation explains snapshot boundaries and shared data. Customized installations may have additional Snapper configurations; inspect yours rather than treating this default boundary as universal.

An illustrative update sequence shows a common trap:

before update: system A + personal config A
after update:  system B + migrated personal config B
after restore: system A + personal config B

The final combination can fail even when restoration succeeded. Keep personal configuration copies alongside your file backup. Do not respond by deleting all of .config.

Inspect prerequisites while the system still works

Run these inspections before depending on automatic recovery:

findmnt -no FSTYPE,SOURCE,OPTIONS /
findmnt /home
sudo snapper list-configs

The root should match the intended filesystem setup. Read the configuration names and subvolume paths. If the configuration covering / is named root, list it with:

sudo snapper -c root list

If it has another name, substitute that actual name. findmnt /home may report no separate mount when home is not mounted independently; that is a reason to inspect layout, not proof of snapshot coverage. The Snapper manual documents these inspection commands.

Check that you can deliberately reach the Limine menu during startup. With Direct Boot, the official guide describes choosing Limine through firmware first; some firmware has limitations. Establish your machine’s route while you can still search documentation, not during a failed update.

Create a manual recovery point and confirm it exists

Save work and identify the covering configuration, then use the documented action:

omarchy-snapshot create

This creates system snapshots; it changes local snapshot state and can prompt for administrator authorization. The pinned helper enumerates configured Snapper configurations, creates a numbered snapshot for each and invokes numbered cleanup. It reports an error if no configurations exist. An installed Snapper executable alone is insufficient.

List the covering configuration again and record the new number, date and description. Compare that with the boot entries at your next planned reboot. A command’s pleasant-looking output is not stronger evidence than an actual listed recovery point. Do not delete older known-working snapshots merely because a new number appeared.

The official update integration creates snapshots automatically, but verify that your installation uses that integration. An update performed through another path or a failed/unconfigured snapshot step may not provide the point you expect.

Restore after a failure, one boundary at a time

1. Establish whether firmware can reach Limine. If it cannot, an available root snapshot is not yet a solution to that earlier boot-chain failure.
2. Open the snapshot entries and choose one before the failing change, using date and version, not just the first entry.
3. Boot that environment and check whether the failing function works. Avoid unnecessary writes while deciding which recovery point to use.
4. If that is the state you intend to restore, use the documented restoration notification or omarchy-snapshot restore, read the tool’s prompts, and follow its completion/reboot instructions. This is a system-changing action, not a preview command.
5. Boot normally and verify the desktop, network, package/application version involved in the failure and your latest files.

If the older environment boots but the same personal application error remains, compare the retained home configuration. Restore the smallest relevant personal file from a known copy. If no usable snapshot exists, keep logs and follow update recovery; repeated restore attempts do not create a missing recovery point.

Space and retention need attention

A snapshot initially shares blocks; subsequent writes and retained old blocks consume space. Ordinary directory sizes cannot be added up as if every snapshot were an independent full copy. Inspect overall use:

df -h /
sudo btrfs filesystem usage /

The second applies only to a Btrfs filesystem; it provides data/metadata allocation information described in the Btrfs manual. This is inspection, not a recommendation to run balance or defragmentation as a generic cleanup.

Use Snapper’s configured retention/cleanup mechanisms for managed snapshots, after identifying what must remain. Do not remove .snapshots with a file-manager delete or a broad recursive command. If space is critically low, avoid a large update until you have identified the cause and retained a recovery path.

A practical readiness record

Keep the covering configuration/path, known recovery number/date, route into Limine, file-backup destination and personal config copies. During a planned maintenance window, checking that a recovery entry boots is stronger evidence than merely knowing snapshots exist; it still does not require performing a destructive rollback rehearsal.

For deleted files and disk loss, continue with backups. For the components behind the workflow, see storage and maintenance. The intended result is a recovery method whose boundaries you can explain before you need it.