Come installare Nakivo Backup & Replication su Ubuntu Linux

Installare Nakivo Backup & Replication su Ubuntu Linux non è complicato, ma conviene farlo con ordine: prima verifico prerequisiti, rete e spazio disco, poi preparo il sistema, quindi passo all’installazione vera e propria e ai controlli post-avvio. In produzione, la differenza la fa quasi sempre la parte iniziale: una porta bloccata, un repository non raggiungibile o un filesystem montato male ti fanno perdere più tempo del setup in sé.

Qui assumo un’installazione su Ubuntu Server recente, con accesso amministrativo, risoluzione DNS funzionante e la possibilità di aprire porte sulla macchina o sul firewall per raggiungere la console web di Nakivo. Se il server è dietro NAT, reverse proxy o firewall perimetrale, conviene chiarire subito il percorso di accesso prima di partire, così eviti di dover rifare la configurazione al termine.

Prerequisiti da verificare prima dell’installazione

Prima di installare il software, controllo che il sistema sia aggiornato, che abbia risorse sufficienti e che il repository ufficiale sia raggiungibile. Nakivo è un prodotto da backup, quindi il punto non è solo “farlo partire”: deve avere spazio, I/O e rete adeguati per lavorare senza colli di bottiglia evidenti.

• Ubuntu Server supportato dalla versione che vuoi installare.

• Accesso sudo o root.

• Spazio disco sufficiente per i componenti applicativi e per eventuali repository di backup locali.

• Connettività verso Internet o verso il repository da cui scaricherai i pacchetti.

• Porta web libera per la console di amministrazione, oltre a eventuali porte richieste dall’ambiente di backup.

Per un controllo rapido del sistema, questi comandi ti danno un quadro minimo utile:

lsb_release -a || cat /etc/os-release
uname -r
df -h
free -h
ip a

Se df -h mostra partizioni quasi piene, sistemalo prima. In un server di backup, disco e I/O sono più critici di quanto sembrino: un’installazione andata a buon fine ma con storage saturo ti lascerà con problemi al primo job serio.

Scelta dell’architettura: server dedicato o macchina già in uso

Nella pratica ci sono due scenari. Il primo è il server dedicato, che è la scelta più pulita: meno conflitti, meno servizi concorrenti, più facilità nel dimensionare storage e rete. Il secondo è una macchina già usata per altro, e lì bisogna essere più prudenti: se il nodo ospita già database, servizi web o altri demoni pesanti, la convivenza può introdurre contese su RAM, CPU e I/O.

Se stai mettendo Nakivo in produzione, io preferisco un host dedicato o almeno una VM ben separata, con storage veloce e backup dei dati applicativi dell’istanza. Questo vale soprattutto se la macchina deve gestire repository locali o se la console verrà usata da più operatori.

Aggiornamento del sistema e dipendenze base

Prima di aggiungere repository o installare pacchetti, aggiorno l’indice e porto il sistema allo stato corrente. È un passaggio banale, ma riduce il rischio di dipendenze incoerenti e mi evita di inseguire problemi già risolti nelle versioni più recenti dei pacchetti di base.

sudo apt update
sudo apt upgrade -y

Se il kernel o librerie critiche vengono aggiornati, valuta un riavvio programmato prima di procedere. Non è obbligatorio in ogni caso, ma è meglio partire da un sistema coerente piuttosto che installare software nuovo sopra una base che richiede ancora un reboot.

Reperimento del pacchetto Nakivo

Il modo corretto per installare Nakivo su Ubuntu è usare il pacchetto ufficiale previsto dal vendor, non pacchetti improvvisati o repository non verificati. Il nome esatto del pacchetto e la procedura possono cambiare in base alla versione del prodotto, quindi il punto chiave è scaricare la build corretta per Ubuntu dalla documentazione ufficiale di Nakivo o dal portale di download associato al tuo account.

Qui non conviene inventare il nome file o il link diretto, perché dipendono dalla release. Il controllo da fare è semplice: una volta scaricato il pacchetto, verifica che corrisponda alla tua architettura e alla versione supportata del sistema operativo. Se il vendor fornisce un file .deb, stai seguendo il percorso standard per Ubuntu; se invece la distribuzione è legata a uno script o a un bundle, usa solo la procedura ufficiale prevista per quella release.

