Whats the best configuration for a Backup and Media server in Proxmox?

[EfrenIZV]

Hello im creating a homelab and im wondering what would be the best solution.
I have Proxmox installed in a mirror of 2 120GB SSDs and a RaidZ (aka ZFS raid 5) with 3 2TB hard drives and I store everything in the RaidZ pool.
The idea is using Samba, NextCloud and Jellyfin to create a files and media server.
The best idea i had is using CentOS containers so i have the native ZFS performance and dont need to use VirtIO in a VM and then install them on top of another filesystem.
I saw another thread about making a NAS in Proxmox and they talked about creating a mountpoint to store the data in a Samba container.
My question is why would i need to create a mountpoint apart from the main container volume, and what would be a good way to manage the storage? Whats the mountpoints security (the ones created with the GUI)?

For example;

/pool/local (files that i only want to be accesible by the devices in the local network with Samba)
/pool/cloud (files that i want to be accesible by users from nextCloud)
/pool/media (files that are not sensible and anyone can see in jellyfin)

or

/pool/data (a single mount point shared by the 3 containers??)

or just use the same volume that is created for the container as i thought?

The idea is that users have a device in the local network and they use Samba to back up their files in the server. Also the users have another device at work or the study place so instead of having to use a paid cloud or storing in a usb drive everytime, they save the work using NextCloud so later they can continue working at home. (I know you can add a Samba share from NextCloud but i dont want that because if someone gained access to a NextCloud user from internet they would be able to delete all the backed up files). Finally both people from internet and home could access the files in the media server (those files are movies, music..)

Thanks!

 

[Alwin]

I saw another thread about making a NAS in Proxmox and they talked about creating a mountpoint to store the data in a Samba container.
My question is why would i need to create a mountpoint apart from the main container volume, and what would be a good way to manage the storage? Whats the mountpoints security (the ones created with the GUI)?

If other services need access to the data but are not installed in the same container. And the use of NFS/SMB is not an option. I don't think this is the case for your setup.

 

[fortechitsolutions]

Footnote for what it may be useful?

I would suggest, decide what is most important for your deployment, and focus on meeting that requirement. Don't assume you can meet all requirements perfectly, including perfect flexible option towards all future possible scenarios.

So if your goal is to have a nextcloud instance, focus on that.
If your goal is to have media server, focus on that.
If you need both, fine, but don't assume that the nextcloud data can be accessible to media server client and vise versa. I'm pretty sure nextcloud is not intended to be accessed by 'other protocols concurrently' which you happen to setup under-the-hood to allow this to happen. even though it may be possible, it could have unwanted impact (ie, break things horribly, lead to loss of data, etc.)

Or maybe you want to test this and see if you can test/break/validate. And that is fine too. But don't assume it will work for certain and don't deploy it in production to end users before you have tested it quite well.

for simplicity, you would do something like

one storage pool on the underlying zpool
make this available to proxmox
deploy VM(s) on top of that storage pool
VMs need to know nothing internally about zpool or external storage source. All they care about is they have a "local disk" into which they can write stuff.

If you create multiple zpools you are adding more complexity, more management, separate things to allocate resources to, etc etc. So if you need to add more complexity, make sure it is for a precisely good and necessary purpose for your priority goals to be achieved.

otherwise just making stuff complicated, 'because you can' - while it may be functional - can lead to longer term pain in terms of management and complexity burden. Or the risk of 'crap breaks more often when it is more complicated than needed'.

Just my 2 cents!



Tim