All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Schniedermeyer <ms@citd.de>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] question
Date: Fri, 12 Dec 2014 13:59:10 +0100	[thread overview]
Message-ID: <20141212125910.GA3470@citd.de> (raw)
In-Reply-To: <20141212121108.GA29099@tansi.org>

On 12.12.2014 13:11, Arno Wagner wrote:
> On Thu, Dec 11, 2014 at 23:04:53 CET, Matthias Schniedermeyer wrote:
> > On 11.12.2014 18:30, Sayler, Craig A. (AFRC-MI)[InuTeq, LLC] wrote:
> > > Is there a way to decrypt a drive permanently with out reinstalling?
> > 
> > Yes.
> > 
> > But the much safer way is:
> > Backup, make a new filesystem on the previous backing-device & Restore 
> > from backup.
> > 
> > 
> > The unsafe(!) 'inplace' method (that as an advantage doesn't need 
> > additional storage):
> > Just open the container normally, 'dd' the mapped container over the 
> > backing device and pray that process isn't interruped. Because it will 
> > be a huge PITA if it gets interruped.
> > 
> > 
> > But don't risk it, Backup & Restore is the way this should be done.
> 
> Interesting approach! Should work though. But you are right that this
> is very high risk.

Standard Unix methodology, i would say.

I did something similar, in reverse (unencrypred -> encrypted), some 
years ago.
Altough i wrote me a script that did the work in steps, so i could 
resume it if it ever got interrupted. (Better safe than sorry. In the 
end it wasn't interupted. But that's Murphy's Law: If you are prepared, 
nothing will happen.)

The script did something like this:

for each block
do
  copy source to other stable storage
  fsync
  update state information
  fsync
  copy block from other stable storage to target
  fsync
  update state information
  fsync
done

The detour is necessary to recover from a partial copy in the last step, 
otherwise you would need to determine the exact spot (and hope the HDD 
didn't do a partial sector write) to restart the process.





-- 

Matthias

  reply	other threads:[~2014-12-12 12:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-11 18:30 [dm-crypt] question Sayler, Craig A. (AFRC-MI)[InuTeq, LLC]
2014-12-11 22:04 ` Matthias Schniedermeyer
2014-12-11 22:07   ` Sayler, Craig A. (AFRC-MI)[InuTeq, LLC]
2014-12-11 22:54     ` Matthias Schniedermeyer
2014-12-12 12:12     ` Arno Wagner
2014-12-12 12:11   ` Arno Wagner
2014-12-12 12:59     ` Matthias Schniedermeyer [this message]
2014-12-13  0:21       ` Arno Wagner
2014-12-14 18:15   ` Milan Broz
2014-12-14 20:23     ` Arno Wagner
  -- strict thread matches above, loose matches on Subject: below --
2011-05-26 20:17 Guy Rachmuth
2011-05-27 12:14 ` Arno Wagner

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=20141212125910.GA3470@citd.de \
    --to=ms@citd.de \
    --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 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.