Raspberry Pi Overlay File System: A Read-Only Root That Survives Power Cuts

Why a read-only root is worth considering

SD cards have a finite number of write cycles, and a power cut during a write can leave the filesystem inconsistent. An always-on Raspberry Pi — a sensor gateway, a signage box, a kiosk — writes constantly: logs, state files, package metadata. The Overlay File System, exposed in raspi-config on Raspberry Pi OS, addresses both problems at once. It makes the root filesystem read-only and layers a writable overlay in RAM on top, so runtime writes land in memory and disappear at reboot.

The thesis: for appliances where nothing on the root filesystem needs to survive a reboot, the overlay is a supported, low-effort way to cut write traffic and shrink the blast radius of an unclean shutdown. It is not free, and it is not a substitute for knowing where your data actually lives.

What the overlay actually changes

Two things happen. The root filesystem is mounted read-only, and a writable layer backed by RAM is stacked on top. Reads fall through to the real filesystem; writes go to the overlay. On reboot the overlay is discarded and you are back to the image as it was.

Two consequences follow directly:

• Anything that must persist has to live somewhere else — a separate writable partition, a USB or NVMe device, or a network store.
• The boot partition is not covered. It normally stays writable, so firmware and boot configuration remain exposed.

A worked example: enable, verify, and prove the persistence cost

Run these on the Pi itself, over SSH or at the console, as a user with sudo. Menu wording and option placement differ between Raspberry Pi OS releases, so read the menu on your installed image rather than trusting a screenshot.

1. Open the configuration tool: sudo raspi-config
2. Navigate to Performance Options and select the Overlay File System entry. Confirm when prompted.
3. Reboot: sudo reboot

After the reboot, check how the root filesystem is mounted:

findmnt -no OPTIONS /
mount | grep ' / '

Expect the options for / to include ro. If you still see rw, the overlay is not active — reopen raspi-config and re-check the setting.

Now demonstrate the trade-off in one loop. Create a marker file in a root-owned directory, reboot, and look for it:

sudo touch /root/overlay-marker
sudo reboot
# after the reboot
ls -l /root/overlay-marker

The file should be gone. That is the protection working: a process that scribbles on the root filesystem cannot corrupt it permanently. It is also the cost — anything you expected to keep is gone too.

To confirm the mechanism rather than the symptom, disable the overlay in raspi-config, reboot, repeat the marker test, and observe that the file persists. Re-enable it when you are done.

What breaks, and how to keep it working

Software that assumes it can write under / or /var will fail or silently lose data. Common offenders:

• Package managers — apt upgrades and kernel or firmware updates need a writable root. Disable the overlay, update, re-enable.
• Databases and container runtimes — point their data directories at a persistent volume, not the overlay.
• Log collectors and daemons — redirect to a tmpfs mount if the logs are disposable, or to external storage if they are not.

A practical pattern is to keep the root read-only and mount one small writable partition for the handful of paths that genuinely need persistence. That gets most of the wear reduction without fighting every service.

Limitations and alternatives

The overlay is risk reduction, not immunity. It does not make the boot partition read-only, and it does not eliminate every power-loss failure mode. Because the writable layer lives in RAM, sustained writes consume memory until the next reboot — a chatty service can quietly fill it.

Alternatives that address the same failure mode, and can be combined with the overlay:

• High-endurance SD cards, which tolerate more write cycles.
• Booting from USB or NVMe storage, which is generally more robust and faster than SD.
• Moving volatile logs to tmpfs, which removes write traffic without a read-only root.

Checking the result on your own board

Before deploying, verify three things on the actual image and workload:

1. The root mount options include ro while the overlay is active.
2. A file written to a root-owned path disappears after a reboot.
3. Every service you depend on still starts and still writes its data where you intended.

If you plan to script this across a fleet, raspi-config has a non-interactive mode, but subcommand names are not stable across releases. Check the help output on the installed image before committing it to a provisioning script, and cross-check the official Raspberry Pi documentation for that OS release.