[Discuss] SSD drives vs. Mechanical drives

[gaf at blu.org (Jerry Feldman)]

Backup strategy depends on usage. That said, a recent backup of your
data will save a lot of headaches and money. And make sure the backup
runs and your backup device is working.
Case 1: Us, the BLU. we had a backup strategy, but it failed because we
made changes to access of the server and we never checked the
consistency of the backup.
Case 2: Myself. I had a nightly backup running. It was a 32-bit machine.
The /home file system was on a separate physical drive and it failed. My
backup was a tarball. But, I had a couple of VMs on that file system,
and tar failed about halfway through. Unfortunately the important data
was on the section of the tarball that tar could not read past. I spent
a few bucks by sending the drive away where they did an excellent recovery.

The issue is that if you do backups and the integrity of your backup is
good, you stand to lose only the data between the backup time and the
failure. Offsite storage of backup data is recommended, especially for a
business. I once worked for a company that had to restate all their
financial records (mostly for the IRS) because a computer operator
mounted the wrong tape and accounting didn't catch the error. But, many
businesses have a legal requirement for data retention. So, in my case,
I just figure out what I will lose in time and data. There are many
excellent backup methods available for Linux, and you can either take
physical media offsite, or use a cloud service if your trust its
security and integrity.



On 05/05/2014 03:30 PM, Kent Borg wrote:
> On 05/05/2014 11:47 AM, Richard Pieri wrote:
>> Any medium can fail with no warning.
>
> Indeed, though disks frequently (usually?) degrade with warning. SMART
> monitoring can note ECC-errors, for example. And other key components
> tend to have "lifetime" reliability, i.e., CPUs and RAM and
> motherboards are usually replaced while still functioning. Fans
> sometimes die early, but usually make a hellish noise first as a warning.
>
> Flash is a bit unique in that it has an advertised finite life in
> write-cycles (scarily small number per-cell with modern flash) and
> though firmware cleverness extends this, they have still been observed
> to die with no warning. Very unnerving. Very trendy, too: are Mac
> notebooks even available without SSDs these days? Does Apple have some
> magic exemption to these flash problems? Very unnerving.
>
>> Good backups have always been the go-to recourse for these occurrences. 
>
> The term "backup" tends to refer to having historical copies of data,
> usually with a notable delay in how long it takes to restore the data.
>
> I would suggest that with flash, hardware redundancy (external to
> whatever proprietary hocus-pocus is already in a flash product) is
> wise. Something present and immediately bootable.
>
> In my case (1) limiting the use to a regime that is not so stressful
> to flash and (2) having a ready backup boot device, should address
> that. Unfortunately, if it does fail on me, a human presence is
> probably needed to reboot things. Just my personal basement server, so
> I think I can live with that.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90