I can't edit now... but one thing I'd like to change - it's not fair to call this their first line of defense.
Rachel did the most important thing right: taking backups at the first sign of trouble, presumably beforehand too.
I just feel they're off the mark foregoing block devices and having a strange process as a result... "because images are big". Speeding up doesn't normally quiet a squeaky wheel. Not to say it can't... but let's place bets :)
There are options for this concern without compromising the efficacy of the whole process; for example, {de,}compression.
Yes, you care about the files, but to recover them... you don't get to ignore the details of the filesystem - or the constraints you're allowing it (and yourself) to operate under.
The takeaway from this isn't "substitute well-established recovery processes..." but, make sure you have backups so you can afford two perks:
* ignore a failing drive for weeks
* not care *at all* about your attempts to recover the source filesystem
The filesystem, your storage, everything will lie.
Prepare for it; make copies and accept this will take time. This chestnut still applies: "If you don't have time to do it right, you must have time to do it again."
The right thing is not storing data on a single 2.5 consumer SSD because the endurance on those devices are trash and the fail at super high rates.
They aren’t designed for a linux server, they’re designed for a disposable Windows laptop that will be chucked in the bin after a year or two. I’ve learned this lesson the hard way over, and over, and over again with these little cheap SSDs.
Most consumer 1TB SSDs with 600TBW should last at least within 10% or so of 600 days at 1 DWPD. If your ZQQTIAN or KingDonxi Amazon specials, populated with Micron QA rejects or SpecTek super economy grade or random e-waste upcycling chips failed in a month, that's on you.
> The right thing is not storing data on a single 2.5 consumer SSD because the endurance on those devices are trash and the fail at super high rates.
What do you mean by "endurance"?
The only definition I found was the number of writes during the warranty time, and you're talking about a use case involving a very low volume of writes (i.e., save a file, keep it up for eternity).
This means that warranty time (more specifically, any failure mode at all beyond excess writes) is the most likely failure mode. Not writes, just the SSD being old.
Samsung advertises between 3 years and 10 years of warranty. The typical warranty of HDDs is between 3 and 5 years. Doesn't this suggest that buying you a decent SSD buys you at worst the same reliability?
How do I know an SSD is reliable or not? How do I know it's a consumer SSD or a real SSD? I'm particularly interested in drives which contain firmware that doesn't lie to the operating system about whether crucial operations have completed or whether errors were found. Is there a way to know?
I want to buy equipment that will last at least 10 years. It won't be heavily written but it will be heavily read. To me it feels like SSDs should last a long time for write-once read-many use cases.
Meh. The right tool for the job. That's engineering.
I hint at that by not caring about how the copy is made. Just that it is made... and that it's checked. Perhaps against some friends/additional copies if the situation allows for it.
Maybe all you have is an SD card or floppy drive, y'know? Each project or situation is different, I find dealing with the matters at hand more practical than dwelling over what I'd prefer.
Laptops would all be better off with four drives in RAID10 but we just don't do that.
Rachel did the most important thing right: taking backups at the first sign of trouble, presumably beforehand too.
I just feel they're off the mark foregoing block devices and having a strange process as a result... "because images are big". Speeding up doesn't normally quiet a squeaky wheel. Not to say it can't... but let's place bets :)
There are options for this concern without compromising the efficacy of the whole process; for example, {de,}compression.
Yes, you care about the files, but to recover them... you don't get to ignore the details of the filesystem - or the constraints you're allowing it (and yourself) to operate under.
The takeaway from this isn't "substitute well-established recovery processes..." but, make sure you have backups so you can afford two perks:
The filesystem, your storage, everything will lie.Prepare for it; make copies and accept this will take time. This chestnut still applies: "If you don't have time to do it right, you must have time to do it again."
The recovery or your data?