From: Mick <michaelkintzios@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Safeguarding strategies against SSD data loss
Date: Mon, 27 Oct 2014 15:23:20 +0000 [thread overview]
Message-ID: <201410271523.22392.michaelkintzios@gmail.com> (raw)
In-Reply-To: <loom.20141027T154955-641@post.gmane.org>
[-- Attachment #1: Type: Text/Plain, Size: 3204 bytes --]
On Monday 27 Oct 2014 15:15:22 James wrote:
> Rich Freeman <rich0 <at> gentoo.org> writes:
> > > On 27/10/2014 11:24, Mick wrote:
> > >>> With a caveat: if an ssd dies, it will die suddenly. Without warning.
>
> With SSD the most important fact to keep constantly in mind is
> writing/erasing by blocks due to uniqueness of the hardware.
> Unfortunately, if you dig deeply, many Solid State Storage devices
> are organized differently and those hardware differences may impact
> your SSD_specific implementation details. SSD raid redundancy is
> something most machines (folks) cannot afford, imho and may be a waist
> to dis_functional if you employ the same semantics for I/O on the
> redundant SSD hardware.
>
> [1]
> http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-summary-what-eve
> ry-programmer-should-know-about-solid-state-drives/
>
> > >> In such cases I am prepared to live with the risk of some
> > >>
> > >> data loss, on machines where raid is not an option.
>
> Wise with a well thought out (planned) recovery/fresh-install strategy.
>
> > > Without some form of redundancy that would be your best strategy -
> > > decent and frequent backups
> >
> > But yes, backup and RAID are really your only options for SSD failure
> > as far as I can see it. That and limiting the amount of data that
> > can't be re-generated. If you just save the world file and all of
> > /etc you could probably rebuild a Gentoo install fairly quickly on a
> > new drive, and then you're just left with /home and whatever else you
> > happen to have installed that sticks stuff in /var that you care
> > about.
>
> Yep. Rich has it exactly right. I'd add /usr/local/*
> as by design that is where I put most uniqueness in any linux system
> besides the list above.
>
> In fact for small networks, I just identify the directories that I want
> to preserve. At the least you rsysnc those to a differnet system
> on the local net, besides a backup, if no raid is underneath. (Triple).
> Obviously, you have all systems on UPS power......?
>
> I'd add any dirs with custom scripts and the kernel files also minimally
> replicated to another system. A comprehensive list of critical files
> is fine. Workstations and servers have different lists of critial files;
> and you can further subdivide the servers by function, to focus
> on those critical files and directories. So what is on the SSD that is
> important, just replicate it to a spinning HD on the local net. None
> of this replaces weekly backups, but give you a tertiary level of
> recovery redundancy for the important stuff. Triple redundancy is keenly
> important for all critical stuff; ymmv.
>
> Personally, I find max-ram and spinning HD to be the best bang for the
> buck. But, many folks with older portables are usually really happy with
> SSD as a replacement (single) drive that is cost effective but needs
> a network backup.
>
> [2]
> http://serverfault.com/questions/454775/is-post-sudden-power-loss-filesyste
> m-corruption-on-an-ssd-drives-ext3-partition
>
>
> hth,
> James
Good comments and links James. Thank you.
--
Regards,
Mick
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2014-10-27 15:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-27 9:24 [gentoo-user] Safeguarding strategies against SSD data loss Mick
2014-10-27 10:30 ` Alec Ten Harmsel
2014-10-27 11:11 ` Alan McKinnon
2014-10-27 13:13 ` Rich Freeman
2014-10-27 15:15 ` [gentoo-user] " James
2014-10-27 15:23 ` Mick [this message]
2014-10-27 15:22 ` [gentoo-user] " Mick
2014-10-27 15:36 ` Rich Freeman
2014-10-27 16:52 ` Pandu Poluan
2014-10-27 17:26 ` Volker Armin Hemmann
2014-10-27 17:30 ` Rich Freeman
2014-10-28 0:41 ` Pandu Poluan
2014-10-28 1:13 ` Rich Freeman
2014-10-28 3:45 ` Tom H
2014-10-27 17:23 ` Volker Armin Hemmann
2014-10-27 17:37 ` Rich Freeman
2014-10-28 0:56 ` Pandu Poluan
2014-10-28 3:49 ` Tom H
2014-10-27 17:20 ` Volker Armin Hemmann
2014-10-27 17:17 ` Volker Armin Hemmann
2014-10-27 12:27 ` Philip Webb
2014-10-27 14:12 ` [gentoo-user] Safeguarding strategies against SSD data loss : PS Philip Webb
2014-10-27 15:16 ` [gentoo-user] Safeguarding strategies against SSD data loss Mick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201410271523.22392.michaelkintzios@gmail.com \
--to=michaelkintzios@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox