Prevent unexpected power loss
The most direct way to avoid corruption is to ensure the Raspberry Pi receives stable power and shuts down cleanly when power fails. An uninterruptible power supply can switch to battery and signal the system to begin a graceful shutdown before the battery is exhausted.
When a clean shutdown is not possible, the remaining defenses center on file system configuration and reduced write activity. Official Raspberry Pi documentation notes that proper shutdown procedures make local storage extremely reliable under normal conditions.
- Use a UPS that notifies the Pi of impending power loss so a controlled shutdown can complete.
- Avoid running the Pi from marginal power supplies that drop voltage under load.
Maintain sufficient free space
Running out of space during an update or write operation can leave the file system in an inconsistent state. Before running apt full-upgrade or other large operations, check available space with df -h and free up room if needed by removing unnecessary packages or old logs.
Raspberry Pi OS recommends at least 8 GB for Lite images and 32 GB for desktop images. Keeping a margin beyond these minimums reduces the chance that an interrupted write will exhaust the remaining blocks.
- Run df -h before major updates to confirm adequate free space.
- Remove unused packages and old kernel images regularly.
Control system logging
Excessive logging increases the number of writes that can be interrupted by a power event and shortens the life of flash storage. Raspberry Pi OS provides raspi-config options to change logging behavior.
The available modes include default, volatile (logs stored only in RAM and cleared on reboot), persistent (logs written to disk), auto, and none. Volatile logging eliminates writes to permanent storage for routine log data while still allowing temporary inspection of recent events.
- Open raspi-config and select Advanced Options > Logging to choose volatile mode when logs do not need to survive reboots.
- For troubleshooting over longer periods, switch to persistent mode only when required and monitor disk usage.
Choose journaling modes and mount options
Most file systems used on Raspberry Pi, including ext4, employ journaling to keep metadata consistent after an unclean shutdown. The default data=ordered mode journals metadata and ensures file data reaches storage before the metadata that references it. This offers a practical balance between safety and performance.
The data=journal mode journals both metadata and file data but roughly doubles the amount of data written. The data=writeback mode is faster yet can expose stale data after a crash. For a dedicated data partition, data=ordered with metadata_csum enabled and a reasonable commit interval is recommended.
- Mount the root file system with data=ordered (the default) unless specific performance requirements dictate otherwise.
- Place persistent application data on a small separate partition and apply the same journaling and commit tuning to that partition alone.
Use read-only root file systems and tmpfs
Mounting the root file system read-only eliminates almost all writes to the primary storage device. When application data must still be retained, a small read-write partition or external USB drive can be used for that purpose. Overlayfs or a native read-only image such as SquashFS combined with an overlay provides another route to the same goal.
Temporary data that does not need to survive a reboot can be placed on tmpfs, which resides in RAM and therefore cannot be corrupted by power loss or contribute to flash wear.
- Bind-mount writable directories from a small data partition into the read-only root when needed.
- Configure tmpfs mounts for /tmp, /var/tmp, and other transient directories in /etc/fstab.
Back up data and protect the boot partition
Even with the precautions above, storage can still fail. Regular backups of important data and configuration files are essential. External USB storage or network locations provide an off-device copy that survives SD card or eMMC failure.
The /boot partition should receive the same protection as the root file system. Read-only mounting or careful write reduction applies there as well. When possible, boot from network storage to remove the SD card from the write path entirely.
- Schedule periodic rsync or tar backups of user data and configuration to external or network storage.
- Verify backups by performing test restores before relying on them.