Raspberry Pi SD Card Wear Reduction Guide¶

Reducing unnecessary writes can improve the reliability of a Raspberry Pi appliance, but disabling logs and filesystem safeguards creates new failure modes. First identify what writes, then apply the smallest reversible change. Use a read-only root only when the device is designed to discard changes after reboot.

Choose the right method¶

Situation	Recommended first step	Persistence
Ordinary server with growing logs	Set journal and application rotation limits	Logs retained within limits
Temporary cache or generated files	Put only that directory on `tmpfs`	Lost at reboot
Database writes heavily	Tune the application or move data to suitable storage	Retained
Kiosk should reset after reboot	Enable supported Raspberry Pi OS OverlayFS	Root changes discarded
Critical data must survive media failure	Back up to another device/location	Retained independently

OverlayFS, ZRAM, and tmpfs solve different problems. ZRAM compresses memory pages for swap; tmpfs stores files in memory; OverlayFS presents a read-only lower layer with a temporary writable upper layer.

Find the source of writes¶

Check filesystem usage and mounted devices:

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT

Install and run iotop during the real workload:

sudo apt update
sudo apt install iotop
sudo iotop -oPa

Inspect journal size and the largest log directories:

journalctl --disk-usage
sudo du -xhd1 /var/log | sort -h
sudo du -xhd1 /var/lib | sort -h

For a longer before-and-after comparison, read the kernel block counters for the root device. Resolve the actual parent device first; do not copy a hard-coded mmcblk0 name to USB or NVMe systems:

findmnt -no SOURCE /
lsblk -o NAME,PKNAME,TYPE,SIZE,MOUNTPOINTS
cat /sys/block/mmcblk0/stat

The block stat fields are cumulative and device-specific. Save the raw line before and after a fixed workload, and document the kernel sector size before converting it to bytes. iotop is easier when the goal is identifying the responsible process.

Limit systemd journal growth¶

Keep useful diagnostics while placing a ceiling on persistent storage. Create a drop-in file:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/20-size-limit.conf

Example:

[Journal]
SystemMaxUse=200M
SystemKeepFree=500M
MaxRetentionSec=14day
Compress=yes

Apply and verify:

sudo systemctl restart systemd-journald
journalctl --disk-usage
journalctl --verify

Choose limits for the device and incident-response needs. A remote production system may need more history than a supervised kiosk.

Vacuuming can reduce existing journal data, but it is destructive. Review the date range first and keep logs required for an active investigation:

journalctl --list-boots
sudo journalctl --vacuum-time=14d

Configure application log rotation¶

Check whether the application already writes to journald. Avoid duplicating the same output in journald and a text file.

For a text log such as /var/log/my-app/app.log, create /etc/logrotate.d/my-app:

/var/log/my-app/*.log {
    daily
    rotate 7
    size 10M
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

copytruncate can lose a small amount of log data during rotation. Prefer an application that reopens its log after a signal when available. Test the rule first:

sudo logrotate --debug /etc/logrotate.d/my-app

Use `tmpfs` for genuinely disposable files¶

Measure the directory's peak size before putting it in RAM. A bounded example for an application cache is:

1	`tmpfs /var/cache/my-app tmpfs rw,nosuid,nodev,noexec,size=128M,mode=0750 0 0`

Create the directory and test the mount before rebooting:

sudo install -d -m 0750 /var/cache/my-app
sudo mount /var/cache/my-app
findmnt /var/cache/my-app

Do not place databases, SSH host keys, machine identity, package state, or required application configuration on tmpfs.

Enable a read-only root with Raspberry Pi OS¶

Raspberry Pi OS provides a supported OverlayFS option through its configuration tools. Use the focused OverlayFS guide for preparation, activation, maintenance, and recovery.

Before enabling it, inventory persistent paths:

sudo find /var/lib /var/log /etc -xdev -type f -mmin -60 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

Typical data requiring a persistent location includes:

databases and message queues
uploads, recordings, and sensor history
SSH host keys and WireGuard/Tailscale state
package and configuration changes
time-series monitoring data
browser profiles that must retain sessions

Place persistent data on a separate writable filesystem and back it up. Confirm that the application behaves correctly when the root upper layer is discarded.

Filesystem and power basics still matter¶

Use a suitable power supply and cable; unexpected resets can corrupt active writes.
Shut down cleanly with sudo systemctl poweroff before removing power.
Keep free space available for filesystem and flash management.
Use high-quality storage sized for the write workload.
Back up required data and test restoration.
Treat vcgencmd get_throttled undervoltage history as a fault to investigate.

A read-only root reduces one class of corruption but does not protect a writable data partition, the boot partition, or the media from physical failure.

Before-and-after test¶

Use the same 30- or 60-minute workload for each configuration:

Metric	Baseline	Changed
Test duration, minutes
Device sectors written
Journal size, MiB
Application data written, MiB
Peak RAM used, MiB
Reboot persistence test
Required logs available
Recovery test passed

Publish the raw commands, device name, sector size, OS version, storage model, workload, and whether caches were warm. Do not present estimated endurance as measured lifespan.

Changes to avoid¶

Disabling journald completely
Mounting the whole root with sync
Disabling barriers or filesystem journaling without a validated failure model
Moving unbounded logs to tmpfs
Enabling OverlayFS on a remote device without recovery access
Assuming a read-only root replaces backup
Claiming a specific SD card lifespan from a short benchmark

FAQ¶

Does swap destroy an SD card?¶

Swap can add writes under memory pressure, but actual wear depends on workload, media, and configuration. Measure swap activity and write sources. ZRAM may help when the workload and CPU budget make compression beneficial.

Should `/var/log` always use `tmpfs`?¶

No. Doing so removes evidence after a crash or reboot. Bounded persistent logs are usually a better default; use volatile logs only for an appliance with another monitoring path.

Is OverlayFS the best solution for every Raspberry Pi?¶

No. It is best for appliances intended to return to a known state. General servers normally need persistent updates, logs, and service data.

Can software report the remaining SD card life?¶

Most consumer microSD cards do not expose a reliable universal health percentage. Monitor errors, keep backups, and design for replacement instead of trusting an estimated lifespan.