Raspberry Pi SD Card Corruption: What Actually Broke

Raspberry Pi SD card corruption is what I blamed for most of a weekend, and the card turned out to be fine. My SQLite connections were running PRAGMA synchronous=NORMAL in WAL mode; the SQLite Write-Ahead Logging documentation says that setting leaves transactions no longer durable, with a possible rollback after a power failure or hard reset. I run FULL on anything unattended now, keep the database off the boot card, and mount the root read-only.

What my Raspberry Pi SD card was doing before the power cut

Raspberry Pi SD card corruption on my bench came from the SQLite database, not from the card itself. The nodes ran one ingestion service that wrote every few seconds, and the card absorbed those writes for months without complaint. A brownout during a breaker test killed a board with no warning. The next boot replayed the journal and mounted cleanly, which is what kept me looking past the storage.

I had wired it up the way most people end up logging to a database: one SQLite file sitting on the same card that held the operating system. The box shares a closet with the home server closet cooling gear I run, and heat was never the variable here. A thin power lead was, maybe, and I had not checked it.

Where my Raspberry Pi SD card troubleshooting went wrong

Raspberry Pi SD card corruption handed me a clean mount log, and I spent the afternoon reading logs that had nothing to say about the data.

1. I assumed the card was failing. Wrong: it had run the same write pattern for months without a single complaint.
2. I read the boot log and stopped at the mount line. Wrong: a clean root mount says nothing about a database file that lost its last committed transaction.
3. I rewrote the ingestion service to use smaller transactions. Wrong: I never touched the sync setting, which is the one the SQLite Write-Ahead Logging documentation ties to durability after power loss.
4. I copied the database off the card and ran PRAGMA integrity_check on the copy. Wrong: the copy was taken after the replay, so it covered none of the window where the rows went missing.
5. I bought a new card and reflashed it. That handled the symptom and left the setting in place for the next brownout.

Step five was cheap because my Jenkins NAnt build pipeline already knew how to reflash a card, which is the part of that list I would keep. The rest of it was rearranging one wrong assumption.

What fixed Raspberry Pi SD card corruption on my nodes

Setting PRAGMA synchronous=FULL fixed it, because the SQLite Write-Ahead Logging documentation states that FULL makes writers sync the WAL on every transaction commit.

1. Set PRAGMA synchronous=FULL on every connection that writes. With NORMAL, writers omit that sync, and the same documentation says transactions might roll back following a power failure or hard reset.
2. Move the database off the boot card. An SD card controller keeps a small piece of cache memory and a list of operations it has not performed yet, so an unclean cut leaves “pending write operations that will never get completed”, as Arya Voronova put it in Hackaday on March 9, 2022.
3. Open the file with psow=0. The SQLite Powersafe Overwrite documentation, a page last updated May 31, 2025, says the default unix and windows VFS reported a 512-byte sector size through version 3.7.9, while newer drives use 4096-byte sectors.
4. Mount the root file system read-only. The Raspberry Pi Ltd white paper Making a more resilient file system, Release 2 under a 2022-2026 copyright, lists a read-only ext4 root, an overlay file system, tmpfs for temporary files, F2FS and pSLC on Compute Modules as the supported ways to reduce writes.
5. Take the log stream off the card. I pointed it at a broker through a Log4Net RabbitMQ appender, which removed writes the filesystem had no reason to journal in the first place.
6. Check the SQLite version. The same Write-Ahead Logging documentation says the WAL-reset bug is present in every version from 3.7.0, released July 21, 2010, through 3.51.2, released January 9, 2026, and fixed in 3.51.3 on March 13, 2026, with backports in 3.44.6 and 3.50.7.

Roger Binns, quoted in the Powersafe Overwrite documentation, told the SQLite developers mailing list that “‘poorly written’ should be the main assumption about drive firmware.”

A checklist for Raspberry Pi SD card corruption risk

Raspberry Pi SD card corruption risk shows up in settings, versions, storage and power, and the version check is the one that gets skipped.

What to check	What I found	What it tells you
PRAGMA synchronous on every writing connection	NORMAL	SQLite Write-Ahead Logging docs, page updated August 25, 2026: transactions might roll back after a power failure or hard reset
SQLite version	older than 3.51.3	Same page: the WAL-reset bug spans 3.7.0 (2010-07-21) through 3.51.2 (2026-01-09)
Where the database file lives	on the boot card	Hackaday, March 9, 2022: the card controller holds a list of writes it has not performed yet
Root mount option	writable	Raspberry Pi Ltd white paper, Release 2 (copyright 2022-2026): read-only root, tmpfs and an overlay file system
Storage behind the database	a network filesystem	SQLite Write-Ahead Logging docs, page updated August 25, 2026: WAL does not work over a network filesystem
Power feed	an original undersized lead	Hackaday, March 9, 2022: a hand-soldered supply caused years of corruption until it was swapped

What to do this week if your Raspberry Pi SD card is corrupting

Run PRAGMA integrity_check on the live file first, because the SQLite PRAGMA documentation says it returns ok when it finds nothing and stops after 100 errors otherwise.

1. Run the check against the file that is actually on the card, not a copy made after a reboot.
2. Set PRAGMA synchronous=FULL on every connection that writes, then restart the service.
3. Move the database off the boot card, and open the most recent restore once to prove it opens.
4. Replace the power feed before the card. Hackaday reported on March 9, 2022 that a hand-soldered LM2576 supply had caused repeated corruption on one board until it was replaced.

Raspberry Pi SD card corruption FAQ

Does Raspberry Pi SD card corruption always mean the card is dead?

No. In my case the card survived and the database on it lost committed rows, because PRAGMA synchronous=NORMAL in WAL mode leaves transactions no longer durable (SQLite Write-Ahead Logging documentation, page updated August 25, 2026). The card was the last thing I suspected and the wrong thing to replace.

Is a read-only root filesystem enough to stop Raspberry Pi SD card corruption on its own?

No. A read-only root removes most writes to the operating system card, and the Raspberry Pi Ltd white paper Making a more resilient file system (Release 2, copyright 2022-2026) pairs it with tmpfs, an overlay file system and separate storage for state. It does nothing for a database whose own commits were never synced.

Does WAL mode make a SQLite database on a Raspberry Pi SD card safe?

No. WAL mode reduces the number of fsync calls, but with PRAGMA synchronous=NORMAL writers skip the commit sync entirely, and the SQLite Write-Ahead Logging documentation says transactions might roll back after a power failure or hard reset. WAL also needs every process on one host, because WAL does not work over a network filesystem.