The microSD Card Is the Weakest Part of a 24/7 Phone Camera (Silent Write Failure, Wear Cycles, and the Only Honest Test)

A phone recording 24/7 is not really a camera problem. It is a sustained-write problem wearing a camera costume.

Two earlier posts in this series dealt with the file: why an interrupted recording produces an MP4 that will not play, and why finding the right thirty seconds inside a day of footage is harder than capturing it. Both of those assume the bytes are on the medium.

This one is about the assumption. Specifically: the removable card a lot of people reach for the moment they decide the old phone in the drawer is going to be a camera.

1. Flash storage fails in a way that does not look like failing

A hard drive that is dying is usually loud about it. It clicks, it gets slow, it throws read errors, SMART counters climb. You get warning.

A worn or counterfeit flash card can fail in a much less useful way: it accepts the write, returns success to the operating system, and does not durably store what you handed it. The recording app is told the write succeeded, because as far as the card's controller reported, it did. Nothing in the UI has any reason to show an error. Free space goes down. The file appears in the list, with a sensible size and a sensible timestamp.

The problem only surfaces when something reads the data back. Which, for a security recording, is usually the one day you actually need it.

This is the shape of the whole issue: write success is not a durability signal. Every layer above the card is reporting on the layer below's promise, and the bottom layer is the one with an incentive to promise quickly.

2. Continuous recording is close to the worst workload you can hand a card

Consumer microSD cards are specified around a photography workload: bursts of writes, long idle periods, occasional full-card format. That is roughly the opposite of a camera that never stops.

Continuous recording is:

• sustained, not bursty. The write never stops for the entire life of the deployment.
• rewriting, not accumulating. Once the card is full, the useful behaviour is delete-oldest-and-continue, which means the whole capacity gets cycled over and over.
• unattended. Nobody is watching the transfer complete.

The delete-oldest loop is the part people underestimate, because it converts capacity into time between rewrites rather than into headroom. A bigger card does not stop the rewriting. It just slows down how often you go all the way around.

3. The arithmetic on how many times a year you rewrite the entire card

This is straightforward arithmetic and worth doing before buying anything. Bytes per hour is bitrate divided by eight:

Turned into full-capacity rewrites per year, a 128 GB card at 4 Mbps is around 123 complete cycles a year. At 8 Mbps it is around 246. At 16 Mbps — which is an ordinary handset default for 1080p, not an extreme setting — it is around 493.

Two honest caveats on that table, because the number that matters is yours, not mine:

• Bitrate varies enormously with resolution, frame rate, codec and scene complexity. A mostly-static hallway at 1080p H.265 and a windy garden at 1080p H.264 do not produce the same file sizes. Measure your own: record for an hour at your real settings and look at the file.
• Cycles-per-year is not the same as flash program/erase cycles per cell. Wear levelling spreads writes around, and the card's controller does not simply map one full-capacity rewrite to one erase per cell. The point of the table is not to predict a death date. It is to show that the workload is measured in hundreds of full passes a year, which is not the workload the cheap card in the checkout aisle was priced for.

That is also why "high endurance" cards exist as a separate product line, and why the price gap is not purely branding. If a continuous-recording deployment is worth doing, that gap is the cheapest part of it.

4. The filesystem on a removable card cannot tell you it lost something

Removable cards typically arrive formatted FAT32 or exFAT, and phones will happily keep them that way, because that is what makes the card readable when you pull it out and put it in a laptop. That portability is genuinely useful. It also means:

• No checksums. The filesystem stores no per-block hash, so nothing in the read path can distinguish "this is the byte you wrote" from "this is a byte." Silent corruption stays silent.
• No journaling on FAT32. A power loss during a metadata update can damage the allocation table itself, not just the file being written. That is a different and worse failure than losing the last few seconds of a recording.
• A single point of metadata failure. In FAT-family filesystems, the mapping from file to clusters lives in one structure. Damage there can make files that are physically intact become unreachable.

This compounds with the segmentation advice from the interrupted-recording post. Segmenting the recording limits how much video an interruption costs you. It does not protect the allocation table. Those are two different exposures and only one of them is fixed by writing smaller files.

5. "Recording stopped cleanly" and "the bytes are on the card" are separate claims

