I have had enough of damaged Raspberry Pi SD cards due to frequent power outages here. This week I have ended up with damaged SD card number three and had to take measures to prevent this from happening again and again. Where I live, the power goes down frequently and this is ideal for SD card corruption to occur. And I mean not only damaged file system, but physically damaged SD card. Low level format doesn’t help. I have a good power supply and didn’t overclock; tried a variety of “supported” SD cards so those are eliminated as possible cause. I haven’t been able to run my Raspberry Pi straight for more than 3-4 days, leaving me pretty unhappy about the stability. Googling on the issue reveals it is a frequent problem with many users. I decided to try the approach described by Orer2ddo456 in this post, namely move Raspberry Pi’ root file system from the power sensitive SD card to external USB flash drive. The instructions are easy to follow and 30 minutes later I had my Pi running off the USB drive. I have switched on the SD card’s write protection switch, so it is guaranteed to be read only [edit: apparently the SD card switch is for the OS to consider, not a hardware switch. So Raspberry Pi doesn’t consider it and you can still write to a ‘locked’ card]. The SD card is still required for booting (R/O), but with this approach you can use a 2GB card, so it is a saver. 
The home directory is moved also to the USB drive, so from user’s prospective nothing is changed. I will give this setup a fair amount of abuse to see how it behaves, but it looks promising.
How about using a microsd card adaptor that has a write protection switch?
SD cards also have write protect switch, I flipped mine after I was done. You still have to move the root fs to a writeable drive for the Raspberry Pi to operate normally
OK, I just learnedthat the SD card R/O switch is just a flag for the OS to consider and not a real physical switch.. so flipping it won’t really change anything as I originally thought.
On the Pi, the SD switch connections from that damn fragile socket aren’t even connected! I discovered when I replaced the socket (identical ones from alienspec.co.uk for about £2 each). No connection to the pads. Circuit schematic confirms.
When the / filesystem has been xferred to USB stick, just make sure the boot part is set to ro in fstab. (Has to be undone temporarily if you need to do a dist-upgrade or firmware upgrade)
I moved mine to a Iomega usb hdd a couple of months ago for the same reasons, and despite having 3 or 4 power outages since, the SD Card & HDD survived without a problem, With the increased capacity, it was also an opportunity to add a media server for streaming music/video/pictures, and also a file server – to use as a network backup device. Both functions run happily alongside emoncms.
Paul
That sounds great. Maybe a HDD would be a better option than a flash USB drive
I now use the media server every day listening to music on various devices, and for the first time I now have a great backup routine as I can run it via wi-fi at the click of a icon from my laptop or desktop.
I’ve put the media & backup files in separate partitions to the ‘root’ partition just in case there is any problems with the Pi.
Paul
And why not to use ReadOnly root system with mounted /home on external usb (hdd, ssd, or flash).
Google Debian root ro.
I am using voyage linux on alix board (x86) for home automation about 3-4years. And the root system is always on good condition. Data can be on network.
I need to explore that option too, won’t that mean limited updates/new software installation?
there are two comand: remountrw and remountro
on startup root system is mounted ro.
🙂
That definitely sounds great..I will experiment with it, thanks for pointing it out.
Another option might be to add something like this as an “UPS”: http://lygte-info.dk/review/Review%20USB%20battery%20box%202×18650%20enb%20UK.html
It’s a 2×18650 battery box, able drive load using the input current while charging itself. Delivers 1.5 amp without trouble. There also exist a 3x battery version.
I was also thinking about UPS, but then that doesn’t change the fact that SD cards have a limited number of write cycles before they are damaged
Hi Martin, I’m super interested in hearing how your new setup with USB stick works. Are usb sticks not the same type of flash storage as SD cards? I have found the SD card to die after about four months of emoncms logging. This us something we need to address. On a related but separate topic, today I setup a Pi with an external hard drive to make a local copy of our server databases every night for backup.
Hi Glyn, very good question that has came across my mind too. Strange, but when you google about “SD card power down write”, there are tons of posts on the Internet, but no-one is complaining about a USB pen drive being damaged during an improper power down+write cycle. I have learned (after this blog post) that SD cards have a wear-level mechanism in place, so the larger the SD card is, the more time it takes to wear it out due to write cycles. With no doubt an external HDD drive would be even better, but involves powered USB hub requirement and makes the whole setup quite bulky/more power hungry. I like the idea that @ziuras shares above to mount the rootfs as R/O and only have user data R/W, will experiment with it.
Anyway, it is day 3 for my setup and all working nicely; I think If I manage to get this running for a month then we can call it a success.
Just to add: I think it is unacceptable to have 4 months SD card life as you mention; The Rapsberry Pi team has to really address this by getting rid of the SD card based OS; Since the Raspberry Pi is used in education/kids, it will be a frustration for many to get their setup/work destroyed so easily
Hi all,
my experience with USB-sticks is similar to that with SDcards. They die when running emoncms on a RaspberryPi for a certain time. Tried several things, like no SWAP, no logs but at the end it did not help.
My project was a hydronic balance of our heating system and there are 32 sensors (water forward and return) sending data appr. every minute.
The USB-stick survived just 2 days.
No joy! All data lost. RaspberryPi sitting in the corner collecting dust now.
Oh dear, that doesn’t sound good. Probably external HDD will be the way to go; mine is still holding ground since this blog post, I’m curious how long will it be before it damages the USB flash drive..
Pingback: Raspberry Pi root file system in read-only mode | Martin's corner on the web
Pingback: Martin's corner on the web
How is this setup holding up for you? Am considering the same.
See my next post. Long story short: not good
Hi, As an alternative to the RPi a Beagleboard Black could be used. The cost is the same, but it has a lot more functionality.
This article may interest you: http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/08/10/bbb–rechargeable-on-board-battery-system
Thanks for this guide. Very helpful !
I just want to add my 2 cents : do not forget to update your boot partition on the SD card.
In my case, I installed a different Linux distribution than the one that sit on the SD card. So in order to use the kernel of that distro, you need to copy the boot partition that come with the linux distro to the SD card boot partition.
And after copying the linux distro boot partition to SD card boot partition, don’t forget to re-edit /boot/cmd.txt to redirect the rootfs.
Hello,
What about using a Ramdisk ? I know RasPi is quite low on RAM but may be there is a way to manage a small RAMDisk or TmpFs as some kind of temporary buffer and then write/append datas to main files into SDCard time to time (every few minutes of every hour only) this way SDCard should be much less used and may stay alive longer.
The idea may be suitable for files that only purpose is to be filled, I mean you store data into them but the program/daemon will not have to reread them from RamDisk for example data that are logged into text files or databases.
Let me explain my point of view.
Text file : Your application/daemon is set to write log file into /ramdisk/ , then every xx minutes you trigger some script to “cat /ramdisk/file.log >> /sdcard/file.log” and “rm /ramdisk.log”.
Database : Your application/daemon is set to write log file into /ramdisk/ , then every xx minutes you trigger some script to dump/export database records from RamDisk import into SDCard located database, then clear database tables into RamDisk.
But the program/daemon that is actually using those log files or databases may not appreciate other process touch the same files they are working on, or you may miss some data during the transfert operation so you’ll have to find some trick to avoid this.
Loosing log file entries is possible during the small timelaps between the end of “cat” and “rm” if “cat” is done, a new line come into log file but “rm” has not yet been executed.
Loosing database records is also possible the same way between the small moment dump ends and tables cleaning is on the run, but here you may try some table lock before dump and release lock only once table has been cleaned. If database is SQLite, problem is stlightlly different as you may not be able to write-access DB file if the other process has locked it.
Of course if it is your own program then you can configure it to check for some transfert-running.lock file and then wait until this file dissapear or manage the RamDisk to SDCard directly into your program instead of external cron’ed script.
But may be this idea is dumb ?
…and I forgot, during the transfert operation you may also “/etc/init.d/daemon stop/start” so you stop daemon, then do the transfert, then restart daemon.
But daemon may miss some external events (if it is something working with X10 or ZWave events listening), but if it is a simple 1-Wire reading/logging daemon, then it should be ok.
I have done some experimentation on a NAS disk to improve the performance.
Maybee it can also be used to improve the card reliability.
It’s possible to set the option noatime.
Other possible option :
writeback mode
In data=writeback mode, ext4 does not journal data at all. This mode provides
a similar level of journaling as that of XFS, JFS, and ReiserFS in its default
mode – metadata journaling. A crash+recovery can cause incorrect data to
appear in files which were written shortly before the crash. This mode will
typically provide the best ext4 performance.
ordered mode
In data=ordered mode, ext4 only officially journals metadata, but it logically
groups metadata information related to data changes with the data blocks into a
single unit called a transaction. When it’s time to write the new metadata
out to disk, the associated data blocks are written first. In general,
this mode performs slightly slower than writeback but significantly faster than journal mode.
Example :
#Remount root with noatime
mount -o remount,rw,noatime,nodiratime /dev/root
Example :
#Remount SDA 3 with noatime
mount -o remount,rw,noatime,nodiratime /dev/sda3
ou
# remount with noatime
mount -o remount,noatime /
mount -o remount,noatime /volume1
# optionally disable the swap file
#swapoff /dev/md1