UPDATE: I was able to solve this problem years ago, but for anyone reading this in the future, the durability problems turned out to be related to flaky power supplies.

--- Original question ---

I'm attempting to use the Raspberry Pi as an embedded/industrial computer. Temperatures are within completely sane ranges, and the primary reliability issues I'm running into are seem to be around SD card deaths after a few months.

Are there any published stats of SD cards in use in industrial/embedded solutions and their MTBF (Mean Time Before Failure)? I've seen a few basic stats claiming 1,000,000 write cycles per sector with wear leveling built into the card, and that's all well and good, but I'm looking for published, real-world test results, not the sales spec sheets, showing real-world performance and failure numbers.

Ideally I need something that I can reliability write to continuously for about 2 years before failure for an embedded linux install that occupies about 1.8 Gb of space on the card. I'm also aware that the larger your free space, the more you can spread out the wear leveling, so larger cards of the same durability effectively give you longer life.

Anyone try to use Raspberry Pis in an industrial situation successfully?

  • 3
    This question appears to be off-topic because it is about SD card durability and has nothing to do with RaspberryPi.
    – lenik
    Commented Aug 26, 2013 at 0:41
  • 2
    The question is completely related to RaspberrryPi. Since it will affect the consumer UX. RaspberryPi has chosen to recommend SD cards as storage, so the discussion about the durability of such storage is within boundaries. Commented Feb 8, 2021 at 3:37

4 Answers 4


An episode from Jupiter Broadcasting Techsnap (Originating research) discuss how a university did real life stress tests on NAND chips. It is about power failures but the discussion touches on the expected life of NAND chips and similar. No manufactures were revealed but the results are interesting.

The best approach is to try and increase the life of card in lieu of trying to figure out how long it should last. You should act in best interest to double its life time that will guarantee a full 2 year span of normal operation.

You can start by making the root file system read only. This also involves turning off logging or moving it to /tmp. You will also opt out of regular updates or manually mounting the file system with write permission to update if needed.

Create an "infrequent" data partition for infrequently accessed files, like web server files or FTP access.

Two or more partition for backups.

Set your /tmp to use RAM and store frequently written files there. Check in /etc/fstab to adjust settings.

Have a separate process do a backup of your /tmp files every n minutes or hours to the separate smaller data partitions. You could even copy the same file to two identically sized partition for redundancy if you are really paranoid.

If the SD card dies of fatigue due to extreme temperatures or voltage spikes then not everything is lost. Good data recovery companies can read the chips and rebuild the data for you if it is very important. Usually only the controllers fry while the memory chips still contain all the data.

I would suggest looking at this answer for more details on how to extend the life of an SD card.

But frankly... even hammering a good SD card 24/7 at full speed will take years before it completey gives up.


Consider using an SLC (rather than MLC) type card. (See a thorough explanation here.) They are an order of magnitude more expensive, but they are also more durable (how much really, I don't know; specs suggest an order of magnitude jump here, too, but...).

And, of course, do follow the advices in e.g. ppumkin's great answer, except the last sentence:

But frankly... even hammering a good SD card 24/7 at full speed will take years before it completey gives up.

Having "good SD card" unspecified (should only SLC or industrial grade products qualify?), I can only say that experience suggests otherwise, unless common Samsung, Kingston etc. cards are all to be considered "not good". As to my own experience, I have both a microSD (some consider it more reliable than normal SD) and a normal one damaged under a year in computers (moderately used static data storage in a laptop, and a default Raspbian on R'PI), while no damage in "dumb" devices, like digital cameras or phones.

Regular durability estimates need to assume a reasonably friendly average distribution of writes, whereas running a live system off such a card has radically different (= horrible) write patterns, especially on /[inux]+/ systems (sorry about the vague regexp ;) ), where "everything is a file" is the default way of life. (I know, I know, that was supposed to be Plan9, but...)

BTW, filesystem choice also has a vast effect on the durability/reliability of flash media. And the Ext* family is definitely not the best for this purpose.

(BTW/2: Your question is about "Maximum, demonstrated durability", but in fact, what you need is some "guaranteed minimum" to safely count on, not a longevity record. Either way, as ppumkin said, that can still only be unreliable guesswork.)


The company Transcend has a series of industrial rated SD and SDHC cards Here

  • 1
    They seems to be more focused on physical ruggedness not electronic ruggedness. Also for storage devices an MTBF measured in hours is pretty much useless.
    – user8894
    Commented Sep 19, 2013 at 10:53

Have you looked into putting the the root file system on to an external HDD or USB pen drive? It's faster (in the case of the external HDD, as for the USB stick it is actually slower) and it extends the life of the SD card, as the SD card is simply used for booting; the root file system is stored externally. This also makes backups/restores easier, as well as transferring files.

Here's the site I read about this on: http://c-mobberley.com/wordpress/index.php/2013/04/13/moving-raspberry-pi-root-folders-from-sd-card-to-usb-hdd/ and here: http://raspberrypihobbyist.blogspot.com/2013/07/running-from-external-hard-drive.html.

From the first post:

So it is a well known fact now that SD cards have a limited life with their read/writes. This poses a problem for the raspberry pi as the root file system is all sat on an SD. If you have ever been met with corruption issues or crashes you more than likely end up having to reflash a new image to the SD card which can result in you losing all of your set up. To get around this there have been a number of posts on the forums regarding moving the root folders out of the SD card and purely using a USB flash drive or HDD.

I have yet to try this out, but I am planning on doing so relatively soon.

Hope this helps!

  • Please do post comments or links to blog posts after to switch over to USB or HDD - I'd be interested to know what your experience is. Thanks, also, for the answer.
    – jefflunt
    Commented Sep 19, 2013 at 15:56
  • Yeah, no problem! Glad you found it interesting, hope it helps you out! Commented Sep 19, 2013 at 17:59
  • USB pen drive flash is the same as SD flash. Obviously some tech about size differs but essentially it is the SAME! What is the purpose of moving root to a usb pendrive? WHy not move it to SSD instead? I rarely give -1 - But because this makes absolutely no sense to me - it just seems like work for nothing?!?!
    – Piotr Kula
    Commented Sep 20, 2013 at 7:37
  • You can move it to an SSD, I just copied the information straight from the article, and the original article didn't include any mention of an SSD, though it would work as well. As for moving the root of the device to an external flash drive is very useful because it makes it helps keep files the same, even if the SD card gets corrupted. If you had read the articles the authors explain the benefits over keeping everything on the SD card. However, this question was about extending the length of the SD card, and this does that, as it minimizes the Read/Write's to the SD card, used for boot only. Commented Sep 20, 2013 at 20:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.