All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: Matt Garman <matthew.garman@gmail.com>
Cc: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>,
	Mdadm <linux-raid@vger.kernel.org>
Subject: Re: Storage system
Date: Fri, 07 Feb 2014 17:11:31 +0100	[thread overview]
Message-ID: <52F505B3.2050902@hesbynett.no> (raw)
In-Reply-To: <CAJvUf-BTjmxonub0eWGNm1YNp4zYis5Mgti9FuRiQ8RbVY3cXQ@mail.gmail.com>

On 07/02/14 15:29, Matt Garman wrote:
> FWIW, I use a program called "shred" when I'm done with a disk.  It
> makes N (default = 3) passes of writing random data to the disk, and
> an optional final pass of zeroes.  It's time-consuming to complete,
> but takes only 30 seconds to get going.  Even more convenient if you
> have one of those USB hard drive docks, so you can take the drive out
> of your system.
> 
> Based on what I've read, that should be sufficient to keep anyone
> without a Dept of Defense budget from recovering you data.  The DOD
> probably already has your data anyway, so that's a non-issue.  :)
> 

Even with the full resources of NSA, there is no way to read useful data
from a disk that has had a single pass of writing zeros.  Multi-pass
disk erasure is a case of some companies getting very rich from a myth
based on a single academic paper with theories about how /some/ data
/might/ be recoverable from overwritten disks.  It was never more than
an idea at the time, and it applies even less to modern disks.

In an experiment, researchers wrote some bits to a sample of hard drive
material, overwrote them once, then tried to read the old data.  I can't
find the reference (I really wish I could), so my figures may be a bit
off - but they are in the right ballpark.  I believe it was about 32
bits they wrote.  They managed to recover 7 bits that they were
confident were correct - after spending months with equipment such as
electron microscopes.

The most convincing argument, however, is the economic one - if it were
possible to recover erased data (that has been overwritten once) with
any reliability, then disk recovery firms would be offering such a
service.  These folks can get your photos back after disks have been
"destroyed" in fires - but they cannot get data back if it has been erased.


The only thing you can't erase are re-mapped sectors - but hopefully
those will be rare!

With SSD's it's a bit different - re-mapping and garbage collection
means that there is the possibility of some data being left on partially
filled blocks.

> 
> 
> On Fri, Feb 7, 2014 at 2:07 AM, David Brown <david.brown@hesbynett.no> wrote:
>> On 06/02/14 19:09, Piergiorgio Sartor wrote:
>>> Hi all,
>>>
>>> this question is only partially related to Linux MD,
>>> but since the experts are here, I think it would not
>>> be a big problem to ask here.
>>>
>>> I'm considering a storage system.
>>> This is based on HDD "rust".
>>> It should have RAID-6, for protection agaist disk
>>> failure(s).
>>> It should have LUKS (or similar), in order to simplify
>>> HDD disposal (disk that are still somehow readable will
>>> not need to be wiped out before dumping them).
>>> It should have LVM, as flexible partition system.
>>>
>>
>>
>> It strikes me as a bad idea to use encryption of any sort "to save time
>> when dumping old disks".  Physically destroying hard disks is not /that/
>> hard.  Unless you are keeping plans for a nuclear missile, then a few
>> whacks with a hammer will be good enough.  Breaking the electronics
>> means it costs many thousands of dollars to get the data off the disk
>> again - you don't even need to open the drive and get out the platters
>> (opening the drive is time-consuming - destroying the platters after
>> opening is easy).  And with raid, little of the data on the disk is
>> intelligible unless you have the full stripe (minus parity) - just ask
>> anyone who has tried to recover from one too many disk failures.
>>
>> And of course, just dd'ing /dev/zero to the first few MB of the disk
>> will make it unreadable for most hackers - even if they have all the
>> disks in a set, and know how they were configured.  And you could donate
>> the old disks to windows users - then they are guaranteed unreadable!
>>
>> Disk encryption slows everything down, and adds lots of complications to
>> the system.  It is less of an issue with drives with built-in
>> encryption, but still a complete waste of time and money if all you want
>> is "safe" disposal of old disks.
>>
>> The /only/ thing disk encryption is useful for is if you fear the disks
>> will be physically stolen by someone who is after your data (or customs
>> guards in dodgy countries, which amounts to the same thing).  So if you
>> fear that your company will be the target of top-range thieves who will
>> steal your disks for the data, then encryption is a good idea.  Of
>> course, better locks and alarm systems would be a better investment.
>>
>>
>> Once you have eliminated the "E", then I believe HRL is the common
>> arrangement, although sometimes you also do physical partitioning of the
>> disks first, so that you can have different bits with different raid
>> types.  A multi-way raid1 partition first for /boot can make booting
>> easier, a set of raid1 pairs works well for swap (for emergency use
>> only), and then the rest of each disk makes up your raid6 array.
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  parent reply	other threads:[~2014-02-07 16:11 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
2014-02-07 15:45       ` Roberto Spadim
2014-02-07 16:11     ` David Brown [this message]
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=52F505B3.2050902@hesbynett.no \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.