thanks for clarifying. wasn’t aware that there was no SMART or anything whatsortsoever.
How about SD then with dd once a “day” (night) to another SD card of the same size with previos error check?
or dd to a magnetic disk with erasion of files when new ones are being deployed and disk capacity >80%
there was a possibility to write 0’s to the free space on a SD and then compress the image?
These sound like a lot of write operations. Writes are what wear out the SD card. Each memory space can only be written to a finite number of times.
Also, with flash memory it really isn’t possible to write zeros to the free space. The technology just doesn’t work that way. You can write zeros a million times but you have on control over what cells those zeros get written to. There may be many if not most of the currently marked as unused cells that never get written. And the “free” cells may not be wholly free. This sort of thing simply does not work with flash memory.
Over all, honestly, this sounds way more complicated than just setting up a good backup and restore procedure and dealing with restoring to a new SD card when the SD card you are using goes south. You will need this anyway. And configuring the machine to use an SSD or HDD would be even simpler and in the end probably more reliable.
OK thanks for clarifying, I am still thinking about magnetic discs.
I read that amanda seems to be a pretty descent tool?
I will follow your suggestion and go with an hdd and do daily backups, now I need to get this SD card running with the least amount of writes.
I’ve got a 5V 6A power supply and will attach an USB hdd and do backups with amanda and probably one dd every couple of weeks.
As UPS I will look into getting a power-bank.
See here where I am stuck at the moment
It is, and you can use it to backup the raw SD card. You just need some storage space, but not that much actually so that can well be flash based (as you write there just once a day, wearout is no issue for that).
Going through all these now! Thanks great tips. My sad card was toast last week, so I am doing a restart and gonna setup this way.
I want to use persistence and show my sensordata with grafana. At the moment I still have a microSD card in my Raspberry B+. So copying the root system (like in the openhabian-config tool) to an SSD will not be the fix?
Why are so many suggesting to use an SSD? You say that wear leveling will not apply because files will not get created and deleted like on servers?
Because it’s the only improvement they know. Yes SSDs are better than SDs because they have a buffer but it is still flash RAM, too, and there’s further drawbacks these come with (knowledge needed to config, cost, proper setup to boot etc). Yes wear levelling doesn’t always apply. If it truely did, we wouldn’t be having that many people to have problems.
SSD´s are alot faster than SD cards, even connected to the Rpi.
Ofcouse there are drawbacks, (there always are, not matter what you choose). My main reason for recommening an SSD rather than an SD card is, that the SSD is way faster. And the chances of getting a drive crash is less than with the SD card. (cant say how much though).
Even though my SSD is connected using the USB port of the Rpi, it´s still significan faster than the SD card. Some weeks ago I started a new Rpi (3B+) with a SD card due to some testing. My main Rpi 3B is running with an SSD and is quite busy. The new Rpi 3B+ got a absolut minimal install with only one binding.
My main and quite busy system boot up to finish more than a minute faster than the Rpi 3B+ with SD card and minimal install.
A fresh install of openhab 2.4 (hassle-free openhabian) takes aprox 15 minutes using an SSD. Including creating the image copy on a windows 10 using win32diskimager.
Using an SD card it takes what feels like forever. My guess is about 1 hour 15 minutes, including the image copy.
I personally would never fall back to SD cards again. I´ll rather pay some more, and then have more time to play some more 
So in openhabian-config the option to move root to usb device serves only for better speed and has not much to do with reliability of the system?
Mostly yes. Sure it’s distributing write load across multiple media so helps somewhat but it clearly is not the aspired solution to provide high reliability.
Hello, I am new here and I really want your opinion about somehing?
Do you have Discord?
Mail?
What ever you like I just have a few question.
Thank you so much for all your help on the forum !
I’m not doing 1:1 support or discussion.
This is a public forum so post your question in a new thread.
And please follow the rules.
Okay I am sorry I didnt know that.
I’ve been using a powerbank since almost one year. I noticed that a couple of led does not work anymore but except that it continues to operate reliably. Nevertheless, i’ve recently found a blog entry on the ravpower website, stating that pass-through is not meant to be used continuously.
In any case, even an ups will eventually require a replacement of its internal battey after some time. When my powerbank will finally fail i will consider an ups, whose advantage is clearly that it can keep up and running also my switch.
I’ve offloaded /var/log and /var/lib/persistence to an USB stick. While all the log files after some times are split by the logrotate, the same does not apply to rrd4j persistence files that do not grow in size by design and are continuously written. Would it be worth periodically copying persistence files in order to let wear leveling work?
You don’t need to do this because of the way that wear leveling works. The storage is broken up into sectors. Each sector can have part or all of more than one file in it. When and file that is stored in that sector changes, the entire sector is copied to a new sector with the changes made. The old sector is now added to the pool of available free sectors.
Every time rrd4j writes to the DB, the file gets moved around the SD card anyway. There is no need to copy files around for wear leveling.
Also, the above is why you should never pull the power on an RPi if you can help it. If it happens to be writing a sector that also contains, for example, part of the kernel, the next time you start up it won’t be able to boot because part of the kernel was lost.
Is there a way to turn off all logging? Ie. have nothing being written to the SD card. I have a couple of products in my house like the ISY99 that have an SD card. They are several (>3) years old and are doing just fine. I don’t really need logging. Nor persistence. I don’t mind backing up my PI when I make changes, but I don’t want to spend the time setting up and maintaining storage on a USB drive or a NAS and managing the sym links etc.
I think you can disable logging for OH in the config file. But that only addresses OH. All kinds of stuff logs too from sshd to the kernel. It will be way less work in the long run to configure the logging to go to a ramdisk than to figure out how to so everything from logging.
Following on what @rlkoshak said, this article might be of interest to you. I bookmarked it earlier this week as something to try in the future. If you get it working, I’d love to hear about it.
As @rlkoshak said there still will be system logging, so reducing OH logging helps but won’t disable writes altogether.
Try commit=300 (or a higher value) in /etc/fstab for the filesystems your Pi logs to, that should greatly reduce the number of writes (but be cautious with the / filesystem, I haven’t tried it there yet).