SSD "refresh" with badblocks(8) to aid long term data retention. [no general guaranteed validity on all SSDs]

[spamhog]

THIS IS CONSIDERED AN IMAGINARY PROBLEM BY MANY.

DO READ THE REPLIES! MY ASSUMPTIONS MIGHT BE TOO SIMPLISTIC.

Some pessimistic reports emerged years ago that unpowered SSDs, especially enterprise types, lose data when left unpowered for long periods.
https://www.extremetech.com/computing/2 ... hout-power

TL;DR
To "refresh" data for optimum long term retention on SSD,
which MIGHT be lost especially if read only, especially on unpowered, cold, enterprise devices
1) do regular backups to other media (not discussed here)
2) check data integrity read-only (not discussed here)
3) on a fully unmounted drive, occasionally do a verbose, non-destructive badblocks check showing progress.

Code: Select all

sudo badblocks -vns [path to whole drive]

Suggestions were offered that dara should be rewritten once in a while, to rebuild the original charge in the nonvolatile memory cells, which is supposedly subjected to slow random leakage.

I suggest to do the refresh with badblocks.

https://wiki.archlinux.org/title/badblocks
"A non-destructive read-write test makes a backup of the original content of a sector before testing with a single random pattern and then restoring the content from the backup. This is a single pass test and is useful as a general maintenance test. "

https://linux.die.net/man/8/badblocks
"-n Use non-destructive read-write mode. By default only a non-destructive read-only test is done."

AFTER making sure data is ok with an integrity check, back it up elsewhere, then use badblocks - vns [path to whole drive] which will
- read each cell (by block)
- back up content in RAM
- write a random pattern to cell
- Read cell
- confirm read corresponds to write
- get original content from RAM
- write it back in the cell
- report if any block is bad.

End result would be verified data, backed up, and refreshed at cell level.

Better than rewriting in the file system as the process would refresh also data structures, journals, partitioning etc..

Risk should be more or less limited to the event of a power loss.

This would certainly burn one write out of the lifetime of the SSD. True, only rewriting files would eat much less than exactly 1 write per cell everywhere.

Any comments?

[senjoz]

I suggest to do the refresh with badblocks.

Although my knowledge about flash-based storage devices is limited, I think that it is not totally transparent how badblocks -nsv /dev/device will work with/over SSD's firmware.

This would certainly burn one write out of the lifetime of the SSD.

There may be more write outs of the lifetime involved, backup of the original content, writing single random pattern and
restoring the content from the backup. Three P/E operations?

Interesting link: https://www.ni.com/en-nz/support/docume ... orage.html.

Regards, Jože

[Lady Fitzgerald]

I just power up my external backup SSDs at least once a month to make sure the charge that determines data gets refreshed (the data drives in my daily driver computer get powered up far more frequently). To do so, I connect the backup SSD to the computer (either via USB or by way of a hot swap bay), then run the backup profile for that drive in FreeFileSync to ensure every cell gets read. I also TRIM the drives at least once a month.

Once a month is actually overkill--once a year would probably be plenty--but I normally swap out my backup drives at home with the ones I keep in my safe deposit box at my credit union at least once a month so I'm going to be updating the drives before and after the swap anyway.

A lot of the concern for data retention came from a few years ago, Samsung SSDs were losing data at an alarming rate when used in Linux operated data centers. That was quickly corrected with a firmware update from Samsung.

SSDs will eventually have data loss when left unpowered for extended periods of time, the amount depending on the number of bits in a cell and the remaining write life, so they are not as suitable for cold storage (aka archival) as HDDs. However, backups should be active; in other words, they need to be updated frequently so that will easily maintain the charge. For archival, HDDs are better and tape is best.

[senjoz]

I connect the backup SSD to the computer (either via USB or by way of a hot swap bay), then run the backup profile for that drive in FreeFileSync to ensure every cell gets read.

Is reading of the cell really enough for rebuilding the original charge?

Regards, Jože

[Lady Fitzgerald]

I connect the backup SSD to the computer (either via USB or by way of a hot swap bay), then run the backup profile for that drive in FreeFileSync to ensure every cell gets read.

Is reading of the cell really enough for rebuilding the original charge?

Regards, Jože

From what I've read, yes. For example, this quote from https://www.partitionwizard.com/clone-d ... orage.html:

"...Active SSDs Regularly

If your data SSD is not in use for usual, it is recommended to occasionally plug the drive into your computer and read the data simply to ensure that the electric fields stay as strong as possible..."

That was a fairly recent reference. An older reference (https://eshop.macsales.com/blog/43702-w ... rcise-too/) has this to say (essentially the same thing):

"...Mitigating Solid State Drive Storage Failures

In addition to backing up your data, the simplest way to avoid data loss is to make sure any SSD that is placed in long-term storage, is powered on and used at least twice a year. There’s no reason to rewrite the data; simply powering the drive on and using it as you normally would for a few minutes should be sufficient to maintain data integrity..."

[spamhog]

Thank you all!

There seems to be quite a few different possible reliability enhancing action behind the scenes inside a SSD.

If a drive has some kind of error correction, once a read error is detected, it may lead to a repeated read, and on successsful reconstruction lead to a rewrite of corrected data to another location. This is transparent to the OS except perhaps for an update in some SMART statistics with no immediate bearing on ongoing file system operation.

It seems to be quite hard to figure out exactly what a SSD does or doesn't, which seems to be determined by cells, controller, firmware. In turn, this makes it quite hard to suggest a generalized optimal strategy that can be implemented in software on the host.

https://www.usenix.org/system/files/fas ... -bryan.pdf

So the badblocks -nsv [drive-path] idea is a bit like a somewhat shallow raking for weeds in a vegetable garden. Might work, but no guarantee.

A long time ago a coworker described my preparations against possible hardware failures as "ancestral fears". In the haze between growing delivered reliability and even more obscure proprietary tricks by hardware vendors, i'd say my fear isn't receding much.