Start a live Linux session and you get a complete desktop running from removable media. Install a package, change the wallpaper, save a document — and at the next reboot, all of it is gone. That is not a fault. It is how the arrangement is built, and understanding why explains how to change it.
Why a live session forgets
The system files in a live image live in a compressed, read-only archive, usually squashfs. Read-only is deliberate: it keeps the image small, makes it verifiable, and means the session always starts from a known state.
But a running system needs to write — logs, temporary files, configuration. So the boot process stacks a writable layer over the read-only one using an overlay file system. Reads come from the archive unless the writable layer has a newer version; writes always go to the writable layer. By default that layer lives in RAM, which is why it vanishes when power is removed.
What persistence changes
Persistence replaces the RAM-backed writable layer with a file or partition on the drive. The stacking is identical; only the storage underneath is different. Changes accumulate in that file and are still there next time.
Persistence does not make the image writable. It gives the overlay somewhere durable to live.
What ends up stored
- Your home directory: documents, downloads, application settings.
- Packages installed during the session, and their configuration.
- Network profiles, including saved wireless credentials.
- System-level configuration changes.
- Logs, caches and other routine background writes.
That last item is the one people forget. A persistence file fills up over time even if you never save anything yourself.
Sizing the overlay
| Use | Reasonable size | Notes |
|---|---|---|
| Settings and a few documents | 2–4 GB | Comfortable for a portable desktop |
| Extra applications installed | 8–16 GB | Package caches consume more than expected |
| Development or lab work | 32 GB and up | Toolchains and container images are large |
Overlay files are usually created at a fixed size and are awkward to grow afterwards, so err upward at creation time. The file occupies its full size on the drive whether or not it is full, which is the price of the arrangement.
Distribution differences
The mechanism is common; the details are not. Debian-derived images look for a partition or file labelled in a particular way and want a specific configuration file inside it. Fedora-derived images use their own naming. Some distributions do not support persistence at all, and a few implement it in an entirely bespoke way.
Multiboot loaders that support persistence generally do so by mapping an overlay file to the image at boot and passing the kernel parameters that distribution expects. That means support is per-distribution, and the loader's documentation is the place to check before you assume it will work.
Where persistence is the wrong tool
Three situations argue for a full installation instead:
- Daily use. Overlay lookups add overhead on every read, and flash endurance is finite. A system you use every day belongs on a drive prepared for that job.
- Anything that must not be lost. An overlay file is one file on one removable device. It is not a backup strategy and it is not resilient.
- Major system upgrades. Upgrading across releases inside an overlay is a reliable way to produce a session that no longer starts.
Persistence suits the middle ground: a portable environment you use occasionally, configured the way you like it, that you would be mildly annoyed rather than devastated to lose.
Handling credentials
A persistent session stores wireless passwords, browser sessions and anything you save, on a device small enough to leave in a taxi. If the environment holds anything sensitive, the persistence file should be encrypted — several distributions support this directly at creation time — and the rest of the drive should be treated as public.