NixOS persistence: what must survive

An impermanent root starts clean after each boot. That can make a system easier to reason about, but only when you decide exactly what must survive. Encryption solves a different problem: protecting data at rest. Combining the two is useful; confusing them is how installations become unbootable.

1. Draw the persistence boundary

Write down every path that must survive a reboot before changing partitions. A useful first pass includes /nix, system configuration, user data, SSH host keys, databases, and service state. The NixOS manual specifically calls out persistent system state such as /var/lib/nixos. Treat the list as a living inventory: every new service adds new state.

This is a review worksheet, not a mount configuration. The exact paths and encryption boundary depend on your system; keep a tested backup before changing either.

Do not assume that a tmpfs root encrypts anything. Memory contents, swap policy, hibernation and persistent files have separate security properties. Decide which threat you are addressing and document the answer.

2. Separate the boot chain from the data store

For a typical design, firmware reaches a boot partition, the early boot environment unlocks LUKS, and NixOS mounts the persistent store before bringing up services. The exact device identifiers and filesystem layout depend on the machine. Use stable identifiers, verify the intended disk twice and keep a recovery medium nearby.

Encryption at rest does not by itself verify an unencrypted boot partition. If physical tampering matters to your threat model, research secure boot and measured boot before treating this as a complete defense.

3. Test recovery before relying on ephemerality

1. Make and verify a restorable backup of the existing configuration and data.
2. Record the unlock and recovery procedure somewhere outside the machine.
3. Test that the boot environment can see the encrypted volume and that the passphrase works.
4. Reboot once with a minimal persistence set, then confirm expected files survived and temporary files did not.
5. Reboot again after enabling each stateful service; inspect logs, identities and permissions.

What this article deliberately leaves to your machine

Partition names, UUIDs, cryptsetup arguments and NixOS option names must be checked against the current release and your hardware. The historical guide on this domain described one implementation; copying its commands onto another disk is unsafe. Use this map to review a machine-specific plan, then test it on disposable hardware or a virtual machine.

What actually needs to persist?

Do not begin with a copied list of directories. Begin with the consequences of losing each path. A boot path, an identity and an application database fail in different ways; each needs a different recovery test.

A persistence worksheet to fill before changing a host

Configuration: Is the machine definition in version control or on persistent storage? Record how a new host would obtain it. Identity: Record which SSH host keys, machine identity files or service credentials must remain stable. Never put private keys into a public repository. Application state: Locate databases, uploads, queues and certificates created at runtime. Operations: Decide whether logs, timers and caches are necessary for recovery or can be regenerated.

For each item write: path, owning service, reason to persist, sensitivity, backup, restore command or procedure, and observable check after reboot. Treat an absent answer as a blocker for the migration. The official NixOS Wiki lists examples such as /var/lib/nixos and /etc/machine-id, but marks its Impermanence article as outdated; option behavior must be checked against the release you use.

The two-reboot acceptance procedure

1. On a disposable VM or spare machine, take a verified backup and record baseline identities, service state and mount points. Do not experiment first on the only production copy.
2. Apply the candidate persistence configuration. After the first reboot, confirm the encrypted store unlocks, the expected paths exist with correct owners, and a deliberately temporary marker has disappeared.
3. Create one new piece of legitimate state in each enabled service, such as a harmless test record. After the second reboot, verify the new state remains and the service uses the same identity. Inspect logs for failed mounts and permission errors.
4. Restore the backup into a separate disposable environment and compare the recovered state to the expected inventory. A successful boot alone does not prove recoverability.

Test status: This is a procedure and worksheet, not a report of a VM run. No machine-specific partitioning or two-reboot result is claimed here. The article was checked against the current official NixOS Wiki and stable manual on 30 September 2026; verify your own release and hardware before applying commands.

Continue with the NixOS trade-offs field note and our editorial method.