Background: I’d like to turn an old personal laptop into a Jellyfin server so that I can stream media to my living room TV. I want to be able to expand what I use this server for over time. I’m leaning toward Proxmox as the OS so that I can spin up new containers for various services instead of installing a bunch of services on a base Debian install. I also want full disk encryption so that any data on the OS drive is less likely to be compromised by theft or Craigslist.
Question #1: I gather the general accepted approach for this is to first install Debian as a base w/ full disk encryption enabled and then install Proxmox on top because there is no option for full disk encryption in the native installer for Proxmox. Is this still the case?
Excerpt from this tutorial from November 2023 on the Proxmox Forum:
This tutorial deals with encryption of an existing installation. If you are starting fresh, my recommendation would be to install Debian with full disk encryption and then add Proxmox to it.
Excerpt from this post from February 2019 on the Level1Techs Forum:
The easiest way to do an encrypted Proxmox setup is to start with a minimal, vanilla Debian install. Set up the encrypted partition using the installer like you would with any other Debian system. Once installed, reboot. Then follow the guide for installing Proxmox on Debian.
Question #2: I don’t mind entering the key manually whenever I reboot the server, but will I be able to unlock the server remotely? For example, suppose I’m tinkering in the web admin panel or an SSH session and I want/need to reboot—will I have to physically go over to the laptop and enter the key every time?
Also, I appreciate any other tips from the community to help me think about this in the right way. Thanks!
This looks interesting, how do you handle automated backups of all the VMs/Containers? Their docs kind of seem to say “stop everything and figure it out”, but with Proxmox I’m used to it handling everything automatically to my PBS server every night.
https://linuxcontainers.org/incus/docs/main/howto/instances_backup/#instances-snapshots
This describes the jist, it’s all about snapshots! Incus loves BTRFS/ZFS.
There’s no true need for stop everything as far as I can tell.
Stop everything is applicable for databases for any backup system (snapshot avoids backing up a database mid write (guaranteed failure) but the snapshot could be during a live database multi-step operation and while intact is left in a cursed state). For databases I make sure to stop and backup (SQLite losers) or backup live (Gods’ chosen Postgres) specially so no very niche database failures occur even though it was done with instant/write-safe snapshots!!
Recovery plan is restore snapshot and if 0.1% chance of database bad bc was mid big multiple step operation then I have the .gz to restore from.
That’s what proxmox has too, but snapshots aren’t backups and aren’t being sent to a remote backup server… You’re also not supposed to keep snapshots around for very long, whereas I have backups going back several months.
Or are you sending snapshots to a remote server? I think ZFS can do that, so maybe that’s an option I can look at.
https://linuxcontainers.org/incus/docs/main/howto/instances_backup/#instances-backup-export
A bit down from the snapshots section is the export section, what I do is I export to a place then back it up with Restic. I do not compress on export and instead do it myself with the —rsyncable flag added to zstd. (Flag applies to gzip too) With the rsyncable flag incremental backups work on the zip file so it’s space efficient despite being compressed. I don’t worry about collating individual zip files, instead I rely on Restic’s built-in versioning to get a specific version of the VM/container if I needed it.
Also a few of my containers I linked the real file system (big ole data drive) into the container and just snapshot the big ole data drive/send said snapshot using the BTRFS/ZFS methods cause that seemed easier, those containers are easy enough to stand up on a whim and then just need said data hooked up.
I also restic the sent snapshot since snapshots are write-static and restic can read from it at its leisure. Restic is the final backup orchestrator for all of my data. One restic call == one “restic snapshot” so I call it monolithically with one call covering several data sources.
Hope that helps!
Is it all automated with versioning intervals and stuff? Or is restic required as a third party step and maintaining a duplicate of data on the server for it to grab?
Overall it sounds like a decent VM manager but is meant for enterprise stuff where they’ll be building their own backup systems.
So extra background, I was put off by proxmox’s weird steps to get ISO’s onto the system via USB so I was like “I am not touching the backup stuff” and just rolled my own (I treat the VMs/containers on my proxmox server like individual servers and back them up accordingly and do not back up the underlying proxmox instance itself).
I see proxmox has a similar pruning setting to Restic, and it exports the files like incus. So I’d say yes, proxmox is one-stop-shop for backup while with incus you have to put its container export options and restic together and put that in a cron job.
Still hard to say what I’d definitively tell a newbie to go with. I found (and still find) the proxmox ui daunting and difficult while the incus UI makes much more sense to me and is easier (has an ISO pulling system built in for instance. But as you’ve pointed out - proxmox gives you an easy way to have robust backups that takes much more effort on the incus side.
As backups are paramount, proxmox for a total newbie. If someone is familiar with scripting, then incus - because it needs scripted backups to be as robust as proxmox’ backups. @barnaclebill@lemmy.dbzer0.com this conclusion should help you choose proxmox (most likely)!
It’s interesting because you’re not the first person to complain about getting ISOs in Proxmox, but on my instance if I click on my local storage it has an upload ISO button, and a download ISO from URL button right there, so it’s really simple.
It can also mount network storage with existing ISOs and just pull from that.
I don’t use ISOs very often though, either a Debian 12 container template, or a custom Debian 12 cloud-init VM I made and backed up, so I can just hit restore and it gives me a fresh VM with new networking config and everything through cloud-init automatically.