Omarchy updates, backups and recovery: a maintenance guide

Maintenance is a connected workflow: protect what matters, make one change, check the tasks that depend on it, and keep enough information to recover. Updating packages, restoring a system snapshot and recovering a project file solve different problems.

This chapter helps you choose the right operation before following its detailed procedure. For current upstream behavior, consult official updates and system snapshots. The linked guides explain scenarios, evidence and restoration boundaries.

Choose the operation by its purpose

You need to…	Read	What completion means
Apply a routine system update	Updating Omarchy	Update completes and your ordinary tasks still work
Create/check a bootable system recovery point	System snapshots	Coverage, listed recovery point and a known route into Limine
Recover after an update fails	Update recovery	A working state and evidence of the original failure
Recover files or prepare for disk loss	Backups and recovery	A usable separate copy, with a demonstrated restore
Preserve a personal desktop adjustment	Configuration maintenance	The intended change survives without discarding useful new defaults
Diagnose a failure before the desktop starts	Installation and boot troubleshooting	The failing boot stage is identified

If just one application misbehaves, begin with that application’s symptom and recent change. A full rollback may replace unrelated software while leaving the configuration that caused the problem untouched.

Protect three different kinds of state

System state includes the operating environment needed to boot and run applications. A configured snapshot workflow may offer an earlier system state. Its coverage depends on the filesystem and integration used by your installation.

Personal files include documents, projects, photos and other work. Keep a separate backup destination and test reading or restoring from it. A local snapshot shares the original disk’s failure risk. Ordinary synchronization can also propagate deletion; check what history your service retains.

Personal configuration records how you use the system. Save earlier copies of files you change and the reasons for the edits. A file that is syntactically valid can still conflict with a newer application or bypass a changed default.

In the official snapshot workflow covered by our backup guide, system restoration preserves /home. That is valuable for current work, but it also means a system rollback can leave newer personal configuration in place. Do not assume every file returns to the same date.

A repeatable update routine

1. Prepare: save work, provide reliable power, check that the backup you need is usable, and record your version and channel.
2. Review: read relevant release notes, especially when changing major versions or configuration generations. Channel changes deserve their own decision.
3. Update: use the Omarchy update workflow rather than treating an isolated package upgrade as the same operation.
4. Follow completion instructions: note any required restart before judging the result.
5. Repeat ordinary tasks: open a website, type in your usual apps, check audio and displays, and try one customized action.
6. Record the result: if a task fails, preserve the first useful error and stop adding unrelated adjustments until you have a diagnostic direction.

An update finishing without an error is one milestone; your actual workflow still working is another. Choose checks that reflect your own use instead of collecting an enormous generic checklist.

A recovery decision tree

Can you reach the desktop or a usable console? If yes, save relevant errors and inspect the specific failure before selecting recovery. If not, use the boot-stage guide and the snapshot instructions appropriate to your installed bootloader and snapshot configuration.

Did one personal edit trigger the symptom? Restore that file and any separate toggle first. Use configuration loading to understand which file is actually read. Replacing an inactive file cannot fix the active setting.

Did the system fail after an update? Follow update recovery, keeping the pre-update version, failure stage and logs. A snapshot entry existing in a boot menu does not itself demonstrate that a complete restoration has succeeded.

Is a document missing? Look at file backup, version history or sync trash first. A system snapshot restore is not the documented personal-file recovery method in the workflow described here.

Rehearse before an emergency

Use the harmless file exercise in backups and recovery to restore into a new location and compare the result. Confirm that you can access your backup destination and any credentials needed for it from outside the affected computer. Keep the recovery notes somewhere other than only on its disk.

For configuration, change a small setting, verify it, and restore the earlier copy. This proves the recovery path you will later rely on and exposes missing details while the system is still usable.

After recovery: keep the useful evidence

Record what failed, what you restored, what remained unchanged and which tasks now work. If you restored a system snapshot, check relevant personal settings separately. If you removed a custom override, record why so that the same incompatible setting does not reappear during synchronization.

The storage layer explains the component roles; getting help helps turn the incident into a clear report. Recovery is complete when the intended state is usable and your work is accessible, not merely when a command reports success.