Tre minuti per installare NAKIVO Backup & Replication v11.2 su un LXC Debian 12, novanta secondi per attivare la licenza via GUI, zero reboot richiesti.
Quei tre minuti funzionano se hai la check-list giusta. Nel mio setup su CT Debian 12 sono inciampato su tre dettagli: uno è un'asimmetria ecosistema tra Debian e Ubuntu, gli altri due sono errori miei — un flag CLI che non ho letto bene nel manuale e un URL di download rimasto in vecchie note. Li racconto perché messi insieme costano mezzo pomeriggio se non sai che esistono, trenta secondi se sì. Tutto è successo il 24 aprile, su CT 128 del mio cluster Proxmox VE 9.1 — il nodo pve2, il failover che ho montato un mese fa per chiudere il cerchio della ridondanza locale.
Questa è la guida end-to-end per installare NAKIVO su Proxmox 9.1 partendo da zero: pct create del container, download dell'installer dal CDN, i tre dettagli del setup Debian 12 che ho incontrato e come li ho risolti, primo login alla GUI e upload della licenza NFR Enterprise Blogger. Tutti i passaggi sono quelli che ho eseguito di persona — comandi, output, decisioni.
Perché NAKIVO Backup & Replication sul mio homelab: è una piattaforma enterprise che supporta nativamente Proxmox VE 9.1 come hypervisor protetto (mappa VM e container LXC, chiama le API Proxmox per snapshot application-aware), gestisce repository SFTP cifrati lato client con deduplica e compressione, e include replication host-to-host per failover locale. La licenza NFR Enterprise Blogger che NAKIVO mette a disposizione dei creator homelab copre 20 workload (VM, fisici, workstation) e 20 router in una singola Director — scope più che sufficiente per coprire un cluster a due nodi con 13 CT produttivi come il mio. La prima installazione sblocca per 15 giorni anche le feature della Enterprise Plus (Microsoft 365 backup, Real-Time Replication, IT Monitoring), utile per valutare se estendere lo scope prima di fissare la licenza Blogger definitiva.
Dashboard NAKIVO subito dopo l'install e l'attivazione licenza, sul mio CT 128 Proxmox. — homelabz
Cluster Proxmox con 2 nodi: Corosync, QDevice e HA — come funziona il failover con dati reali
Corosync knet, QDevice su Raspberry Pi 5, replica ZFS ogni 15 minuti e failover automatico su 4 container. Come funziona il mio cluster Proxmox a 2 nodi — con i limiti reali che nessun tutorial menziona.
NAKIVO Backup & Replication v11.2 gira bene su un container LXC Debian 12 con 4 GB di RAM e 40 GB di disco. Non serve una VM dedicata, non serve un host fisico. Il Director è Java (JVM con -Xmx2g) più una PostgreSQL embedded per i metadata; il Transporter è un servizio C++ molto più leggero. Tutto sta sotto i 500 MB residenti in idle. Le porte TCP da aprire sul firewall sono 22 per SSH, 4443 per la GUI e le API REST del Director, 9446 per il listener di controllo del Transporter e il range 9448–10000 per il data transfer del Transporter stesso.
Cluster Proxmox VE 9.1 (anche nodo singolo va bene — io lo sto mettendo sul failover)
Template Debian 12 standard (debian-12-standard_12.12-1_amd64.tar.zst)
4 GB RAM, 40 GB disco, 2 vCPU per il container — minimi reali, non teorici
IP statico LAN e connettività HTTPS verso CloudFront per il download dell'installer
Licenza NAKIVO (trial, Free Edition o NFR Blogger come nel mio caso) — .license binario da 6 KB
Creare il container su pve2: lo zfspool che non è local-lvm
Il primo pct create è fallito subito, e non è colpa di NAKIVO. È colpa mia che ho copiato il comando dal nodo principale. Sul mio pve primario lo storage di default è local-lvm. Su pve2 — il secondo nodo, installato pochi mesi fa con lo stesso installer Proxmox ma configurato con ZFS on root — lo storage locale è uno zfspool che ho chiamato pve2-local. Due convenzioni diverse, stessa rete, stesso cluster. Il comando corretto, lanciato su pve2 come root:
Due note operative. unprivileged: 1 è obbligatorio in qualsiasi LXC che tocchi un repository di dati. nesting=1 serve perché NAKIVO durante l'install monta mount namespace interni per la PostgreSQL embedded — senza nesting il transporter parte ma il Director resta bloccato in post-install. Prima di accendere il container, scrivo subito /etc/pve/firewall/128.fw con policy_in DROP e whitelist delle porte NAKIVO elencate sopra: un servizio backup espone metadata sensibili (inventory delle VM, chiavi di connessione agli host, path repository), non va mai in internet nudo.
Installare NAKIVO: 3 cose da sapere per un setup Debian 12 pulito
L'installer NAKIVO è un self-extracting da 999 MB che include JRE, PostgreSQL-linux-lite 10.10 e i binari di Director e Transporter. È compatibile con decine di distribuzioni Linux, da RHEL 7 fino a Ubuntu 24.04, passando per Debian e SUSE. Nel mio setup specifico su CT Debian 12 LXC mi sono preso tre scivoloni. Voglio essere onesto sul cosa sono: una è un'asimmetria tra ecosistemi Debian e Ubuntu — non è un bug di nessuno, è una differenza nota tra le due famiglie. Le altre due sono errori miei: la prima per non aver letto abbastanza il manuale dell'installer, la seconda per essermi fidato di vecchie note invece di verificare l'URL attuale. Le metto in fila perché insieme costano mezz'ora se non le sai e 30 secondi se sì.
Cosa 1 — lsb-release: asimmetria tra Debian e Ubuntu
L'installer universale NAKIVO controlla /etc/lsb-release per identificare la distribuzione. Debian 12 è nella matrice ufficialmente supportata da NAKIVO (come Full Solution e come Transporter), quindi il problema non è la versione della distro: è che il pacchetto lsb-release è opzionale su Debian e le template LXC stock non lo includono, mentre Debian porta l'info di distribuzione in /etc/os-release (standard systemd dal 2014). Una differenza nota tra due famiglie che si porta dietro trent'anni di storia Linux. Effetto pratico: senza il file l'installer non riconosce la distro e mostra la help page con exit code 0, che al primo colpo sembra un flag sbagliato. Il fix è una sola riga eseguita dentro il container prima del download:
Cosa 2 — Come si combinano i flag -b e -f dell'installer
Nei miei appunti avevo segnato di passare -b "master-password" direttamente al comando di install full per pre-configurare la master password del Transporter. Rileggendo la documentazione ufficiale con calma, il pattern di NAKIVO è più pulito di così: -b accompagna l'install del solo Transporter (-t, la modalita' TRANSPORTER_ONLY usata quando distribuisci un nodo di data transfer in un datacenter remoto), perché in quello scenario la master password è l'unico modo per consentire al Director di ri-associare il Transporter in un secondo momento. Nell'install full (-f: Director + Transporter + repository locale sulla stessa macchina) Director e Transporter nascono già accoppiati e la master password viene gestita dalla GUI, in Settings -> Transporters -> Edit. E' una separazione coerente con l'architettura: il full install è una console di management a sé, i flag di bootstrap del Transporter standalone sono cosa diversa. Sul mio v11.2.0.102454 l'ho verificato sul campo; sulla tua versione la regola aurea è la stessa — master password del Transporter via GUI quando installi Director+Transporter insieme.
Cosa 3 — L'installer vive su CDN CloudFront, non sul path legacy
Il terzo è interamente colpa mia. Avevo in testa un URL di download ereditato da vecchie note: qualcosa tipo download.nakivo.com/bin/. Oggi NAKIVO distribuisce gli installer via CDN CloudFront — pattern standard per binari enterprise sopra il gigabyte, garantisce throughput stabile ovunque ti trovi e scarica il backbone dei server origin. La fonte autorevole e unica resta sempre la pagina nakivo.com/resources/download: lì trovi il link corrente della release, aggiornato a ogni minor. La catena TLS CloudFront non viene validata al primo colpo dal CA bundle Debian default, quindi il download richiede il flag -k (o l'aggiunta del root AWS al trust store, se serve in produzione):
bash
# L'installer Linux cambia URL a ogni release minor. La pagina ufficiale da cui partire
# è sempre https://www.nakivo.com/resources/download/ (tab 'Linux Installer'):
# copia il link corrente per la versione Trial o Free e incollalo qui sotto.
# NAKIVO distribuisce via CDN CloudFront, quindi l'host sara' del tipo *.cloudfront.net.
INSTALLER_URL="<incolla-qui-link-da-nakivo.com/resources/download>"
curl -sk -o /tmp/nakivo-installer.sh "$INSTALLER_URL"
Uso -k solo per il download: l'URL è fidato, il container è isolato nel firewall Proxmox, e il rischio è accettabile nel contesto. In produzione su rete non attendibile aggiungerei il bundle AWS root a /usr/local/share/ca-certificates/ e farei update-ca-certificates.
bash
chmod +x /tmp/nakivo-installer.sh
/tmp/nakivo-installer.sh --eula-accept -f -y -a
# --eula-accept : accetta EULA non-interattivo
# -f : full install (Director + Transporter + repository)
# -y : accept limitations silently
# -a : enable call-home (upload support bundle al team NAKIVO)
L'install completa in meno di 3 minuti dallo start del download, lascia due servizi systemd attivi (nkv-dirsvc per il Director e nkv-bhsvc per il Transporter) e due porte in listen: 4443 per la GUI web e 9446 per il Transporter. Output finale:
text
Extracting /tmp/transporter.java/postgresql-linux-lite-10.10-1-x64.gz...
Starting Transporter service...
NAKIVO Backup & Replication Extension installed successfully.
Registering the Director service...
Starting the Director service...
NAKIVO Backup & Replication installed successfully.
Apro il browser su https://10.0.10.128:4443 — accetto il cert autofirmato per la prima volta, perché il wizard è su HTTPS anche prima che tu abbia una configurazione. Il primo GET impiega ~2,4 s: la JVM ha ancora fredda la cache dei classloader. Dal secondo refresh la risposta è istantanea.
Primo accesso GUI e licenza Enterprise Blogger
Il primo login a NAKIVO non è un form di login ma un wizard "Create Account". Ti chiede nome, username, email, password con complexity rules (almeno 22 caratteri mi è parsa una policy sensata per un pannello admin) e consenso all'EULA. Dopo il submit ti manda su /c/configuration?wizard=true: è un tour Inventory → Nodes → Repositories che puoi saltare andando direttamente su /c/overview. Lo skip è voluto — non perdi funzionalità, le configuri in seguito con più contesto.
Prima dell'upload della mia licenza, la pagina Licensing mostra uno stato Trial — Enterprise Plus — con scadenza 15 giorni dall'install. Il trial integrato copre tutte le feature enterprise, inclusi Microsoft 365 e Real-Time Replication che la mia licenza Blogger non include. È un comportamento pulito: il trial non ti vincola, e la licenza NFR sovrascrive tutto al primo upload. L'upload sta in Settings → Licensing → Change License, un click apre il selettore file nativo, carico il mio nakivo-license.license (6088 byte binari), la pagina si ricarica e mostra i nuovi valori senza prompt di conferma.
Pagina Licensing dopo l'upload del file .license NFR Blogger. Serial number e metadata privati sono censurati. — homelabz
Venti workload sono abbondanti per il mio lab domestico: in produzione ci sono 13 container Proxmox, più 2 nodi fisici (pve e pve2) da trattare come physical server. Avanzano ancora quote per eventuali VM esterne. La scadenza 2026-10-22 coincide esattamente con il ciclo NFR di NAKIVO: sei mesi di utilizzo pieno. Tutto il flusso Create Account → saltare wizard → chiudere upsell → upload licenza l'ho automatizzato con uno script Playwright in Python — dall'apertura della GUI alla dashboard operativa in 90 secondi, con screenshot di conferma generati dallo stesso script che censura preventivamente i selettori CSS dei campi sensibili prima del flash.
Cosa cambia davvero in un homelab Proxmox
Il valore vero di NAKIVO Backup & Replication in un contesto homelab non è il costo della licenza — la Free Edition copre già 5 workload — ma il fatto che integra backup e replication sotto la stessa dashboard. Nella mia topologia, pve è il nodo primario con 13 CT in produzione e pve2 è il failover freddo. Fino ad oggi la mia sola linea di difesa offsite era il layer Restic che ho messo su dopo aver fatto i conti con i buchi del disaster recovery ZFS. Restic ha un pregio enorme — è imbattibile come CLI offsite — ma non fa replication locale a caldo tra nodi. Se pve muore, ripristino da Hetzner via rete casa FTTC. Significa ore.
NAKIVO copre entrambe le direzioni nella stessa UI: backup jobs con deduplica e compressione verso un repository SFTP Hetzner (per sostituire Restic sui 13 CT che ho, anatomia che ho raccontato qui) più replication locale pve → pve2 per i tre container che non possono stare giù più di dieci minuti. Un pannello, due storie diverse di recovery.
Confessione da homelabber: il motivo principale per cui sto ristrutturando il layer backup non è tecnico. È che Restic mi funziona da mesi senza un singolo errore, e proprio per questo ho smesso di controllarlo davvero. Quando un backup è invisibile per troppo tempo smetti di sapere se funziona. Una dashboard che mi guarda negli occhi ogni volta che apro il browser su 10.0.10.128 è ingegneria sociale applicata a me stesso.
Dashboard operativa dopo il licensing: zero job, 1 Node (questo Director), 1 Repository (Onboard) — il punto di partenza. — homelabz
Il prossimo passo è aggiungere pve e pve2 come environments nell'inventory NAKIVO (sempre via Playwright — lo scripting per workflow admin ripetibili è sottovalutato), configurare il Hetzner SFTP come repository secondario, e lanciare i primi backup jobs sui 13 container. I numeri reali — tempo di primo backup, dedup ratio, banda utilizzata, RPO ottenuto — li raccolgo nel post #2 di questa serie.
Tre minuti per installare NAKIVO su Proxmox. Novanta secondi per la licenza. Trenta secondi in meno a ogni prossima install, se hai letto questo post.
Se qualcosa va storto
Se al primo avvio il Director non parte, il Transporter non si registra o la GUI su 4443 non risponde, prima di reinstallare da capo vale la pena guardare i tre posti giusti. I servizi systemd sono nkv-dirsvc (Director) e nkv-bhsvc (Transporter): entrambi scrivono log sia in journal sia in /opt/nakivo/director/logs/ e /opt/nakivo/transporter/logs/. I comandi che uso io quando il setup non torna:
bash
# Stato + ultimi errori dei due servizi
systemctl status nkv-dirsvc nkv-bhsvc
journalctl -u nkv-dirsvc -n 100 --no-pager
journalctl -u nkv-bhsvc -n 100 --no-pager
# Le due porte devono essere in listen: 4443 (Director HTTPS) + 9446 (Transporter)
ss -tlnp | grep -E ':(4443|9446)\b'
# Log applicativi NAKIVO (più verbosi di journal, utili su errori PostgreSQL embedded)
tail -n 200 /opt/nakivo/director/logs/director.log
tail -n 200 /opt/nakivo/transporter/logs/bhsvc.log
Il 90% degli incidenti di prima installazione è coperto dalla pagina ufficiale Troubleshooting Installation del Help Center NAKIVO: prerequisiti pacchetto, SELinux attivo su RHEL/SLES, web interface che non risponde post-install, problemi di connettività. Quello che non si trova lì ha senso aprirlo via portale my.nakivo.com — il support risponde anche per licenze NFR/Blogger.
Fonti ufficiali NAKIVO
Porte, flag e prerequisiti cambiano versione per versione: in caso di divergenza fra questo post e la documentazione ufficiale, fa sempre fede la doc NAKIVO. Ho scritto questo articolo sulla v11.2.0.102454 scaricata il 2026-04-24.
Fonti: NAKIVO Backup & Replication v11.2, Proxmox VE 9.1 documentation, note di install first-hand documentate in docs/nakivo-lab.md (homelab privato, 2026-04-24). Post sponsorizzato da NAKIVO — licenza NFR Enterprise Blogger ricevuta, contenuto tecnico e opinioni sul flusso di install restano miei.
Resta Aggiornato
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
