Come scaricare e installare Veeam Agent per Linux

Per installare Veeam Agent for Linux in modo pulito conviene partire dal repository ufficiale del vendor, non da pacchetti presi a caso. Così tieni sotto controllo aggiornamenti, dipendenze e compatibilità con la distribuzione in uso. In pratica il flusso è sempre lo stesso: aggiungi la sorgente corretta, installi il pacchetto, verifichi il servizio e poi fai un test di configurazione prima di affidarti ai primi backup reali.

Il punto importante è distinguere tra download manuale e installazione da repository. Il primo serve solo quando devi lavorare offline o in ambienti blindati; il secondo è la strada normale, perché semplifica manutenzione e patching. Se stai gestendo server di produzione, la differenza la vedi subito: meno drift, meno errori di versione, meno sorprese quando devi aggiornare il componente agent.

Prima di installare: verifica distribuzione, kernel e accesso root

Veeam Agent for Linux gira su distribuzioni supportate dal vendor, ma prima di scaricare qualsiasi pacchetto conviene capire esattamente cosa hai sotto. Il controllo minimo è semplice: versione della distro, architettura, kernel e presenza di privilegi amministrativi. Se questi dati non tornano, fermati prima di toccare il sistema.

Usa questi comandi per fotografare l’ambiente:

cat /etc/os-release
uname -r
uname -m
id

Il risultato atteso è chiaro: una distribuzione riconoscibile, architettura coerente con il pacchetto che scaricherai e un utente con privilegi root o sudo. Se il sistema è minimale e non hai ancora strumenti come curl o wget, installali prima con il gestore pacchetti della tua distro.

Scaricare Veeam Agent for Linux dal repository ufficiale

La logica corretta è aggiungere il repository Veeam e poi installare il pacchetto. Il nome esatto del repository e del pacchetto può cambiare nel tempo, quindi il riferimento giusto resta sempre la documentazione ufficiale del vendor per la release che stai usando. Non inventare URL o versioni: se non hai già il link corretto, recuperalo dalla pagina ufficiale del prodotto e verifica checksum e firma del file scaricato.

Il flusso tipico su sistemi RPM-based è questo: importazione della chiave, aggiunta del repository, refresh dei metadata e installazione del pacchetto. Su sistemi DEB-based il concetto è identico, cambia solo la sintassi del gestore pacchetti.

Esempio generico per repository RPM, da adattare alla release effettiva:

sudo rpm --import <URL_CHIAVE_FIRMATA_O_FILE_GPG>
sudo curl -o /etc/yum.repos.d/veeam.repo <URL_REPO_OFFICIALE>
sudo dnf makecache
sudo dnf install veeam

Su Debian, Ubuntu o derivate, il pattern è equivalente:

curl -fsSL <URL_CHIAVE_O_PUBKEY> | sudo gpg --dearmor -o /usr/share/keyrings/veeam.gpg
printf '%s
' 'deb [signed-by=/usr/share/keyrings/veeam.gpg] <URL_REPO> stable main' | sudo tee /etc/apt/sources.list.d/veeam.list
sudo apt update
sudo apt install veeam

Se il tuo ambiente non consente accesso diretto a Internet, scarica i pacchetti da una macchina connessa, trasferiscili nel repository interno e usa il mirror aziendale. È la scelta più sensata in reti segmentate o in sistemi con controllo stretto dell’egress.

Installazione da file locale: quando serve davvero

L’installazione manuale ha senso in tre casi: server senza accesso esterno, staging che replica un ambiente air-gapped, oppure recovery su macchine dove il repository non è ancora disponibile. In questo scenario il pacchetto si scarica prima su un host fidato, si verifica e poi si trasferisce sul server target.

Prima di installare, controlla che il file sia integro. Il vendor di solito pubblica checksum o firme; se li hai, confrontali subito. Il check non è una formalità: se il pacchetto è corrotto o alterato, non serve andare oltre.

sha256sum veeam*.rpm
rpm -K veeam*.rpm

Se il controllo è OK, installa il pacchetto con il tool della distro:

sudo dnf install ./veeam*.rpm

Oppure, su sistemi DEB:

sudo apt install ./veeam*.deb

Se il pacchetto segnala dipendenze mancanti, non forzare. Risolvi prima le librerie richieste con i repository ufficiali della distribuzione, poi ripeti l’installazione. In ambienti server, un forzato fatto male produce più lavoro dopo che beneficio subito.

Post-installazione: servizio, moduli e controllo dello stato

Dopo l’installazione devi verificare che il servizio sia presente e attivo. Il nome esatto dell’unità systemd può variare a seconda della versione del prodotto e del componente installato, quindi conviene prima scoprire i servizi disponibili e poi controllare lo stato di quello corretto.

systemctl list-unit-files | grep -i veeam
systemctl status <nome-servizio>
journalctl -u <nome-servizio> -b --no-pager

L’esito atteso è un servizio abilitato o almeno avviabile, senza errori di libreria, permessi o collisioni con altri processi. Se trovi errori nel journal, leggili prima di cambiare configurazione: spesso indicano un problema banale come una dipendenza mancante, un path non raggiungibile o un modulo kernel non disponibile.

Un controllo utile è anche quello dei binari installati e del percorso di configurazione:

rpm -ql veeam 2>/dev/null | head
# oppure
apt list --installed 2>/dev/null | grep -i veeam

Se il prodotto installa un’interfaccia testuale o un comando di configurazione, avvialo solo dopo aver letto la documentazione della versione corrente. In molti casi puoi configurare repository di backup, credenziali, retention e schedule senza toccare file manualmente, e questo riduce il rischio di sintassi errata.

