I would advice against using SSDs for storage of media and such. Not only because of their higher price, but also because flash memory cells tend to fade over time, causing read speeds to decrease considerably over time. This is particularily the case for mostly read-only workloads. For each read operation the flash memory cell being read loses a bit of its charge. Eventually the margin for the controller to be able to read the data will be so small, that it takes the controller lots of read operations to figure out the correct data. In the worst case this can lead to the SSD controller being unable to read some data alltogether.

No, tmpfs is always located in virtual memory. Have a look at the kernel documentation for more information about tmpfs.

It is. It might end up on disk in swap, if you run low on memory (and have some sort of disk-based swap enabled), but usually it is located in RAM.

Try diasbling the second DHCP server altogether. You only need one, since you have a flat network.

Are you sure there is exactly one DHCP server running?

I’m exclusively running unprivileged LXC containers and haven’t had any issues regarding the firewall, neither with iptables nor nftables.

No, it is not like Docker. You can treat an LXC container pretty much like a VM in most instances, including firewall rules. To answer the question, you can use fail2ban just like you had done in your VM, meaning you can run it inside the LXC container, where fail2ban can change the firewall rules of that container as it sees fit.