My server runs Debian VMs in Proxmox on an i7-2600 which has a lower benchmark than the 6600k. I also used the Perfect Media Server guide, and have 2 x 8T data drives pooled with MergerFS with 1 for snapraid parity, these are passed through to the main VM from Proxmox using ‘qm set’. One thing I would often forget after deleting/restoring this VM was to run qm set again after restore, ensuring it has the flag to not back up those drives or else backups will fail and I have to go uncheck the backup option on each drive to fix it.

If I need to spin up another VM for tinkering it’s easy enough to mount the NFS share as a volume with docker compose. Proxmox rarely shows CPU usage go above 50% (average is 10%) and this handles the whole *arr stack plus usenet and torrents in a single VM and compose file. I don’t have GPU passthrough set up because the motherboard on this older rig didn’t support IOMMU, never had issues with Plex or Jellyfin transcoding for Chromecast. I might build a new rig with GPU passthrough support to buffer media faster and selfhost LLMs when I get around to it.

deleted by creator

BRB about to make a derivative of this shirt

How could you forget Knockoff Evil Knievel

deleted by creator

For a static site Cloudflare Pages is good for free hosting, doing a git commit and watching the site change in a matter of seconds is very satisfying.

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.

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

We all do better when we all do better.

As someone who has only worked freight in an air-conditioned warehouse, moving boxes is not easy work and not many people will be able to do it their whole careers. I’m personally glad I argue with computers for my job now and I have much respect for those lifting things in the elements.

deleted by creator