Configurazione iniziale: repository, credenziali e criteri di backup

La parte più delicata non è l’installazione, ma la definizione del target di backup. Veeam Agent for Linux può salvare su storage locale, share di rete, repository Veeam o destinazioni compatibili con il tuo scenario. La scelta dipende dal RPO, dalla banda disponibile e dal livello di isolamento che vuoi mantenere.

In produzione evita di mettere credenziali in chiaro in file lasciati a mano in giro. Se devi usare script, limita i permessi, usa account dedicati e conserva i segreti nel secret manager aziendale o nel sistema di vault che già usi per gli altri servizi. Se un file di configurazione contiene password, redigilo prima di condividerlo e ruota l’account se è finito fuori controllo.

Un approccio sano è questo: prima definisci il repository, poi fai un backup di test e solo dopo imposti la pianificazione. Se il backup iniziale fallisce, è inutile schedulare job ripetitivi che falliranno allo stesso modo.

1. Definisci la destinazione del backup e verifica la raggiungibilità di rete o storage.
2. Crea o valida un account con privilegi minimi necessari.
3. Esegui un job manuale di prova su un set ridotto di dati.
4. Controlla il report e la presenza del restore point.
5. Solo dopo imposta retention e pianificazione periodica.

Se usi una share SMB o NFS, controlla anche latenza e stabilità del mount. Un backup che parte ma si interrompe a metà spesso non è un bug dell’agente: è storage instabile, mount con opzioni sbagliate o saturazione della rete.

Verifica pratica: primo backup e primo restore

La prova vera non è vedere il pacchetto installato, ma completare un backup e ripristinare almeno un file o una directory di test. Senza restore testato hai solo una promessa, non una protezione. Questo vale ancora di più su sistemi dove il backup serve per compliance o per continuità operativa.

La verifica minima dovrebbe rispondere a tre domande: il job parte, finisce con successo e produce un restore point utilizzabile. Se una di queste tre condizioni manca, non considerare l’installazione conclusa dal punto di vista operativo.

systemctl status <nome-servizio>
journalctl -u <nome-servizio> -b --no-pager | tail -n 100

Quando fai il primo restore, prova un file piccolo ma rappresentativo. Se il restore fallisce, controlla permessi di destinazione, spazio libero e coerenza del repository. Se il problema è di accesso, è spesso più semplice correggere account e ACL che rilanciare tutto il job.

Errori comuni durante download e installazione

Gli errori più frequenti si ripetono quasi sempre negli stessi punti. Il primo è il repository sbagliato: un URL copiato male o riferito a una release diversa dalla tua distro. Il secondo è la mancanza di dipendenze base, soprattutto su installazioni minimali. Il terzo è la mancata corrispondenza tra architettura del pacchetto e macchina target.

• Repository non raggiungibile: verifica DNS, proxy e firewall con curl -I <URL>.
• Dipendenze mancanti: controlla l’output del package manager e installa i pacchetti richiesti dai repository ufficiali.
• Pacchetto errato: confronta uname -m con l’architettura del file scaricato.
• Servizio non parte: esamina journalctl e i path di configurazione indicati dal vendor.

Un caso da non sottovalutare è il blocco da parte di proxy o ispezione TLS. Se il download fallisce in modo intermittente, non dare per scontato che il file sia il problema: spesso il collo di bottiglia è fuori dal server, nel percorso verso il repository.

Buone pratiche operative dopo l’installazione

Dopo aver installato Veeam Agent for Linux, tratta il sistema come qualsiasi altro componente critico: monitora lo stato del servizio, conserva la configurazione in modo versionato e verifica periodicamente che il repository di backup sia ancora raggiungibile. Il backup non è un evento, è un processo continuo.

Se il server è esposto a patch frequenti o a cambi di kernel, pianifica anche la compatibilità dell’agente con gli aggiornamenti di sistema. Una macchina che aggiorna il kernel senza controllare il comportamento del backup rischia di scoprire il problema troppo tardi, cioè quando serve davvero ripristinare.

Per ambienti con più host, definisci uno standard: stessa modalità di installazione, stessi criteri di retention, stessi controlli di verifica e stessa procedura di restore test. La standardizzazione qui vale più di qualunque ottimizzazione creativa fatta host per host.

Schema operativo consigliato

Se devi portare a termine l’attività in modo ordinato, questa è la sequenza più solida:

1. Identifica distro, architettura e kernel.
2. Recupera repository e chiave ufficiali dal sito Veeam.
3. Installa il pacchetto con il gestore della tua distribuzione.
4. Verifica servizio, log e componenti installati.
5. Configura repository di backup e credenziali con privilegi minimi.
6. Esegui un backup di test e un restore di prova.
7. Solo dopo attiva la schedulazione definitiva.

Questa sequenza riduce il rischio di installazioni incomplete e ti dà un punto di ritorno chiaro se qualcosa non va. Se il repository cambia o la versione del pacchetto viene aggiornata, il controllo iniziale ti evita di inseguire errori a valle.

Conclusione operativa: cosa considerare davvero “installato”

Veeam Agent for Linux non è “installato” quando il pacchetto compare nel package manager. Lo è quando il servizio risulta sano, il backup di test termina con successo e il restore funziona su un dato reale ma non critico. Tutto il resto è solo preparazione.

Se stai lavorando in un contesto eterogeneo, tieni traccia della versione installata, del metodo usato per il download e del repository configurato. Ti servirà al prossimo audit, al prossimo upgrade e soprattutto al primo incidente in cui dovrai capire in fretta se il problema è dell’agente, del sistema o della rete.