Backups and recovery: saving your system, files, and configuration

An updated package, yesterday’s project file, and your custom shortcut need different recovery methods. This guide separates those boundaries, walks through a restore without overwriting your work, and explains recovery decisions after a failed system update.

The scenarios and filenames are teaching examples. The snapshot workflow is checked against the official guide, not tested on your hardware. Confirm that your installation has Limine and configured snapshot integration before depending on it.

1. What are you trying to recover?

What happened	First recovery source	Reason
System or desktop failure after an update	A bootable snapshot from before the update	You need a working system state
A document, photo, or project was deleted or damaged	A separate file backup or version history	Official system restoration preserves /home
A shortcut or application setting was broken	The earlier copy of that configuration file	Undo one change without replacing unrelated settings
The system disk failed or the laptop was lost	A backup on another device or remote destination	Local snapshots may disappear with the originals

Booting an older system and recovering yesterday’s file are separate capabilities. Choose the target before deciding whether recovery succeeded.

2. How snapshots, backups, and sync work together

In the installation covered here, Btrfs provides filesystem snapshots, Snapper manages them, and Limine plus restoration tools provide boot and restore entry points. Separate file backups protect your work. See the storage and maintenance layer.

Snapshots share data blocks to preserve a point in time without immediately copying everything. Sharing the disk also means they cannot protect against its failure; retained changes consume additional space. Btrfs snapshot documentation

Method	Good at	Does not by itself guarantee
System snapshots	Recovering covered system state	Personal file recovery or offsite storage
Versioned file backups	Recovering deleted or changed files	Repairing the boot chain
Ordinary sync	Keeping current files on multiple devices	An older copy if deletions also propagate
Git	Recovering committed project or config versions	Uncommitted work, ignored files, or live database state

Check sync history and trash, and whether uncommitted files, uploaded assets, databases, and keys enter backups. A Git repository alone does not prove everything is recoverable.

3. What remains after system rollback?

The official workflow rolls back the root filesystem while preserving home directories. Here is an illustrative timeline:

Time	System software	Home directory files and configuration
Before updating	Older application	Older config and work in progress
After updating	Newer application	Possibly migrated config and more project edits
After restoring the earlier system snapshot	Older application again	Latest project work and newer config remain

That preserves work but may leave an older application reading newer settings. Rollback does not return every file to the same date. Actual coverage depends on subvolume and snapshot configuration; customized installations should inspect their layout.

4. Rehearse a file restore first

This creates test files and saves a copy inside your home directory. It teaches restoration; it is not protection against disk failure.

If these directories contain an earlier exercise, use a new practice directory. printf overwrites the test filename: do not substitute a real project file.

mkdir -p ~/recovery-practice/source ~/recovery-practice/backup ~/recovery-practice/restored
printf 'Recovery practice version 1\n' > ~/recovery-practice/source/note.txt
cp -i ~/recovery-practice/source/note.txt ~/recovery-practice/backup/note.txt

cp -i asks before replacing an existing destination; decide whether you still need it. Change only the working copy, then restore into a third location:

printf 'Recovery practice version 2\n' > ~/recovery-practice/source/note.txt
cp -i ~/recovery-practice/backup/note.txt ~/recovery-practice/restored/note.txt
cat ~/recovery-practice/source/note.txt
cat ~/recovery-practice/restored/note.txt

Expected: the working file says version 2; the restored one says version 1. You recovered historical content without overwriting current work.

sha256sum ~/recovery-practice/backup/note.txt ~/recovery-practice/restored/note.txt

Matching hashes show that these two files have identical bytes. They do not prove the entire backup is complete or replace opening documents, running projects, and checking assets. Restore real files into a separate directory too, inspect them, and only then decide whether to replace originals. Copy command reference

5. Prepare a real backup

List projects, documents, assets, changed configuration, an application list, and application data. Data may live in ~/.local/share or elsewhere; saving ~/.config alone does not save all application data.

Preparation	Verification
Save backups on another disk or remote destination	Locate and read them without the original computer
Retain historical versions	Select a version from before a file was damaged
Include large files and hidden directories	Inspect records and restore a representative file
Keep passwords and encryption keys available	Unlock backups in recovery; keys must not exist only on the original computer
Recover databases and application data consistently	Use application exports or follow backup instructions with the application stopped

A running database may need a consistent export. Copying changing files does not guarantee a usable database. Restore one real, low-risk document into a new directory and record success before expanding coverage.

6. Scenario: the desktop fails after an update

Record where failure occurs. If the desktop still works but the update transaction reports an error, start with update failure diagnosis. Not every installation error calls for rollback.

For boot failure after updating an installation with official Limine snapshot integration:

1. Restart and reach Limine. With Direct Boot enabled, first choose Limine in the firmware boot menu if necessary; the key varies by manufacturer.
2. Choose a snapshot dated before the failed update, checking its version. The first entry is not automatically correct.
3. Confirm that you entered the snapshot environment and observe the failing boot or desktop function. A successful boot makes this recovery point worth examining.
4. When you decide to restore, use the restoration notification or documented omarchy-snapshot restore, reading its prompts. This changes system state; it is not an inspection command.
5. Follow completion or reboot instructions. After normal boot, check the desktop, networking, the failing application, and your latest files.

The official command for making a manual recovery point beforehand is:

omarchy-snapshot create

It creates snapshots and may request administrator authorization. Running it is not proof that a recovery point exists: inspect errors and confirm a dated snapshot appears in a usable boot entry. This source reports failure when no Snapper configurations exist; installing Snapper alone does not complete integration. Snapshot implementation

If no snapshot is available, you use another loader, or firmware cannot find the system, follow recovery documentation for your installation. Do not reinstall the bootloader just to match this tutorial.

7. Scenario: rollback worked, but one application still fails

Check whether it migrated its config or data format. These steps apply to an identified individual configuration file:

1. Quit the application and record errors and versions before and after rollback.
2. Save the present configuration separately; newer settings may still be valuable.
3. Compare a pre-update copy and restore only the affected application’s necessary files.
4. Start it and test the original failure plus a normal function. Without a reliable older copy, follow its documentation to test separate or fresh settings; do not delete all of ~/.config.

Database migrations require separate consideration. Do not combine older settings with newer databases indiscriminately. Check the application’s recovery compatibility guidance: a bootable system does not prove all application data supports downgrade.

8. Keep a usable recovery record

Record backup locations, the date and files of a successful restore, the snapshot entry point, and important config copies. Verify the original failure is gone, investigate its cause, then decide whether to update again.

Continue with your first configuration change, updating Omarchy, and storage components.

Sources and scope

Reviewed on 2026-10-12: Omarchy snapshots, updates, the pinned snapshot implementation, and Btrfs subvolumes. The exercises and recovery scenarios are original teaching examples, not hardware test reports.