linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Matt Garman <matthew.garman@gmail.com>
Cc: David Brown <david.brown@hesbynett.no>,
	Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>,
	Mdadm <linux-raid@vger.kernel.org>
Subject: Re: Storage system
Date: Fri, 7 Feb 2014 21:14:46 +0600	[thread overview]
Message-ID: <20140207211446.4cf96a7f@natsu> (raw)
In-Reply-To: <CAJvUf-BTjmxonub0eWGNm1YNp4zYis5Mgti9FuRiQ8RbVY3cXQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

On Fri, 7 Feb 2014 08:29:19 -0600
Matt Garman <matthew.garman@gmail.com> wrote:

> FWIW, I use a program called "shred" when I'm done with a disk.

Disks are not always alive when they need to be thrown out, I'd say it's very
much to the contrary. And while the drive electronics may be bust so it
doesn't even detect in the computer, all your data could still sit perfectly
intact on the plates.

Of course a physical destruction of the disk is an option in this case, but
what if instead of throwing away such a disk, you need to RMA it to the
vendor (or send to a data recovery company)? It's the absolutely worst case:
an untold number of people will have unlimited access to your data after they
repair the drive, for as long as they want (they can make a full copy).

Having said all of the above, I do think it is an overkill to use encryption
above/below RAID5/6 to protect against such cases. I feel that "they" get only
a crude haircomb-like view of the data (every 6th 64KB or whatever) is enough
to effectively make the data unusable.

Of course there's still 1 in 6 chance, for a 6-device RAID, that your
passwords, or your private ssh key, or whatever, will fall entirely into that
64KB portion that was on the drive in question, and someone will be
determined-enough that in the absense of a working filesystem look through
all of the drive and find it. But I think that's a risk we can learn to live
with. :)

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2014-02-07 15:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-06 18:09 Storage system Piergiorgio Sartor
2014-02-06 19:24 ` Joe Landman
2014-02-07  8:07 ` David Brown
2014-02-07 14:29   ` Matt Garman
2014-02-07 15:14     ` Roman Mamedov [this message]
2014-02-07 15:45       ` Roberto Spadim
2014-02-07 16:11     ` David Brown
2014-02-07 16:25       ` Can Jeuleers
2014-02-07 16:36         ` David Brown
2014-02-08  0:14           ` Chris Murphy
2014-02-07 19:16       ` Robert L Mathews
2014-02-07 23:58     ` Chris Murphy

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=20140207211446.4cf96a7f@natsu \
    --to=rm@romanrm.net \
    --cc=david.brown@hesbynett.no \
    --cc=linux-raid@vger.kernel.org \
    --cc=matthew.garman@gmail.com \
    --cc=piergiorgio.sartor@nexgo.de \
    /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;
as well as URLs for NNTP newsgroup(s).