This is a complicated question, and made more so by the availability of RAID and LVM. I will try to give some scenarios and
discuss advantages and disadvantages. Note that I say LUKS for
simplicity, but you can do all the things described with plain
dm-crypt as well. Also note that your specific scenario may be so
special that most or even all things I say below do not apply.
Be aware that if you add LVM into the mix, things can get very complicated. Same with RAID but less so. In particular, data recovery
can get exceedingly difficult. Only do so if you have a really good
reason and always remember KISS is what separates an engineer from an
amateur. Of course, if you really need the added complexity, KISS is
satisfied. But be very sure as there is a price to pay for it. In
engineering, complexity is always the enemy and needs to be fought
without mercy when encountered.
Also consider using RAID instead of LVM, as at least with the old superblock format 0.90, the RAID superblock is in the place (end of
disk) where the risk of it permanently damaging the LUKS header is
smallest and you can have your array assembled by the RAID controller
(i.e. the kernel), as it should be. Use partition type 0xfd for that.
I recommend staying away from superblock formats 1.0, 1.1 and 1.2
unless you really need them. Be aware that you lose autodetection with
them and have to fall back to some user-space script to do it.
Scenarios:
(1) Encrypted partition: Just make a partition to your liking, and put LUKS on top of it and a filesystem into the LUKS container. This
gives you isolation of differently-tasked data areas, just as ordinary
partitioning does. You can have confidential data, non-confidential
data, data for some specific applications, user-homes, root, etc.
Advantages are simplicity as there is a 1:1 mapping between partitions
and filesystems, clear security functionality and the ability to
separate data into different, independent (!) containers.
Note that you cannot do this for encrypted root, that requires an initrd. On the other hand, an initrd is about as vulnerable to a
competent attacker as a non-encrypted root, so there really is no
security advantage to doing it that way. An attacker that wants to
compromise your system will just compromise the initrd or the kernel
itself. The better way to deal with this is to make sure the root
partition does not store any critical data and move that to additional
encrypted partitions. If you really are concerned your root partition
may be sabotaged by somebody with physical access (that would however
strangely not, say, sabotage your BIOS, keyboard, etc.), protect it in
some other way. The PC is just not set-up for a really secure
boot-chain (whatever some people may claim).
(2) Fully encrypted raw block device: For this, put LUKS on the raw device (e.g. /dev/sdb) and put a filesystem into the LUKS
container, no partitioning whatsoever involved. This is very suitable
for things like external USB disks used for backups or offline
data-storage.
(3) Encrypted RAID: Create your RAID from partitions and/or full devices. Put LUKS on top of the RAID device, just if it were an
ordinary block device. Applications are just the same as above, but
you get redundancy. (Side note as many people seem to be unaware of
it: You can do RAID1 with an arbitrary number of components in Linux.)
See also Item 2.8.
(4) Now, some people advocate doing the encryption below the RAID layer. That has several serious problems. One is that suddenly
debugging RAID issues becomes much harder. You cannot do automatic
RAID assembly anymore. You need to keep the encryption keys for the
components in sync or manage them somehow. The only possible advantage
is that things may run a little faster as more CPUs do the encryption,
but if speed is a priority over security and simplicity, you are doing
this wrong anyways. A good way to mitigate a speed issue is to get a
CPU that does hardware AES.
Best Answer
Long long time ago...
... There was a time when people used to install Linux and configure it by hand for their specific needs. Some of this is true even today for servers. The choices you see in
gpartedare some of the popular ones for those who had very different needs as compared with the average desktop users, the intended audience for Ubuntu desktop.Let us take these one at a time. I will skip the ones I don't know much about.
/bootthere was a time when the Linux file system was fragile and hard drives were small. People were afraid that the hard drive would fill up or get corrupted and Ubuntu won't boot. Keeping the kernels in a separate partition helped the system to boot when other things went wrong. In those days Linux users used to compile their own kernel and clean up old ones. As recently as with Ubuntu 16.04 LTS, the Software Updater app installed the latest kernel update but did not remove the old kernels. As a result, a small/bootpartition filled up with old kernels and the system stopped booting unless one cleaned it periodically. See what happened if you had a separate/bootpartition and forgot to clean it regularly: How do I free up more space in /boot? With Ubuntu 18.04 LTS the Software Updater app not only keeps the system up-to-date, but also removes the old kernels. It keeps the last two kernels in case the latest kernel has some issues and one needs to revert back the previous one./partition (to safeguard the secret software you are working on), you will need a separate (and unencrypted)/bootpartition. Otherwise the system won't boot. Similarly, if you have a RAID drive, keeping/bootin a non-RAID partition may be useful. Many people thinks having a separate/bootpartition is a very good idea for these and other reasons./homeKeeping home in a separate partition still makes some sense. This folder/partition has your personal files and having it in a separate partition allows you to format/and reinstall Ubuntu while keeping your files untouched. Recent versions of the Ubuntu installation software includes a choice of update from DVD/USB. This option keeps/homeintact even it it is not on a separate partition. If you run out of space in your primary drive with/partition. You may want to add a new drive and create a single/homepartition in the new drive./tmpis where temporary files go. If you are running a server that creates large temp files, they may fill up all the disk space and bring your server to a halt. Keeping it in a separate partition will only fill up that partition and may stop the process that was creating the big temp files but will not stop the rest of the system. I am told it is easier to deal with a filled up/tmppartition than a temporary folder under/partition./usr/,/opt/, and/usr/localare all places where programs and apps are kept under different conditions. If you develop software for Linux, it may make sense to keep these in separate partitions, so that if you reinstall Ubuntu, you won't delete the programs you have written or have been working on./opt/and/usr/localin separate partition also makes sense if you install programs from source (your own or from somewhere else) and want to use them in another distribution (say Red Hat) installed in the same computer in its own partition. Then both the distributions, Ubuntu and Red Hat can share the/optand/usr/localpartitions. (Thanks Rmano!)/srvand/varare particularly useful as separate partitions if you run servers or develop web pages. For the average desktop user these folders don't take up much space and does not hold anything that is of value to the user. For a web developer losing/var/wwwmay mean losing her job.To be sure, these are not the only directories one can mount as partitions. In Linux, one can mount a partition as any folder anywhere. Partitions are often mounted as sub-directories of
/mnt/and/media.Hope this helps