Self-HostingTutorial end-to-end di NAKIVO Backup & Replication v11.2 su LXC Debian 12 in Proxmox VE 9.1. Tre minuti di install, 90 secondi di licenza, 3 dettagli del setup che ti fanno risparmiare mezz'ora: uno è asimmetria Debian/Ubuntu, due sono errori da primo tentativo.
Self-HostingPrometheus con 8 job, Grafana, node-exporter su ogni nodo e container, blackbox HTTP probe. E zero alert configurati. Il monitoring che raccoglie tutto ma non ti sveglia quando serve.

27 aprile 2026 · 11 min lettura
ZFS mirror, replica cross-node ogni 15 minuti, 5 job vzdump stratificati. Pensavo di essere protetto. Poi ho controllato davvero: il mirror non era un mirror, i backup stavano sulla root, e l'offsite era vuoto.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.

Sul mio cluster pve+pve2 girano 14 LXC e 2 VM. La scelta VM vs LXC Proxmox non l'ho fatta per ideologia: per matematica.
Tra VM e LXC su Proxmox la scelta è netta: i container LXC danno 8× la densità a costo di un kernel condiviso, le VM via QEMU/KVM danno isolamento completo a costo di 25-40 secondi di boot e centinaia di MB idle. Per un servizio Linux fidato in casa, vince LXC. Per Windows, FreeBSD, codice non fidato o cluster con live migration, vince la VM. Tutto il resto è marketing.
Il dogma "container = sempre meglio" è proprio questo: dogma. La documentazione ufficiale Proxmox stessa scrive che "full virtual machines provide better isolation". Quando qualcuno ti dice di mettere tutto in LXC senza chiederti il workload, ti sta vendendo religione, non ingegneria.
Un container LXC su Proxmox è un'istanza Linux che condivide il kernel con l'host. Niente hypervisor in mezzo, niente OS guest da emulare: i processi del container girano direttamente sul CPU scheduler dell'host, dentro namespace e cgroup che li tengono isolati dagli altri. Una VM, invece, è una macchina completa gestita da QEMU/KVM — un hypervisor di tipo 1 — con il suo kernel guest, la sua memoria emulata, il suo BIOS/UEFI virtuale. Due paradigmi diversi, sullo stesso hypervisor.
They use the kernel of the host system that they run on, instead of emulating a full operating system. — Documentazione ufficiale Proxmox
Da questa singola differenza discende tutto il resto: densità, boot time, RAM idle, sicurezza, compatibilità sono corollari del fatto che LXC condividono il kernel e le VM no. Conseguenza diretta numero uno: dentro un LXC girano solo distribuzioni Linux. "It is not possible to run other operating systems like, for example, FreeBSD or Microsoft Windows inside a container", scrive la doc. Niente Windows, niente BSD, niente Solaris. Se il vendor ti dà un'ISO che non sia Linux, hai già finito di pensare: VM.
La densità è il primo motivo per cui un homelab serio sceglie LXC. Sul mio Ryzen 7 5825U con 64 GB di RAM tengo in piedi 14 container Debian 12 più 2 VM senza che il sistema sudi: homelabz.cc gira in CT 110 con 80 MB di RAM idle, e ne avevamo parlato in dettaglio nell'analisi del cluster Ryzen. La stessa Debian 12 in VM sullo stesso host idle parte da 600 MB. Stesso OS, stessi servizi, 7,5× più memoria sprecata.
Non sono numeri da cherry-picking. La tabella dei benchmark indipendenti (ashimov.com, propelrc.com) dà LXC tra 50 e 100+ container per host vs 10-30 VM per host. Se scegli VM per tutto su 64 GB, ti fermi a 5-6 macchine vere prima che lo swap inizi a singhiozzare. Con LXC arrivi tranquillo a 14, e potresti spingerti oltre. La differenza non è marginale: è strutturale.
I numeri di I/O del benchmark utente tomee (forum ufficiale, thread 155546) sono ancora più crudi: oltre 2× di IOPS in random read 16k a favore di LXC, latenza che scende da 146,94 µs a 74,91 µs. Lo staff (Falk R.) ha confermato che il delta è plausibile per workload database I/O-bound. Se il tuo Postgres o MariaDB casalingo è il collo di bottiglia, sai dove infilarlo.

