Correct, it’s not obvious when first diving in but the main use for RAID is increasing performance and availability by allowing up to a specific number of drive failures. For that to work, ideally in an enterprise you’d have a primary and secondary controller to mitigate that point of failure which is not typical for most homelabs and makes backup even more important.
One note which may not apply to you, I installed my Proxmox to boot from 2 256G SSDs as a basic RAID 1 mirror and only have the bare minimum data in VM storage to reduce size of backups. Backup retention on the boot drives is limited because a cron job on the VM handles copying backups to the MergerFS pool for longer term storage.
Moving docker’s data directory to the ‘slow’ drives was a helpful decision, this post covers the old/wrong ways to do that and the way which worked (data-root). Docker data doesn’t take up a huge amount of space, but it saved me some work recently when I found my media server had been down for a while and couldn’t remember when it worked last to identify a working backup. I spun up a fresh Debian image and ran through the steps to reinstall the stack, and point to the same Docker data path. Running the same Docker compose command got most services working with the old metadata, though others i renamed/removed the service’s path and reconfigured.
My docker-compose and its revisions are the extent of a backup I need for a piracy box as my internet is quick enough to recreate my library within a couple days if needed.
Tried OpenMediaVault but found vanilla Debian on Proxmox is the easiest to troubleshoot. This guide helped me set it up. MergerFS works great with mismatched sizes of drives, and doing parity on media server content is a good use for SnapRAID.
deleted by creator
deleted by creator
If you don’t need realtime parity, I’ve had no issues on my media server running mismatched drives pooled via MergerFS with SnapRAID doing scheduled parity.