There is a stack of buffers between an app and the physical medium: the app's own encoder output, the operating system's page cache, the card's internal write cache. A write call returning success generally means the data has been handed to the next layer down, not that it has been committed to flash.

An app can force the issue by flushing and syncing, which pushes data down the stack and waits. That is not free — sync points cost throughput, and a recorder doing it constantly is trading sustained write performance for durability. Where that dial should sit is a real engineering tradeoff, not an obvious win in either direction.

But the important consequence for someone deploying a camera is the ordering: a clean shutdown is a much stronger durability signal than a yanked power cable, and the gap between them is not "the last frame." Depending on what was in flight, it can be the file's index, the directory entry, or the allocation table.

Which is one more reason a phone is a slightly unusual choice here, and in this one respect a good one: it has a battery. A phone with a functioning battery on a wall charger is, structurally, a recorder with a small built-in UPS. When the outlet cuts out, it keeps running instead of dropping mid-write. (Whether an old battery is still a safe thing to keep on a charger indefinitely is a separate question, covered in the heat and battery post.)

6. The media index is not the filesystem

On Android there is one more layer that produces confusing symptoms: the system media index. Gallery-style apps generally browse the index, not the card.

The two can disagree in both directions. A file can exist on the card and not appear in a gallery, because it was never indexed or the index was rebuilt without it. A stale entry can appear in a gallery and resolve to nothing. Neither state is proof of what is actually stored.

The practical rule: a thumbnail is not evidence. A file listing is not evidence either. Only a successful read of the actual bytes is evidence, which brings us to the test.

7. The only honest test is a read-back of the oldest file

Checking free space tells you the card is accepting writes. That is exactly the thing a silently failing card is still good at.

The test that means something is:

1. Open the oldest file still on the card — the one that has been through the most rewrite cycles and has sat there the longest.
2. Play it end to end, or at least scrub through it at several points, including the last few seconds.
3. Do the same for a file from the middle of the retention window.
4. Note the date. Repeat on a schedule you will actually keep — monthly is a reasonable starting point for an unattended deployment.

Newest-file playback is the test most people accidentally run, and it is the least informative one. The newest file is the least worn, most recently written, and most likely to still be partly in a cache. It passes on cards that are already in trouble.

If you want to be more rigorous: copy a known file to the card, copy it back, and compare hashes. On a laptop that is one sha256sum on each side. It takes a minute and it is the only check in this whole article that produces a yes-or-no answer.

8. What actually reduces the exposure

Ordered roughly by how much they buy you per unit of effort:

• Prefer internal storage where the capacity allows it. Managed NAND in the phone is generally a better-behaved medium than a removable card, and it removes the mechanical failure mode of a card working loose in a mounted device.
• Buy the endurance-rated card, from a seller you would trust with a warranty claim. Counterfeit and remarked cards are common enough that provenance is part of the spec.
• Segment the files. It bounds the damage from any single interruption, and it makes retrieval tractable, per the retrieval post.
• Read back the oldest file on a schedule. The whole point of the section above.
• Treat the card as a consumable with a replacement interval, not as infrastructure. If the arithmetic in section 3 says you are doing hundreds of full passes a year, you should have a date in mind for replacing it, the same way you would for a filter or a smoke detector battery.
• Get anything that matters off the card promptly. Retention on a single unattended medium is a plan with exactly one copy in it.

That last one is where the medium question meets the reason to have a camera at all. A recording that only exists on the card is one silent-write-failure away from never having existed. A live remote view, or a copy pulled off the device the same day, is not just a convenience feature — it is the second copy.

The questions worth asking

If you are building or choosing something in this space, these are the ones I would want answered:

• Does the recorder verify anything after writing, or does it trust the success code?
• Does it surface write errors as loudly as it surfaces permission errors, or do they go to a log nobody reads?
• Is there any prompt to check the oldest file, or does the interface only ever show you the newest?
• When the card fills, what exactly gets deleted, and is that decision visible before it happens?

I do not think there is a clean answer to the first one that does not cost throughput, and I would rather say that than pretend otherwise. But a recorder that never distinguishes "the card said yes" from "the bytes came back" is quietly making a promise on behalf of a component that has not earned it.

I build Background Camera RemoteStream, an Android app that records with the screen off and streams live to another device on the same network — no cloud account, no subscription. If any of the above is relevant to what you are running, it is on Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam

More on the project at superfunicular.com.