I have 2 hard drives 3TB each. The first of these drives is full with very important content. I have encrypted the second 3TB drive using the following technique:


and have copied the files from the non encrypted first drive to the encrypted second drive. I now want to encrypt the first drive. How do I go about doing that? It has content in it, so I am assuming if I use the above link to encrypt it, the drive will be wiped?

  • 1
    Yeah, you will most likely lose the contents when you add encryption to it, but isn't that why you copied all the files from the first drive to the second driver in the first place? So that the first drive is now free to be reformatted? BTW: best if you copy&paste the (textual) procedure or at least link to it. Speaking personally, I'm not inclined to go over to Youtube and watch a video in order to understand your question.
    – Celada
    Jul 18, 2014 at 22:02
  • @Celada, I copied the files from the first to the second drive to create a backup of the first drive. Now I want to encrypt the original. Jul 18, 2014 at 22:17
  • Similar question: Is there a way to encrypt disk without formatting it? May 4, 2020 at 20:23
  • 1
    Can't you just replace this youtube link with a 1 to 3 sentence summary of what you actually did? May 4, 2020 at 20:24

2 Answers 2


What you should do is securely wipe the original drive to remove any unencrypted data, then set up encryption and copy files over.

First you will want to make sure your backup is correct, since you will be wiping the original drive completely. Wipe the drive using a command such as the following:

# dd if=/dev/urandom of=/dev/sdX bs=4096

where sdX is the drive you want to wipe. You may want to use /dev/zero instead of /dev/urandom, because urandom will take much longer, though it is more secure. More information on this can be found here. Make sure you wipe the right drive, preferably removing the other drive so you cannot possibly corrupt it.

Note that it is impossible to recover data wiped this way (which is the point).

Once you have securely wiped the disk so that no unencrypted data remains, you can set up encryption and copy data over.

  • Wiping a disk with urandom takes ages. Encrypting it with a random key and then wiping that with zeroes is considerably faster, and if you're OK with pseudorandom data you can just use shred -n 1. Jul 25, 2014 at 17:16

Encrypting in-place is possible, but dangerous. It's easier by far to just wipe / format / mkfs it, and repopulate it with files from elsewhere.

For the in-place approach, first you have to shrink the filesystem by at least 2MiB to make room for the LUKS header at the beginning of the drive. For safety, shrink it a bit more than that.

Then you have to keep in mind that due to the LUKS header, all data on the encrypted container has at least a 2MiB offset. Thus, a linear dd copy of the unencrypted to the encrypted container will not work, as each write would overwrite data that has not been read yet.

To avoid that, the copy operation has to run backwards. There is no direct support for that in dd, but you can emulate it using seek=$x skip=$x count=1 in a backwards loop that decrements $x by one in each step until $x=0.

Example using device /dev/sdx1 with ext4 filesystem:

# make sure it's not mounted anywhere
umount /dev/sdx1
# backup the first 128MiB somewhere
dd bs=1M if=/dev/sdx1 of=/somewhere/sdx9.backup count=128
# shrink filesystem by 128MiB
resize2fs /dev/sdx1 $(($(blockdev --getsize64 /dev/sdx1)/1024/1024-128))M
# create encryption layer
cryptsetup luksFormat /dev/sdx1
cryptsetup luksOpen /dev/sdx1 luksx1
# dd backwards using GiBs of memory. Change math and bs for less memory usage.
for x in $(seq $(($(blockdev --getsize64 /dev/sdx1)/1024/1024/1024+1)) -1 0)
    dd bs=1G iflag=fullblock seek=$x skip=$x count=1 \
       if=/dev/sdx1 of=/dev/mapper/luksx1
# include backup for region previously overwritten by LUKS header
dd bs=1M if=/somewhere/sdx9.backup of=/dev/mapper/luksx1
# grow filesystem to full size
resize2fs /dev/mapper/luksx1

Before doing this, test the procedure with a temporary device first.

If the procedure is cancelled at any point, it's pretty much a lost cause, since you end up with a half-encrypted thing.

There are frontends that pretty much use the same method. cryptsetup itself has a reencrypt-program, or you could try your luck with http://www.johannes-bauer.com/linux/luksipc/ . I prefer the manual approach simply because I understand how it works and what can go wrong.

  • The bs=1G looks inefficient. As of 2020, cryptsetup itself features a reencrypt subcommand which arguably is better tested and less error-prone then the above steps. It also supports user interruption and has some recovery features. May 4, 2020 at 20:31
  • @maxschlepzig large blocksize, while counter-productive when reading/writing to different (physical) devices, it actually helps performance when reading from and writing to the same device (with HDDs) as it drastically reduces the number of seeks. May 4, 2020 at 21:10
  • @maxschlepzig the reencrypt subcommand didn't exist when this answer was written and besides, I like to understand how things work :-) feel free to write a new answer May 4, 2020 at 21:14
  • In terms of efficiency, I just did a mini benchmark, and cryptsetup reencrypt seems to be the slowed, followed by cryptsetup-reencrypt and finally dd bs=1G being considerably faster despite being a lousy shell script with many calls to dd. But of course it is an unfair comparison since the dd method does not do any book keeping whatsoever, and is difficult to resume (if it crashes mid-write, you lose $luks_data_offset worth of data) May 4, 2020 at 21:53
  • I can confirm that cryptsetup reencrypt is relatively slow. Perhaps it will be optimized in future versions. Until then I would prefer restoring a backup into a fresh LUKS device instead of using reencrypt when dealing with larger filesystems. May 5, 2020 at 19:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .