I currently have an unencrypted external hard drive that I use as a backup for my encrypted (with LUKS) main machine. To update my backup, I simply log in to the main machine and rsync to my external hard drive. Clearly, having an unencrypted backup for material that was worth encrypting in the first place is a bad idea. However, due to time constraints, I am unable to regularly update my backup without the help of something like rsync. It follows that any encryption method that I use on the external drive must be compatible with rsync. However, I have ran in to the following issues:

  1. Userspace stackable encryption methods like EncFS or eCryptfs appear to both take up a lot of space and not play nice with rsync. The hidden files reponsible for the encryption seem to change frequently enough that rsync ends up having to copy so many files that it's barely worth even using rsync.
  2. luksipc would be an option, but it's latest documentation tells me to instead use the the cryptsetup-reencrypt tool from dm-crypt. Sadly, whenever I look up the relevant documentation on the arch wiki for cryptsetup-reencrypt I can neither tell what to do, nor if it'll work with rsync. The cryptsetup-reencrypt tool also seems to be new enough that it's hard to find doccumentation on it that someone at my level can read.
  3. Plain LUKS, or anything similar isn't an option, because the earlier mentioned time constraints prevent me from being able to wipe the drive and make the backup again from scratch.
  4. Duplicity could be an option, but it doesn't seem able to encrypt any unencrypted files that are on the external hard drive (i.e. where it's copying to).

Overall, it looks like #2 might be my best option for the goal of encrypting my external drive and keeping that drive up to date with rsync, but I don't really know where to begin and I'm not very open to the possibility that I might have to wipe the drive before encrypting it. Am I missing anything useful?

  • 1
    What's the problem with just unlocking the LUKS partition, mounting it, and then running rsync?
    – Xen2050
    Mar 17, 2019 at 16:24
  • @Xen2050 The only LUKS partition that I have is on my main machine. Copying an unlocked version of that on to my external drive is what I'm already doing, i.e. a method resulting in unencrypted output.
    – J. Mini
    Mar 17, 2019 at 16:38
  • 1
    Similar question where an existing unencrypted root filesystem needs to be encrypted: Is there a way to encrypt disk without formatting it? May 4, 2020 at 20:13

2 Answers 2


Nowadays cryptsetup itself supports non-destructively transforming an unencrypted partition into a encrypted LUKS device with the reencrypt subcommand.

Assuming that your external drive is accessible via /dev/sdX and the current filesystem is located on /dev/sdXY you need first shrink the filesystem to make room for the LUKS header and some scratch space for the encryption operation (32 MiB works). The exact command depends on you filesystem, e.g. for ext4:

e2fsck -f /dev/sdXY
resize2fs /dev/sdXY NEWSIZE

(Note that XFS doesn't support shrinking, thus you would need to fstransform it first ...)

Trigger the encryption:

cryptsetup reencrypt --encrypt /dev/sdXY --reduce-device-size 32M

Enlarge the filesystem again:

cryptsetup open /dev/sdXY backup
resize2fs /dev/mapper/backup
cryptsetup close backup

(without a size argument resize2fs uses all available space)

Since you don't change the content of you existing filesystem you can continue using rsync. Instead of something like

mount /dev/sdXY /mnt/backup
rsync -a /home /mnt/backup
umount /mnt/backup

you now have to do something like:

cryptsetup open /dev/sdXY backup
mount /dev/mapper/backup /mnt/backup
rsync -a /home /mnt/backup
umount /mnt/backup

Since you mention your time constraints: cryptsetup reencrypt isn't necessarily as fast as a cryptsetup luksFormat followed by a fresh rsync.

An alternative to the above is to switch to Restic for your backup needs. Restic encrypts all backups, supports incremental backups and is very fast.

If your external drive is large enough you can start with Restic by initializing a Restic repository in a new subdirectory. After the first Restic backup is finished you can remove the old unencrypted backup files. Finally, you have to wipe the free space to destroy any traces of the old unencrypted backup files.

  • It's very odd that a requirement for encrypting my external drive is to shrink the file system on my main drive.
    – J. Mini
    Jul 25, 2020 at 20:16
  • @J.Mini What do you mean? In my answer I'm just referring to the external drive. The shrinking of the existing filesystem on the external drive is necessary because of a) the LUKS encrypted device needs some space for a LUKS header which contains some meta data and key slots and b) the cryptsetup reencrypt command needs some scratch space for its operation. Jul 26, 2020 at 8:29
  • I must be misunderstanding the distinction between dev/sdX and dev/sdXY
    – J. Mini
    Jul 26, 2020 at 9:20
  • 1
    @J.Mini it's whole device vs. the partition the filesystem is located on that device - if the device contains a partition table. If there is no partition table then /dev/sdXY == /dev/sdX. Jul 26, 2020 at 17:15

I think I see the main problem now, it's just:

"How do I encrypt a drive that already has data on it?"

There's only one safe answer, whether you're using LUKS or eCryptFS or EncFS, or basically anything:

  1. Backup the data somewhere else
  2. Encrypt the drive (erasing / overwriting the now backed up existing data on it)
  3. Copy the data to the now encrypted drive
  4. Verify that you can decrypt (unlock) the drive, and that the data is unchanged

For your case, if you wanted to use LUKS on the backup drive, and if the backup drive is less than half full, you could:

  1. create a free partition in half the drive
  2. encrypt the free partition with LUKS
  3. copy your data from the unencrypted partition to the LUKS partition
  4. delete the unencrypted partition
  5. then expand the LUKS partition over the entire drive...

BUT one of those partition shrinking & enlarging operations will most likely require moving data, and to be safe you should have a backup first, so you're stuck with just doing the earlier "Backup the data" step anyway.

The same goes if you're considering a LUKS encrypt-in-place solution (lukspic or cryptsetup-reencrypt) - if it's important data, have a backup first.

  • Since this is already a backup drive, you might be able to use the original drive as a pseudo-backup, and just erase the whole drive, use LUKS, and then make a fresh backup from the original drive

Or, if you don't care if the data were to get deleted, then go ahead and try an encrypt-in-place solution, or move partitions back & forth, just don't be shocked if something goes wrong & everything gets deleted.

  • I've made an edit to reflect this, but you've missed something - the reason why I'm using rsync is because my time constraints prevent me from making a new backup from scratch. However, if memory serves my recent modifications to my backup has rendered the backup drive less than half full, so your answer might be usable.
    – J. Mini
    Mar 20, 2019 at 23:26

You must log in to answer this question.

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