SSD paranoia

Reading up on SSD characteristics, I stumbled across a statement that NAND SSD will slowly leak charge when unpowered: this could lead to data loss after 2-3 years.

How much of a problem is this in practice? My Raspberry Pi (with mSATA SSD) is only powered on for a few hours each day: do you have to add up all the “off” times regardless of how often it’s “on”, or do they just mean “off continuously for years at a time”?

This could influence backup strategies. After all, if there’s a chance you’re storing bad data (thanks to SSD charge leakage) the latest backup cannot be relied upon.

A quick Google found me an article that gave the data loss time as two weeks, but granted this was for a server environment where the things are running hot which greatly affects the lifespan.

Something that confuses me is the apparent contradiction in the articles that I have read. That being that a Flash device without power will, in time, degrade. That degredation happens as a result of the memory cells leaking their charge. But the thing is, Flash isn’t DRAM. It isn’t periodically refreshed, Flash cells are given charge when data is programmed to each block. Which means that active filing systems ought to offer a reasonable life, as writing data and wear levelling should, in time, exercise most of the blocks.
But what about devices like, well, pretty much everything these days that holds firmware in Flash?

For backup purposes, while you may indeed be backing up corrupted data, it’s the same thing that is on the live filesystem. The question is in detecting whether or not the data is corrupted, and for that it helps to have periodic backups that can be referred to. Never keep all of your eggs in one basket.
And, don’t forget, that if your file is corrupt and your backups going back years are corrupt… then clearly it isn’t that important a file. ;-)

Another question to raise is what you are backing up to and how long that lasts for. CD-Rs variously claim longevity from 25 to 100 years, however I’ve had CD-Rs fail on me (the foil layer separates from the plastic), and I’ve also had the same thing happen for commercial music CDs and DVDs. Most of my floppy discs are unreadable. They’re 20 years old and have spent a lot of that time in a damp house. The dampness has probably affected spinning-rust that isn’t frequently used (making it a literal case of spinning rust!).

Nothing lasts forever, the only reasonable way to handle backups is to split your data into two. That which is periodically backed up as a matter of course, and that which is important to you that gets backed up multiple times (and possibly on different media). My photos that I take with my phone are (usually) copied to two different USB harddiscs and to DVD-R.
Why two harddiscs? Brownouts, software failures, DRAM failure, etc etc could lead to filesystem corruption.
Of course, a house fire would take out all of that, so then one needs to consider the possibility of offsite backups for really important data.

I plan to get myself a USB harddisc and a hermetic plastic box. This can live in the field barn. When? I don’t know. Of course, this won’t be a help if the house burns down tomorrow, but I figure in that case I’ll have bigger problems to worry about than whether or not my data is intact…

Do you run chkdsk (Windows) or DiscKnight (RISC OS) before dumping a large amount of data on a read/write device? You should… just to make sure you aren’t ending up with a broken filesystem being even more broken…

Anyway, don’t worry too much about SSD failures. There are hundreds of things that could screw up backups. The best strategy is to back up regularly, keep multiple copies of things, and use various different types of media.

My Raspberry Pi (with mSATA SSD) is only powered on for a few hours each day: do you have to add up all the “off” times regardless of how often it’s “on”, or do they just mean “off continuously for years at a time”?

It looks like the drive needs to rewrite the physical block in order to refresh the charge. In practice, I suspect that as long as you’re periodically writing data to the drive it’ll be fine – the wear levelling should make sure that physical blocks which haven’t been rewritten in a long time eventually get rewritten.

This could influence backup strategies. After all, if there’s a chance you’re storing bad data (thanks to SSD charge leakage) the latest backup cannot be relied upon.

Backing up to SSD, or backing up from SSD? If you’re backing up from SSD, the blocks which have gone bad due to current leakage should be detected by the drive and you’ll get a read error.

If you’re backing up to SSD, it sounds like you’ll have to be careful with how you use that SSD in future. I.e. writing to the SSD once and then throwing it in a cupboard (or a freezer to slow down the current leakage!), eventually the data will degrade beyond the limits of the ECC and the backup will be useless. But if you continue to periodically write data to the SSD, that old archival backup file from 10 years ago should stay healthy and fresh (at least until the SSD gives up and becomes read-only)

But what about devices like, well, pretty much everything these days that holds firmware in Flash?

Somehow I doubt the manufacturer would complain if you had to frequently throw away your old devices and buy the latest models…

Risk is absolutely minimal:
https://www.pcworld.com/article/2925173/debunked-your-ssd-wont-lose-data-if-left-unplugged-after-all.html

And it was 5 years ago.

Nothing lasts forever, the only reasonable way to handle backups is to split your data into two.

I had been employing a slightly disjointed approach across my three machines (Pi, MacBook and ArmBook):

1. A monthly archive of everything on the Pi to two USB flash drives. This means I still have two copies of every backup I have ever taken since purchasing the Pi – they don’t take up that much room :-)
2. Stuff that I was working on would be copied to the MacBook on a more frequent (but in practice ad-hoc) basis, where it would be stored on spinning rust.
3. On the ArmBook, I had been achieving de facto backups of the SD card by changing to a new SD card at every ArmBook software upgrade. An external SSD attached to the ArmBook had never been backed-up, although the vast majority of the data came from the Pi.

That came to an end two days ago when my MacBook became an ex-MacBook. This got me thinking about the impermanence of all things, including the longevity of SSD…

Do you run chkdsk (Windows) or DiscKnight (RISC OS) before dumping a large amount of data on a read/write device?

Yes, although I don’t rely on those alone. As mentioned above, I use two USB sticks (so if writing to one stick fails I still have everything on the other stick). For important backups I also check that the saved archives can be read successfully (for .zip archives via the SparkFS “Test” facility).