dm-crypt.saout.de archive mirror
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Help request
Date: Wed, 8 Jul 2020 01:43:17 +0200	[thread overview]
Message-ID: <20200707234316.GB24459@tansi.org> (raw)
In-Reply-To: <a18449a3-644e-4478-96dc-268ed9a5d70c@localhost>

On Tue, Jul 07, 2020 at 22:58:14 CEST, Michael Kjörling wrote:
> On 6 Jul 2020 03:36 +0000, from lacedaemonius1@protonmail.com (lacedaemonius):
[...]
> > I don't think it's a drive failure because it's only a few months
> > old and I haven't got any SMART warnings, so that leaves software.
> 
> Unfortunately, drives can fail without reporting failures in SMART
> data, and they can fail early. While the probability of either is
> _lower_, it is non-zero.

There are some numbers from IBM that say that drives fail about 50% 
of the time without a failed SMART status. These are old numbers,
not sure how much they apply these days.It alsois a good idea to 
mionitor SMART attributes directly and not only check for a failed 
status.

One thing to do is to run a long SMART selftest (basically a more
sophisticated variant of scanning the surface yourself). It does
read the whole surface to check for read errors:

 smartctl -t long <drive>

Depending on drive size, this can take a long time. It also makes
sense to look at the SMART attributes manually, a drive will
get a failed SMART status only when things are really bad.
But you often can see what is going on anyways.
This gives you the attributes:

 smartctl -a <drive>

Post the results here if you are unsure how to interpret them.

[...]

> The fact that the LUKS container was not closed _should_ not cause any
> issues after a reboot, because closing the container really just
> removes bookkeeping information and cryptographic keys from kernel
> memory; it doesn't affect on-disk data. 

In fact, LUKS data never gets written in normal operation. Hence
it is not actually "opened" as far as the on-disk status is concerned.

> > Is it worth making any attempt at trying to recover the drive and if
> > so is there any documentation that explains what to do? I don't have
> > a backup of the LUKS header, if that's the problem.
> 
> Do you have a recent backup of the data on the drive, or does the
> drive that is giving you problems hold the only copy? Is it data that
> you care a lot about, or can it be easily restored from other sources?
> (This basically boils down to: how important is it to rescue the data
> in-place?)

If this is broken hardware in the drive (and it looks like it), this 
will be something you likely cannot do yourself and it will be really 
expensive. It will also fail unless a valid keyslot gets recovered 
fully. It may be a broken controller or even some other hardware 
damage on the system you are trying to read the disk, so it may be 
worthwhile trying to read it somewhere else. 

The detailed SMART status should tell more though.

Regards,
Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

  reply	other threads:[~2020-07-07 23:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-06  3:36 [dm-crypt] Help request lacedaemonius
2020-07-07 20:58 ` Michael Kjörling
2020-07-07 23:43   ` Arno Wagner [this message]
2020-07-08  0:43   ` Robert Nichols

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=20200707234316.GB24459@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.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).