There are many advices how to partition your hard-drives/SSDs on a small server. However I have learned a lesson which I want to share with you, so you won’t do the same mistake. I do not want to tell you exactly how much space to reserve for what partition under particular OS.
Separate /var /usr and /root or not?
For desktop, you do not need it, for small server – it depends… I’m from “old school” when we used to have separate partitions for /root /usr and /var, however times are changing and differences between these partitions are diminishing. Why? Because for example consider you run virtual machines. These include /usr code, but images are stored in /var. Also consider for example DNS server bind – your domains will be stored in /var/named. Not to mention if you run named-chroot, then even your /etc/named configuration will actually be stored in /var partition. Also I do not think there is any risk of running out of space of the /usr partition and by combining partitions together – you actually save the storage space. So I would not go for separate root /usr and /var anymore. Also there is an argument to mount /var with noexec,nodev,nosuid flags, however you will run into problem with most of the chroot implementations (postfix/named etc…), so if you use chroot, you cannot do it anyway… I also tried to search for another arguments for separate /var – I cannot find them – or more precisely – I cannnot find an explanation how will the full root (+usr) partition harm the system? For example Debian manual says
"Any partition which can fluctuate, e.g. although it mentions other factors as well – it doesn’t explain why… The only advantage of separate /var (but not /usr) under CentOS I can see is that you can mount it with nosuid flags – as mentioned in CentOS Wiki.
/var/log) should also be on a separate partition." -
Separate /home however is a good practice. And separate /tmp – maybe or use tmpfs with noexec,nodev,nosuid flags.
I suggest – follow the advice of your OS/distribution, but also consider your requirements and restrictions – for example – answer the questions:
1.What storage do you have / plan to buy – SSDs or HDDs?
2. Do you want to use software(hardware) raid? (and what type do you want/can afford – 1 or 5 or…)
3. What file systems do you want to use? LVM+EXT4 or BTRFS or even ZFS? You need to consider point 1 here as well.
4. Do you want to use encryption? If yes, what type – only “home”/”data” or full disk encryption? If you decide to go for full disk – please note you will have to enter password on each reboot.
Now I have two advices here:
Advice 1 – why to use encryption: Consider you harddrive or ssd which fails. You need to send it to manufacturer for replacement if it is under warranty or you need to throw it away if it is out of warranty. Please note that even if harddrive/ssd is faulty, it is still possible to obtain data from it. You also do not know what will manufacturer do – they may fix electronics and resell it as refurbished… You know when files are deleted on harddrives/SSDs, they are just “unlinked”, but data are still stored on the media, so this is the reason why to encrypt your storage.
Advice 2 – Create “shadow” system – No matter how you split partitions, for your system, I suggest you to create it twice – or at least reserve the same amount of space and structure as you reserve for your system. An example – Let’s say you go for full storage encryption – well – it is never “full” as you need to boot from something which is not encrypted, so your /boot will stay unencrypted. So if you are partitioning your storage space – reserve for example 1.5GB for /boot and reserve the 1.5GB for another /boot (you do not have assign mount point at that time – you will do it later). Also please note, that especially for /boot the more is better – OSes seem to increase minimal /boot requirements frequently. And then when you for example reserve 30GB for the rest of your system, create additional 30GB partition as well. Also repeat this for any other system partition you decided to have on separate partition. This will allow you to “clone” your existing system partition into the backup partitions and the only thing you need to update in order to boot from backup is grub (also if your system uses UUIDs, then you need to change UUIDs manually after cloning). If you decide you can even install new system into the backup area.
Problem with my server I encountered is that by using LVM on top of luks, I found it is not trivial to resize physical LVM volume and even less trivial to resize luks partition…
Let me know your experience… But as I have to sort it out, my next post can be about it…
Let me know your thoughts or comments.