(I’m not sure which category this post should go in.)
I suppose that the FreedomBox image uses a single partition because it makes installation and administration easier. Since it does not offer partition options, I prefer to start by installing Debian.
Some new features offered by the Debian 13 installer are:
The option to select blends such as FreedomBox from the start, which will trigger a dialog box that may need to be skipped.
The option to select a different partition scheme for the server, which may be suitable for certain FreedomBox use cases.
The default schemes in Debian relevant to the server are:
separate /, /home, /var, /tmp;
separate /, /srv, /var.
My use case is a minimal server with maximum functionality for occasional visits from external users and for use by a few internal users.
The Filesystem Hierarchy Standard assigns /srv for service data offered by the system that is not essential for the operation of any program or reserved for use by any particular user, while /home is intended for users’ personal use.
It is recommended to separate partitions where users have write permissions to prevent fill-up attacks. Will /home become more relevant and deserve its own partition?
It is recommended to separate dynamic data from static data into different partitions. Has the confusion in /var and other directories justified the creation of /svr?
Perhaps a small static website in /svr/www instead of /var/www/html and a large number of static files in /svr/ftp instead of /var/lib/freedombox/shares.
I would like to know what you recommend based on your experience and use case.
An important consideration for partitioning is btrfs snapshots. That means the simplest layout with a single partition is the best as the entire filesystem will remain consistent if a snapshot is restored. Also, if available disk space is split into partitions, it unnecessarily restricts the system to certain use cases. For example, if large store is allotted to /home in anticipation of user storing a lot of files, it might go unused entirely on systems that are only used for hosting services.
Notes:
Each partition typically has some space reserved for root which can’t be filled up by other users. This allows root to login and perform most operations without running of disk space. This could still be a problem for all the daemons that don’t run as root user.
Quotas can help with preventing users from filling up disk space.
/tmp is tmpfs (in RAM) and managed by systemd. It usually does not require a separate partition.
Exceptions:
It might be a good idea to have /home to be separate partition even for btrfs snapshots. Since we likely don’t want to restore that data.
If you are on an UEFI system, /boot/efi must be a fat32 file system.
If you are on an Raspberry Pi, first partition must contain the Raspberry Pi GPU firmware.
In future, we plan ship read-only operating system images. In this case, the partition setup will be more complicated. Root (/) will be read-only. There will be a second copy of root partition that will be used for atomic updates. /var, /home, and /etc will be read-write.
@Sunil, my machine is x86-64. I decided to reinstall my system (I didn’t manage the snapshots well), so your precision is very helpful. I appreciate it.
My partition scheme so far is 1 (although with LVM), and I checked that, as you say, /home was an almost useless partition, because most of the files served are for all users. That’s why I’m considering scheme 2.
I was thinking of dedicating /svr to serving those common files (media and library) that require the most storage and more direct access from sftp. There won’t be much else. I would set quotas for /home, since it would be on the same root partition. My concern about possible inconsistent btrfs snapshots is the separation of /var in this scheme.
As for backups, although snapshots would not cover it if it were, for example, a separate xfs partition, I suppose I could configure Borg to automatically back up the bulk data in /svr.
I find the FHS argument for clearly separating non-exposed data from exposed services convincing. But I could still do it on a single partition, if this does not weaken security or performance.
After researching the capabilities of btrfs and considering the @Sunil’s suggestions and clarifications, I recognize that a single btrfs partition is the most suitable configuration for a server, due to data security and ease of management. So that’s what I did.
My previous configuration was wrong for my case: physically separating /var can cause inconsistencies when recovering a snapshot of /. And, for resizing capabilities on partitions, I had configured LVM, whose task can be replaced by btrfs.
However, btrfs protection implies a loss of sequential read/write performance in large multimedia files (compared to xfs and even ext4) that I intend to serve from /svr. Can I safely create a subvolume of /svr to set quotas, separate this directory from system snapshots, and disable features such as verification or compression, if it makes sense?
I recognize that a single btrfs partition is the most suitable configuration for a server, due to data security and ease of management. So that’s what I did.
Try the single btrfs filesystem. I bet it will be good enough. Then do this…
@joseph Thanks for the info. I’ll try the tool.
I still need to set up subvolumes. If there are no significant risks (apart from the dreaded RAID configurations and those pointed out by Debian), I will rely on the official documentation to separate /srv from the rest of the system to the extent that btrfs allows me to do so.
You don’t have to do anything with btrfs. Seriously don’t worry about sub volumes unless you want to learn about all that.
Do the maintenance, don’t keep too many snapshots. That is all you need to do.
You can reduce the frequency of snapshots using the Freedombox snapshots app. I keep a few - maybe one yearly, a couple monthly, and a maybe a couple daily or something. I don’t use the reboot or software installation snapshot myself.
It has been reliable and not been a performance problem that way for me.