Sì, e questo è il punto. Un container LXC condivide il kernel con l'host: significa che un kernel exploit come Dirty COW (CVE-2016-5195) o Dirty Pipe (CVE-2022-0847) impatta tutti i container in un colpo solo. Una VM no — il suo kernel guest è isolato dal kernel host. È la differenza fra un singolo punto di fallimento e una compartimentazione vera. Il team upstream LXC è esplicito: "those containers aren't and cannot be root-safe" parlando dei privileged. Tradotto: in privileged mode il kernel exploit è game over.
I container unprivileged riducono drasticamente la superficie d'attacco grazie alla mappatura UID: l'uid 0 dentro il container diventa uid 100000 sull'host, quindi un escape che ottiene root nel container ottiene un utente non-privilegiato fuori. Sono "safe by design" secondo la documentazione upstream. Ma resta il kernel condiviso: un bug in cgroups (CVE-2022-0492) o filesystem context (CVE-2022-0185) ti taglia la gamba lo stesso.
Una VM sull'hypervisor conviene in cinque scenari precisi, e fuori da quelli è quasi sempre overkill. OS non-Linux: Windows Server, FreeBSD, OPNsense, pfSense. Vendor che lo richiede: NAKIVO Backup & Replication non gira in LXC, e ne ho fatto esperienza diretta installandolo su Proxmox 9.1. Stack Docker Compose grossi, multi-tenancy o codice non fidato, e cluster con live migration. Tutto il resto è LXC fino a prova contraria.
Sul mio cluster pfSense storico è in VM perché il kernel è BSD, NAKIVO è in VM perché il vendor lo richiede e mounting NFS+block storage in LXC mi dava troppi conflitti SELinux. Punto. Le altre 14 unità sono LXC perché non c'era alcun motivo razionale per pagare il pedaggio QEMU.
Qui arriva l'obiezione che vale la pena prendere sul serio. LXC su Proxmox non supporta live migration: quando sposti un container fra due nodi del cluster, viene fermato e ripartito sull'altro nodo. Per un homelab è 5-10 secondi di downtime — chi se ne frega. Per un'azienda che sposta workload durante un upgrade kernel host senza fermare niente, è un dealbreaker.
I don't run LX(C) containers in our clusters due to the non-live-migratability. — LnxBil, Proxmox Distinguished Member, forum staff
La citazione è di uno staffer Proxmox che spinge container su KVM in cluster di produzione. Ha ragione lui? In quel contesto, sì: la non-migratability è il motivo principale per cui in azienda si resta su KVM. Ma non è il tuo caso se hai un homelab a uno o due nodi che riavvia di notte mentre tu dormi. La conclusione si capovolge appena cambia la condizione. Lo riconosce la documentazione stessa: "for use cases demanding maximum isolation and the ability to live-migrate, nesting containers inside a Proxmox QEMU VM remains a recommended practice". In pratica: se vuoi container ma anche live migration, metti Docker dentro una VM Linux e migra la VM — pattern raccomandato dallo staff da anni, valido anche dopo il 9.1.
Per anni la regola è stata: Docker non si mette dentro LXC, si mette in una VM Linux dedicata. La FAQ ufficiale lo dice chiaro, e chiunque abbia provato a far convivere Docker con cgroup unprivileged sa perché — conflitti AppArmor, bind mount NAS che vanno in segmentation fault, overlay storage driver capricciosi. Proxmox VE 9.1 di novembre 2025 ha cambiato in parte le carte in tavola con il supporto OCI image nativo per LXC, basato su kernel 6.17.2, LXC 6.0.5 e QEMU 10.1.2 della stessa release.
Tutto vero, ma lo staff non ha cantato vittoria. Sul forum ufficiale Fiona scrive: "in general it's recommended to install Docker inside a VM". Thomas Lamprecht aggiunge: "That one of the major reasons for why it's a tech preview, i.e., it's a bit involved". E Johannes S è ancora più diretto: "If you want to host oci-image-based applications who just work, stick with docker-vms".
Per servizi Linux nativi che non sono Docker — come Ollama in LXC CPU-only, Nginx, Postgres, Pi-hole, AdGuard, Authentik — il container vince a mani basse, e la versione 9.1 non c'entra. La domanda non è "Docker in LXC sì o no": è "hai davvero bisogno di Docker per questo singolo servizio, o ti serve un LXC Debian con il binario nativo?". Nove volte su dieci la risposta è la seconda.
Oltre alla live migration ci sono altri quattro punti dove gli LXC mostrano i limiti, e dove la VM diventa la scelta meno faticosa. Il primo è il kernel module custom: un container non può caricare moduli propri. Se ti serve un driver fuori dal kernel host, devi caricarlo sull'host stesso e fare bind-mount nel container — workaround che rompe il principio di isolamento e rende il setup fragile a ogni upgrade kernel dell'host.
Il secondo è NFS server kernel-space: il forum Proxmox è chiaro — "Running the nfs-kernel-server inside an LXC container does not make sense and does not really work by design". Esistono workaround come Ganesha-NFS user-space o mount sull'host con bind, ma non sono trasparenti. Se devi esportare uno share NFS da una sola macchina, una VM Debian con nfs-kernel-server installato e via.
Il terzo è il mount NFS lato client + GPU passthrough esclusivo. Mount NFS in LXC è fattibile (privileged + features=nfs=1, oppure mount sull'host con bind-mount), ma è il punto in cui il mio NAKIVO ha smesso di collaborare e ho dovuto pivottare su VM — SELinux, cgroup e AppArmor non si parlano sempre bene quando un servizio enterprise chiede block storage. La GPU, invece, in LXC si condivide (perfetto per Ollama o transcoding Plex), ma non si assegna in modo esclusivo: se vuoi una VM Windows con la 3060 dedicata per gaming nested o CUDA isolato, il container non è lo strumento adatto.
Smontati i miti, resta la matrice VM vs LXC Proxmox in versione operativa. Si legge dall'alto: appena una riga risponde sì, hai la tua decisione e fermi il ragionamento. La logica è semplice — partire dai vincoli duri (compatibilità OS, vendor) e scendere verso i trade-off (densità, sicurezza). Niente filosofia, solo gerarchia.
No. La documentazione ufficiale è esplicita: "Only Linux distributions can be run in Proxmox Containers". Windows richiede una VM via QEMU/KVM, niente alternative.
Privileged = root nel container è root sull'host (sconsigliato dal team upstream LXC, "cannot be root-safe"). Unprivileged = uid 0 mappato a uid 100000 sull'host, container escape ottiene un utente non-privilegiato. Default Proxmox dal 2017 è unprivileged. Usa privileged solo se ti serve esplicitamente (mount NFS legacy, alcuni device passthrough).
No. Il container viene fermato sul nodo sorgente e ripartito sul nodo destinazione (work in progress upstream da anni). Le VM via QEMU/KVM, invece, supportano live migration nativamente. È il motivo principale per cui in cluster di produzione si preferiscono ancora le VM, anche per workload Linux puri.
VE 9.1 (novembre 2025, kernel 6.17.2, LXC 6.0.5) introduce il supporto nativo a OCI image nei container LXC: pulli da Docker Hub o registry compatibili e converti in container LXC. È tech preview, non GA, e non sostituisce le VM Docker per stack di produzione: lo dichiara lo staff stesso. Funziona bene per servizi singoli; per Compose, Portainer e stack multi-servizio resta consigliata la VM con Docker engine.
Sul mio cluster: 14 LXC, 2 VM, 64 GB di RAM. Nessuno dei container è in privileged mode. Nessuna VM gira lì per moda — pfSense ci sta perché il kernel è BSD, NAKIVO ci sta perché il vendor lo impone. Tutto il resto è container, perché la matematica non lascia margini. Cambia la matematica, cambia la risposta.
Fonti: Proxmox Wiki — Linux Container, Proxmox Docs — Container Toolkit (pct), Proxmox Wiki — Unprivileged LXC containers, Proxmox Docs — QEMU/KVM Virtual Machines, linuxcontainers.org — LXC Security, Proxmox VE 9.1 press release, Forum Proxmox — OCI Images in LXC (9.1), Forum Proxmox — LXC vs VM Performance (tomee, Falk R.), Forum Proxmox — Should I move from KVM to LXC (LnxBil).
| Metrica | LXC | VM (KVM) |
|---|---|---|
| RAM idle Debian 12 (esperienza autore) | 80 MB | 600 MB |
| Boot time tipico | 1-5 s | 15-60 s |
| Densità per host (workload light) | 50-100+ | 10-30 |
| IOPS random read 16k (FIO MariaDB, PVE 8.2) | 13.300 | 6.768 |
| MariaDB qps SysBench (PVE 8.2) | 145.713 | 61.776 |
| CPU overhead (PVE 8.x sysbench) | ~99-100% bare metal | 80-95% |
| Esigenza | Scelta | Motivo |
|---|---|---|
| OS non-Linux (Windows, FreeBSD, pfSense, OPNsense) | VM | LXC supporta solo Linux |
| Vendor lo richiede esplicitamente (NAKIVO, hypervisor nested) | VM | Compatibilità contrattuale, supporto |
| Docker Compose stack 5+ servizi, Portainer, Traefik di produzione | VM con Docker | OCI-LXC 9.1 è tech preview, niente Compose |
| Multi-tenant, codice non fidato, hosting clienti | VM | Container non sono security boundary |
| Cluster con requisito live migration | VM (o nesting Docker in VM) | LXC fa stop+restart, non live |
| Kernel module custom o NFS server kernel-space | VM | LXC condivide il kernel host |
| Servizio Linux nativo singolo (Nginx, Postgres, Redis, Pi-hole, blog) | LXC unprivileged | 5-10× densità, boot 1-5s, 80 MB RAM idle |
| GPU shared per AI/transcoding (Ollama, Plex) | LXC | Passthrough condiviso, niente penalty QEMU |
| GPU passthrough esclusivo (gaming nested, CUDA dedicato) | VM | LXC non assegna GPU in modo esclusivo |
| 50+ servizi su 64 GB di RAM | LXC | Matematica: VM non ci stanno |