In caso di dubbio, la verifica minima è questa:

file nome-pacchetto.deb
dpkg-deb -I nome-pacchetto.deb | sed -n '1,20p'

Il primo comando ti conferma il formato, il secondo mostra metadati utili come versione e architettura. Se il pacchetto non è quello atteso, fermati prima di installare.

Installazione del pacchetto su Ubuntu

Una volta ottenuto il pacchetto corretto, il flusso tipico su Ubuntu è installarlo con apt o dpkg, a seconda delle istruzioni del vendor. Se il pacchetto richiede dipendenze aggiuntive, apt è spesso più comodo perché risolve automaticamente ciò che manca. Se il vendor indica esplicitamente dpkg, conviene seguirne la procedura e poi chiudere le dipendenze mancanti con apt -f install.

sudo apt install ./nome-pacchetto.deb

Se il pacchetto non viene accettato da apt, il percorso alternativo è:

sudo dpkg -i nome-pacchetto.deb
sudo apt -f install

Durante l’installazione, osserva con attenzione eventuali errori su dipendenze, porte occupate o servizi non avviabili. Se il setup fallisce, la prima cosa da controllare è il log dell’installazione e lo stato del servizio creato dal pacchetto.

Verifica del servizio dopo l’installazione

Dopo l’installazione, il controllo più utile è capire se il servizio applicativo è attivo e ascolta sulle porte attese. Su sistemi moderni, systemd è il punto di partenza naturale.

systemctl list-units --type=service | grep -i nakivo
systemctl status nome-servizio

Il nome esatto del servizio può variare in base al pacchetto e alla versione, quindi se non lo conosci conviene elencare i servizi e filtrare per Nakivo. L’output atteso è un servizio active (running). Se vedi failed o inactive, passa subito ai log.

journalctl -u nome-servizio -n 100 --no-pager

Questa è la verifica che ti evita di andare a tentoni: spesso l’errore è un binding su porta già occupata, una directory non scrivibile o un prerequisito mancante. Meglio leggere il log subito che aprire il browser e scoprire una pagina vuota senza contesto.

Accesso alla console web

Una volta avviato il servizio, la console di Nakivo si raggiunge dal browser all’indirizzo del server e sulla porta prevista dalla configurazione del prodotto. La porta esatta dipende dalla versione e dal pacchetto installato, quindi va confermata nella documentazione o nell’output del setup. Se il server è raggiungibile in rete ma la console non risponde, il problema spesso è uno tra questi: servizio non partito, porta non aperta nel firewall locale, security group o firewall esterno che blocca il traffico, oppure binding solo su localhost.

Controllo minimo lato rete:

ss -tulpn | grep -i LISTEN
sudo ufw status verbose

Se usi ufw, apri solo la porta necessaria e solo verso gli IP autorizzati, se possibile. In un contesto di backup non ha senso esporre più del necessario: la console è un punto sensibile e va trattata come tale.

Configurazione iniziale guidata

Al primo accesso, la procedura guidata ti chiederà di creare o inizializzare l’ambiente di amministrazione. Qui conviene fermarsi un attimo e decidere subito tre cose: chi amministra la piattaforma, dove saranno conservati i repository di backup e come verranno gestite le credenziali verso hypervisor, server fisici o storage esterni.

Le pratiche migliori sono semplici ma spesso trascurate: usa un account amministrativo nominativo, conserva le credenziali in un password manager aziendale, e separa per quanto possibile l’accesso alla console da quello agli ambienti protetti. Se il prodotto supporta ruoli o permessi granulari, sfruttali fin da subito, invece di lasciare tutto al primo account creato.

Quando la procedura ti chiede il repository o il percorso di storage, scegli un filesystem con spazio reale e margine di crescita. Non usare directory improvvisate su partizioni quasi piene. Se il repository è locale, valuta anche il comportamento in caso di reboot: il mount deve essere persistente e disponibile al boot.

Repository di backup e capacità disco

Il punto più sottovalutato in una nuova installazione non è l’applicazione, ma il repository. Un backup software installato bene ma senza storage adeguato è solo una console vuota. La capacità va dimensionata tenendo conto di retention, full, incrementali, eventuale compressione, cifratura e crescita attesa dei workload protetti.

Per un controllo rapido della capacità reale, oltre a df -h conviene guardare anche il tipo di filesystem e il punto di mount:

df -Th
mount | grep -E ' /|backup|data'

Se il repository è su storage esterno, verifica anche latenza e stabilità del collegamento. Un disco lento o un volume remoto instabile può trasformare una finestra di backup in un collo di bottiglia continuo, con job che si allungano e saturano la finestra operativa.

Firewall, porte e accesso sicuro

Per una installazione pulita, il firewall locale deve consentire solo ciò che serve davvero. L’errore tipico è aprire tutto “per far prima” e lasciare una console amministrativa esposta più del necessario. Meglio una regola mirata e documentata, con sorgenti autorizzate definite in modo esplicito.

Se usi UFW, la logica è semplice: apri la porta della console solo dagli IP di amministrazione e conferma poi la raggiungibilità dal client autorizzato. Se usi un firewall diverso, applica lo stesso principio. Il controllo finale non è solo “la porta è aperta”, ma “la porta è aperta solo dove deve esserlo”.

Un controllo utile dopo la modifica è:

sudo ufw status numbered
ss -tulpn | grep -E ':[0-9]+' 

Se lavori dietro un firewall perimetrale o un security group cloud, aggiorna anche lì la regola. Spesso la macchina risponde localmente, ma dall’esterno la porta resta chiusa perché il filtro più esterno non è stato toccato.

Controlli post-installazione da non saltare

Quando la console è accessibile, il lavoro non è finito. Servono almeno tre verifiche: il servizio resta attivo dopo un riavvio, il percorso di storage è persistente e le credenziali di accesso agli ambienti da proteggere sono state inserite correttamente. In più, conviene fare un test semplice di login e un controllo sui log applicativi per intercettare warning iniziali.

systemctl is-enabled nome-servizio
systemctl is-active nome-servizio
journalctl -u nome-servizio -p warning -n 50 --no-pager

Se il servizio non è abilitato all’avvio, valutalo subito. Un backup server che parte solo manualmente è una fragilità operativa inutile. Lo stesso vale per mount non persistenti: un reboot programmato non deve diventare un fermo impianto.

Backup della configurazione e piano di rollback

Anche se l’installazione è lineare, conviene salvare ciò che hai fatto: versione del pacchetto, parametri scelti, porte aperte, percorso del repository e stato iniziale del servizio. Se qualcosa va storto nelle ore successive, queste note ti fanno risparmiare tempo.

Il rollback dipende da come hai installato il prodotto. In generale, se hai usato un pacchetto .deb, il ritiro dell’applicazione passa dalla rimozione del pacchetto e dalla pulizia dei file di configurazione solo se sei certo di non dover recuperare nulla. Prima di rimuovere, però, salva i dati applicativi e verifica se esiste una procedura ufficiale di uninstall del vendor. Non cancellare directory a mano finché non hai chiaro cosa contengono.

dpkg -l | grep -i nakivo
sudo cp -a /etc/nome-config /root/backup-nakivo-config-$(date +%F)

Se devi intervenire sul firewall o sul percorso di storage, il rollback deve essere altrettanto semplice: ripristina la regola precedente o il mount precedente, verifica il servizio, e controlla nuovamente i log. In un ambiente di backup, la regola giusta è cambiare una cosa alla volta e poterla annullare senza ambiguità.

Errore comuni durante l’installazione

I problemi più frequenti sono sempre gli stessi: pacchetto sbagliato, dipendenze mancanti, porta già occupata, storage non disponibile e regole firewall incomplete. In pratica, l’installazione fallisce molto più spesso per l’ambiente circostante che per il software in sé.

• Pacchetto non compatibile: verifica versione Ubuntu e architettura con lsb_release -a e dpkg --print-architecture.

• Servizio non parte: leggi journalctl -u nome-servizio e cerca errori di binding, permessi o dipendenze.

• Console non raggiungibile: controlla ss -tulpn, firewall locale e filtro esterno.

• Repository instabile: verifica mount, spazio e latenza dello storage prima di lanciare i primi job.

Se vuoi evitare il classico “installato ma non operativo”, la sequenza corretta è: pacchetto giusto, servizio attivo, porta raggiungibile, storage valido, login riuscito, poi solo dopo i primi job di test. È un ordine semplice, ma in ambienti reali fa la differenza tra una messa online pulita e una serata passata a inseguire errori banali.