I've been setting up a few LUKS encrypted drives and noticed that I've been creating the encrypted disk directly on the 'raw'(?) drive, ie. /dev/sdb, while many examples via google are showing it created on /dev/sdb1
Example using /dev/sdb:
# cryptsetup luksFormat /dev/sdb
# cryptsetup luksOpen /dev/sdb lvm_backup
..and then following on with creating volume groups and logical volumes like so:
# vgcreate vg_backup /dev/mapper/lvm_backup
# lvcreate -l +100%FREE lvm_backup -n backup
# mkfs.ext4 /dev/mapper/vg_backup-backup
and finally mounting the drives.
This leave me with a lsblk looking something like this:
sdb 8:16 0 2.7T 0 disk
lvm_backup (dm-3) 252:3 0 2.7T 0 crypt
vg_backup-backup (dm-5) 252:5 0 2T 0 lvm /backup
In contrast, other lsblk output looks like:
sdb 8:16 0 2.7T 0 disk
sdb1 #:# 0 2.7T 0 part
lvm_backup (dm-3) 252:3 0 2.7T 0 crypt
vg_backup-backup (dm-5) 252:5 0 2T 0 lvm /backup
What are the advantages/disadvantages of working directly on the disk (/dev/sdb) vs creating a partition (/dev/sdb1) first?
I'm assuming this is probably somewhat related to:
https://serverfault.com/questions/338937/differences-between-dev-sda-and-dev-sda1
Best Answer
Offhand, I'm thinking that if your using the entire device (
/dev/sdb
) and your LUKS header is at the start of the drive, and if some other tool or OS "helpfully" decides that your disk is unformatted with no MBR or GPT, if it were to overwrite your LUKS header that would be bad. If you were using a partition for LUKS then at least a new MBR or GPT wouldn't be as devastating.You should always backup the LUKS header anyway, as the
cryptsetup
man page advises too.And this is what the cryptsetup FAQ says about using "2.2 LUKS on partitions or on raw disks?" (it's long but I'll just paste it, mentions RAID & LVM can greatly complicate things, you may want to rethink using LVM on top of LUKS):