Microsoft ha rilasciato ieri un importante aggiornamento Out-Of-Band (OOB), ovvero una fix di emergenza da installare prima dei prossimi update di aprile, per Windows Server versioni 2022, 2016 e 2012 (non ancora disponibile per la versione 2019).
Questo update corregge un know issue che è stato identificato nell’ultimo update di marzo: il problema affligge il servizio LSASS degli Active Directory Domain Controllers, in cui un memory leak durante le richieste di autenticazione kerberos può causare il crash del servizio e il reboot inaspettato del server.
Microsoft consiglia di installare subito l’aggiornamento nel caso il sistema rientri nella casistica descritta.
Questo aggiornamento viene incontro soprattutto a quei clienti che per esigenze di utilizzo devono mantenere la compatibilità con vecchi hypervisor (ad esempio VMware vSphere/Esxi 5.5).
La patch contiene alcune fix del prodotto, ed anche qualche correzione di sicurezza di componenti di terze parti presenti nel software, come ad esempio VDDK, OpenSSL, liblz4, zlib e Putty:
Nota importante: se decidete di installare questa patch, non potrete più passare alla V12.1, ma dovrete attendere l’uscita del prossimo minor update V12.2 (previsto nella seconda metà del 2024).
Per cui, se siete alla V11 e non avete problemi di compatibilità con il resto dell’infrastruttura, il consiglio è di passare all’ultima versione V12.1, sfruttando subito le tante funzionalità aggiuntive.
Di seguito un ultimo link che può risultare utile durante la pianificazione degli aggiornamenti, quello dell’upgrade-path di Veeam B&R.
Le informazioni, ormai sempre più sotto forma di dati digitali, sono una risorsa fondamentale per tutte le aziende, dalle più piccole alle più grandi.
Lo standard ISO/IEC 27001 ci ricorda quali sono i requisiti e le best practice per gestire al meglio la sicurezza di queste informazioni.
I tre principi cardine sono:
Riservatezza: non tutti possono accedere ad una determinata informazione privata, solo le persone con le giuste autorizzazioni
Integrità delle informazioni: i dati che l’organizzazione utilizza per svolgere la propria attività o che tiene al sicuro per gli altri devono essere conservati in modo affidabile, assicurando che non vengano cancellati o danneggiati
Disponibilità dei dati: i dati devono essere sempre disponibili, in modo tale chiunque sia autorizzato possa accedere alle informazioni ogni volta che è necessario
IL RUOLO DI VEEAM
Per proteggere questi dati, software come Veeam Backup & Replication sono indispensabili, perché contribuiscono a perseguire i tre suddetti principi cardine della sicurezza delle informazioni.
Nello specifico, Veeam ci consente di:
creare dei backup e repliche dei nostri dati, ovvero copie ulteriori delle informazioni originali → aiuta a preservare l’integrità
tenere i backup protetti da eventuali interventi malevoli, problemi hardware o eventi naturali disastrosi , sfruttando immutabilità, air gapped e offsite copy→ aiuta a tenere il dato sempre disponibile
salvare i nostri dati attraverso protocolli sicuri e in maniera criptata → aiuta a mantenere la confidenzialità
Tutto questo si traduce nella regola fondamentale di Veeam, la famosa 3-2-1-1-0.
A questa regola, appunto, aggiungerei una caratteristica da applicare globalmente: l’encryption.
VEEAM ENCRYPTION – PERCHÈ E COME FUNZIONA
Così come l’encryption sul dato originale, l’encryption dei backup non è una pratica sempre utilizzata, a volte per motivi di “compatibilità” con le appliance di deduplica, altre volte perché ci si dimentica o non la si ritiene così necessaria.
A mio avviso, invece, è uno dei punti chiave per garantire la confidenzialità delle informazioni.
Sia se salviamo i backup su un cloud esterno, che all’interno del nostro datacenter, è indispensabile garantire che chiunque abbia accesso a questi dati non riesca a leggerli se non autorizzato.
L’esfiltrazione dei dati è una cosa che può impattare anche i nostri backup, e se non sono criptati qualunque istanza di VBR può leggerli.
Veeam garantisce sia l’encryption in transit, cioè durante la copia del dato originale verso il repository designato, che l’encryption at rest, cioè applicata al backup stesso.
La traffic encryption è basata su TLS (dall’ultima versione di Veeam v12.1 è supportato anche TLS 1.3).
L’encryption dei file di backup, invece, è basata sulle librerie Veeam Cryptographic Module and Microsoft Crypto API, che sono entrambi FIPS compliant.
Per criptare i dati, si utilizza un algoritmo di encryption single-key, ovvero una chiave unica per criptare e decriptare, sfruttando lo standard AES-256.
Senza andare troppo nel dettaglio di Cipher, KEX e quant’altro, quello che vorrei descrivere sono lo schema gerarchico e il workflow dell’encryption in Veeam:
Partendo dal basso, troviamo:
session key: utilizzata sui data block di backup, cambia ad ogni sessione di backup
metakey: utilizzata per criptare i metadati dei backup; come la session key, cambia ad ogni sessione di backup
storage key: le due precedenti chiavi sono a loro volta crittografate dalla storage key, la quale viene utilizzata a livello di restore point; quando una catena di backup, infatti, subisce una trasformazione e alcuni backup data block vengono riscritti all’interno di un full (ad esempio durante operazioni di syntetic full, reverse incremental, forever forward incremental..), un singolo restore point conterrà più session keys. La singola storage key è in grado di agire sul singolo restore point. Essa viene mantenuta nel config db fino a scadenza della retention del restore point associato
user key: quando il Veeam administrator crea una encryption password, e successivamente attiva l’encryption su un job di backup, questa password viene utilizzata per generare la user key. Questa chiave, che agisce appunto a livello di job, viene utilizzata per criptare le storage keys che saranno generate per ogni singolo restore point all’interno della catena di questo job
backup server keys: coppia di chiavi opzionale, generata quando si aggancia un backup server al VBEM; secondo l’algoritmo asimmetrico RSA, la chiave pubblica viene passata al VBEM, mentre la chiave privata viene mantenuta nel db del VBR. La coppia di chiavi sarà utilizzata per identificare in maniera sicura il backup server durante l’eventuale richiesta di decriptazione verso l’Enterprise Manager, secondo la funzionalità di “password loss protection”
enterprise manager keys: coppia di chiavi opzionale, generata quando si aggancia un backup server al VBEM; secondo l’algoritmo asimmetrico RSA, la chiave pubblica viene passata al backup server, ed è utilizzata per criptare le session keys allo stesso modo della user key; la chiave privata viene mantenuta nel db del VBEM ed utilizzata in caso di decriptazione, secondo la funzionalità di “password loss protection”
Durante un job di backup quindi, insieme ai data block criptati vengono salvati i crittogrami delle session key, metakey, storage key (una criptata con la user key e una con la EM public key), user key e EM public key, che serviranno poi per identificare le corrispondenti chiavi in fase di restore.
PASSWORD LOSS PROTECTION
Come anticipato in precedenza, esiste una funzionalità di Veeam Enterprise Manager che consente una seconda chance di decriptare i backup nel caso in cui nel nostro backup server non sia più presente la password, magari perché si tratta di vecchi backup che erano stati rimossi dalla configurazione.
Prerequisiti
VUL o licenze socket di tipo almeno Enterprise
EM e backup server originali connessi
Dalla Veeam 12.1, la funzionalità di password loss protection supporta anche l’integrazione con KMS.
La coppia di chiavi creata dall’EM è detta keyset. È possibile creare nuovi keyset, esportarli o importarli.
È possibile settare la generazione automatica di nuovi keyset, e il retention period degli stessi.
Il processo di restore senza password si compone dei seguenti passaggi:
1) il Veeam admin inizia il processo di “encryption key restore” dal backup server
2) questo wizard genera una request che contiene, in maniera crittografata, i riferimenti della storage key e della EM public key utilizzate in fase di backup per criptare quei dati
3) la request viene passata al EM admin
4) EM admin inizia il “password recovery” wizard nell’EM e inserisce la request ricevuta
5) EM trova il corrispondente keyset
6) EM, utilizzando la EM private key, decripta la storage key e la inserisce in un file di risposta
7) EM admin invia questa risposta al Veeam admin
8) il Veeam admin inserisce questa risposta nel wizard di “encryption key restore”, terminando così il processo di decriptazione
Limitazioni: se si perde il backup server, o l’EM, o il keyset dell’EM non si potrà utilizzare la procedura di recovery.
L’unico modo per essere veramente al sicuro quando si utilizza l’encryption è non perdere mai la user password.
Quindi, la regola fondamentale è: SALVARE LA PASSWORD DI ENCRYPTION IN MODO SICURO, magari applicando anche per questo dato la regola d’oro 3-2-1-1-0!
CONCLUSIONE
In questi tempi in cui gli attacchi cyber sono sempre più frequenti, considerare i backup come qualcosa di secondario è un errore da non commettere, devono essere visti più come un’estensione indispensabile dei nostri dati.
Utilizzare le best practice è fortemente consigliato..regola 3-2-1-1-0 con encryption!
La notizia che stavamo aspettando è finalmente arrivata: con l’uscita di qualche giorno fa della versione Esxi 8.0 U2b, VMware conferma nelle release notes che il bug che nella versione 8.0 U2 affliggeva la funzionalità del Change Block Tracking (CBT) è stato risolto.
In vSphere 8.0 Update 2, to optimize the open and close process of virtual disks during hot extension, the disk remains open during hot extend operations. Due to this change, incremental backup of virtual disks with CBT enabled might be incomplete, because the CBT in-memory bitmap does not resize, and CBT cannot record the changes to the extended disk block. As a result, when you try to restore a VM from an incremental backup of virtual disks with CBT, the VM might fail to start.
Il bug, documentato nella KB ufficiale95965, affliggeva i virtual disk con CBT abilitato ed estesi a caldo, e provocava una possibile perdita o corruzione di dati in fase di restore tramite software di backup.
Questo perché, a causa del bug, alcune informazioni non venivano correttamente aggiornate nel CBT stesso, che è il meccanismo utilizzato appunto dai software di backup per leggere solamente i blocchi modificati rispetto all’ultimo incrementale, senza dover fare ogni volta uno scan completo del disco.
Ricordiamo, comunque, che la patch non corregge le eventuali VM che erano incappate nel bug prima dell’installazione di questo update.
Per questo motivo, è necessario applicare il workaround consigliato nella suddetta KB, ovvero effettuare il reset del CBT e far girare un nuovo active full.
Consigliamo, infine, di effettuare sempre dei test di restore (automatizzati o manuali) per assicurarci che i nostri backup siano validi.
In un precedente post, siamo andati ad esplorare le nuove e più interessanti funzionalità della versione 12.1 di Veeam B&R.
In questo post andremo più nel dettaglio del tool che ci consente di tenere sotto controllo lo stato della nostra infrastruttura di backup: il Security and Compliance Analyzer.
INTRODUZIONE
Quando progettiamo e implementiamo le nostre infrastrutture di backup, fare attenzione alle regole di sicurezza è ormai imprescindibile.
Esistono una serie di considerazioni generali che ci aiutano ad hardenizzare i nostri server, cosi come molte best practice che dovrebbero essere applicate ai nostri backup.
Il nuovo tool Security and Compliance Analyzer ci consente appunto di avere un resoconto semplice e intuitivo dell’implementazione di queste best practice sul nostro server di backup.
Andiamo a vedere nel dettaglio il suo funzionamento.
IL TOOL
L’accesso al tool è ben visible nella barra principale della Veeam Console:
Come anticipato in precedenza, i controlli sono divisi in due sezioni: “Backup Infrastructure Security” e “Product Configuration”.
BACKUP INFRASTRUCTURE SECURITY
Come possiamo vedere, si occupa di controllare l’implementazione di di alcune buone pratiche definite per il sistema operativo Windows che ospita il nostro backup server.
I primi settaggi che vengono consigliati riguardano la disabilitazione di quei servizi considerati critici, poiché consentono l’interazione remota con il nostro server, ovvero il “Remote Desktop”, il “Remote Registry” e il “Windows Remote Management”.
Si passa poi al poco considerato Windows Firewall: la best practice è quella di tenerlo sempre attivo, andando a lavorare con le inbound e outbound rule in caso di necessità. Nota: Veeam B&R crea automaticamente le firewall rule necessarie per far comunicare i propri componenti tra loro.
Si consiglia poi di disabilitare le funzionalità “WDigest credentials caching” e “Web Proxy Auto-Discovery service” per prevenire attacchi alle credenziali o di tipo MITM.
Il controllo seguente è sulle versioni deprecate di SSL e TLS, come SSL 2.0, SSL 3.0, TLS 1.0 e TLS 1.1, che dovrebbero essere anch’esse disabilitate.
Per quanto riguarda possibili attacchi malware basati su script, buona norma è tentare di limitarli disabilitando lo “Windows Script Host”.
Tornando ai protocolli deprecati, anche SMBv1 è tra quelli da disabilitare, poiché affetto da numerose vulnerabilità. Nota: a partire da Windows Server 2016 è disabilitato di default.
L’ultimo protocollo da disabilitare è il “Link-Local Multicast Name Resolution”, per limitare attacchi di spoofing e MITM.
Infine, viene verificata la sicurezza sul protocollo SMBv3, controllando che siano attive le impostazioni per prevenire attacchi di tipo NTLMv2 relay.
PRODUCT CONFIGURATION
Passiamo ora ai controlli sulle impostazioni lato software.
Le strategie e le configurazioni che Veeam ci consiglia sono ovviamente mirate alla salvaguardia dei nostri backup.
MFA per la VBR console: dall v12 è possibile abilitare la multi-factor authentication sulla console di backup.
Immutable or offline media: per proteggere i file di backup, si consiglia l’utilizzo di almeno un repository con la funzionalità di immutabilità dei dati attiva o un media che può essere scollegato dalla rete, come tape o rotated drives.
Password loss protection: settaggio di Veeam Enterprise Manager che consente di decriptare i nostri dati di backup nel caso in cui la password di encryption venga persa.
Dominio o non dominio?: Veeam ci consiglia di lasciare il nostro server, e il resto dei componenti dell’infrastruttura, a Workgroup. Nota: nel caso in cui si voglia utilizzare il join con AD, è buona pratica creare un dominio di management dedicato esclusivamente all’ambiente di backup.
Email notification: ricordarsi sempre di attivare le notifiche tramite email, è indispensabile per tenere sotto controllo l’esito dei backup e gli altri eventi che accadono nel sistema.
3-2-1 rule: la regola d’oro ci consiglia di avere almeno 3 copie del dato (compreso il dato originale, quindi due copie di backup), su almeno 2 media differenti e 1 copia offsite. Nota: la regola si è ormai evoluta in 3-2-1-1-0, dove il secondo 1 è la copia offline/immutabile, e lo 0 indica la necessità di implementare una procedura automatizzata di validazione dei nostri backup, e senza errori durante i test di verifica.
Reverse Incremental: è il metodo che produce più operazioni di lettura e scrittura sul nostro repository, da abbandonare in favore dell’incrementale standard.
Unknown Linux servers: nel caso si debbano aggiungere server linux alla nostra infrastruttura di backup, è consigliato trustarli in maniera manuale piuttosto che automatica.
Configuration Backup: da best practice, il backup della configurazione dovrebbe essere salvato su un repository esterno al backup server stesso. Nota: dalla 12.1 è possibile selezionare anche per questo task un repository object storage immutabile.
Proxy traffic encryption: se i nostri proxy virtuali utilizzano il transport mode di tipo network, è consigliato l’utilizzo dell’encryption (NBDSSL).
Physical Hardened repository: per ridurre la superficie di attacco, il repository di tipo hardened dovrebbe risiedere su un server fisico (e con dischi locali) anziché su uno virtuale.
Network traffic encryption: per consentire una comunicazione sicura nella nostra rete di backup, sia verso internet che verso le reti private, si consiglia di abilitare globalmente l’encryption nelle impostazioni generali del software.
Linux authentication: la best practice consiglia di non utlizzare l’autenticazione basata su password per i nostri server linux, ma di entrare in SSH tramite l’utilizzo della coppia chiave pubblica-chiave privata, prevenendo attacchi di tipo brute force e MITM.
Backup services: si consiglia di utilizzare “Local System” come account per i nostri servizi Veeam.
Configuration backup encryption: si consiglia di utilizzare l’encryption anche sul backup della configurazione di Veeam, per una gestione più sicura dei dati sensibili presenti nel DB.
Password rotation: il controllo è sulle credenziali dei vari componenti aggiunti alla nostra infrastruttura di backup e sulla password di encryption, che dovrebbero essere cambiate almeno una volta all’anno.
Hardened repository access: come best practice, l’SSH su questo tipo di repository dovrebbe essere disabilitato.
S3 object lock type: questo controllo verifica che l’immutabilità impostata sugli S3 aggiunti su Veeam sia di tipo Compliance (non modificabile) e non di tipo Governance (modificabile), andando incontro ad eventuali politiche sul trattamento del dato (es: GDPR) ed ovviamente alla sicurezza di effettiva immutabilità dei backup.
Backup encryption: soprattutto se i nostri backup vengono salvati su un repository cloud, è buona norma abilitare l’encryption a livello di singolo job.
Latest updates: si consiglia di tenere il software Veeam B&R sempre aggiornato all’ultima release/patch.
IMPLEMENTAZIONE
Per facilitare l’implementazione della maggior parte di queste best practice, Veeam ha messo a disposizione sulle proprie KB uno script in powershell che corregge tutti gli 11 punti relativi alla backup infrastructure e 2 punti relativi alla product infrastructure, mentre le impostazioni che necessitano di settaggi custom (come, ad esempio, l’impostazione del nostro mail server, la scelta di un repository, gli utenti per cui attivare l’MFA, ecc..) sono ovviamente lasciate alla configurazione manuale da parte del backup administrator.
Il tool può essere utilizzato sia in maniera interattiva che automatica.
È possibile, infatti, impostare un report con schedulazione giornaliera e invio tramite email.
Infine, è possibile anche escludere uno o più parametri dai controlli, marcandoli come “suppressed”.
CONCLUSIONE
Non ci stancheremo mai di ripetere quanto sia importante la sicurezza, soprattutto per i backup, che sono la nostra ultima difesa contro la perdita o la corruzione dei nostri dati. Questo strumento migliorato è un buon punto di partenza per aiutarci a tenere la situazione sotto controllo.
Concludiamo il post riproponendo i soliti altri link utili riguardanti la sicurezza e le best practice, con la speranza che anche il Security and Compliance Analyzer venga sempre più sviluppato e migliorato secondo le linee guida in continua evoluzione.
In questo post andiamo a descrivere in maniera generale le nuove e principali funzionalità dell’ultima versione Veeam Data Platform 12.1.
Senza dubbio, la principale abilità aggiunta al motore del software è la Malware Detection, ovvero la capacità di individuare ed identificare i cyber attacchi, sfruttando tre nuove tecnologie:
Inline malware detection: basata su metodi di ML (Machine Learning), effettua un’analisi in tempo reale e a basso impatto del flusso di backup per individuare possibili attività di criptazione in atto sui dati
Suspicious file system activity detection: ricerca, tramite l’indicizzazione del file system guest, file sospetti, come estensioni di malware conosciute, ransom notes, ecc..; analizza inoltre attività del file system, comparando gli indici precedenti allo scopo di individuare modifiche sospette, come ad esempio sul numero e la tipologia dei file presenti
Early threat detection: sfrutta le Veeam Incident API per ricevere da EDR/XDR notifiche su possibili infezioni in atto nei server della nostra infrastruttura; questo consente a Veeam B&R di marcare i corrispondenti successivi backup come compromessi; è possibile inoltre attivare un backup automatico sul server infetto come risposta a questo evento, in modo tale da cercare di mettere al sicuro più file possibili prima che l’attività di criptazione venga completata
Il secondo importante aspetto riguarda la capacità di rispondere ad un possibile attacco malware in maniera più rapida ed efficiente. Le funzionalità in grado di svolgere questa importante innovazione sono:
Scan backups with YARA: oltre al classico scan con antivirus, in questa versione Veeam ha introdotto la possibilità, per effettuare i controlli in fase di restore, di ultilizzare anche le YARA rule, parti di codice basati su pattern specifici a seconda del tipo di ricerca o dei file che si vogliono trovare (ad esempio per una particolare famiglia di malware); lo scan è ora in grado di ricercare più rapidamente, in maniera sequenziale o binaria, un file di backup non infetto, velocizzando le operazioni di restore a seguito di un attacco; è possibile inoltre utilizzare job di SureBackup in modalità only scan (senza Virtual Lab)
Avoid reinfection with threat tracking: in questa nuova versione, il software è in grado di individuare e tenere traccia di quali sono i potenziali backup infetti, in modo da evitare eventuali restore di file già compromessi; in caso di falsi positivi, è possibile settare manualmente una esclusione
Event forwarding: con l’introduzione del supporto di Syslog, Veeam è in grado di inviare qualsiasi evento ad un SIEM di nostra scelta, in modo tale da attivare meccanismi di reazione a determinati incidenti di sicurezza registrati dal software
Infine, è stata migliorata la sicurezza e la compliance di determinate operazioni.
Four-eyes authorization: impostazione che attiva un doppio controllo su particolari operazioni sensibili, come ad esempio la cancellazione di un backup, di un repository o l’aggiunta di un nuovo Veeam Administrator, permettendo di limitare gli errori accidentali o i tentativi di compromissione da parte di un utente malevolo; nello specifico, quando un admin effettua una di queste operazioni, è richiesta l’approvazione di un secondo admin entro un lasso di tempo configurabile, scaduto il quale la richiesta viene rigettata
Key Management Server (KMS) integration: grazie all’integrazione con KMIP (Key Management Interoperability Protocol), è ora possibile utilizzare un qualunque KMS supportato per effettuare la rotazione automatica delle chiavi di encryption
Security and compliance analyzer : tool integrato nella VBR console, consente di verificare in maniera manuale o schedulata la compliance a specifiche baseline di sicurezza della nostra infrastruttura di backup, assicurando che siano applicate le varie best practice del software; è stato migliorato rispetto alla v12, introducendo numerosi controlli in più, e attivando la possibilità di schedulare un report ed inviarlo tramite email
Veeam Threat Center: una specifica dashboard di Veeam ONE è ora integrata nella VBR console, e consente di mettere in evidenza gli eventi malevoli identificati, i possibili rischi e punti critici, nonché uno score sullo stato generale della nostra infrastruttura di backup basato sull’implementazione delle varie best practices consigliate dal software
Altre importanti funzionalità sono:
Backup di object storage: grazie ad una architettura storage-agnostica, è stata introdotta la possibilità di effettuare il backup di sorgenti di tipo object storage, proteggendo i dati dei nostri bucket, siano essi on-prem o in cloud
Sviluppo del motore CDP: la Veeam Continous Data Protection, che consente di ottenere gli RPO più piccoli per i nostri backup, è stata migliorata sia in termini di funzionalità (4x numero di VM-vDisk supportati) che di efficienza (ridotto di 2x i requisiti computazionali); introdotta inoltre la possibilità di effettuare test di failover senza interrompere le attuali repliche
Veeam AI assistant: ecco all’interno della VBR console il nostro “assistente personale” basato su modello OpenAI, che può essere utilizzato, grazie al suo apprendimento della documentazione ufficiale Veeam, per aiuti e consigli sulla nostra infrastruttura di backup
Appena possibile, in futuri post si andranno ad approfondire singolarmente alcune di queste nuove funzionalità.
Per i dettagli di tutte le numerosissime feature introdotte con la Veeam Data Platform 12.1 vi rimando al seguente documento ufficiale.
Per poter aggiornare il software in maniera sicura e controllata, è bene valutare prima una serie di aspetti fondamentali.
ATTIVITA PROPEDEUTICHE
LICENZA
Per poter procedere con l’aggiornamento è necessario effettuare, come prima cosa, la verifica di validità della licenza, ovvero il contratto di supporto deve essere attivo e non scaduto.
REQUISITI E MATRICE DI COMPATIBILITA
Il secondo passaggio è la verifica dei requisiti minimi di compatibilità dei vari sistemi/componenti che interagiscono con il nostro ambiente di backup, ad esempio: il backup server, i proxy, gli hypervisor, i backup repository, etc..
Per tutti questi componenti dobbiamo assicurarci che tutte le loro specifiche hardware e software siano in matrice con la nuova versione di Veeam 12.1 (ad esempio, le versioni di vCenter e di Esxi devono essere almeno alla 6.x)
È inoltre necessario verificare l’upgrade path del software stesso, ovvero qual è la versione minima che dobbiamo avere per poter aggiornarlo direttamente senza dover fare più di step di versione: in questo caso, per poter aggiornare all’ultima build della12.1 (build 12.1.1.56), è necessario avere almeno tra la versione 10a (10.0.1.4854) e la versione 12 (12.0.0.1420 P20230718) .
PORTE E PERMESSI
Come ulteriore consiglio, è sempre bene verificare nuovamente le porte su cui dovranno comunicare i vari componenti e i permessi configurati per svolgere tutte le operazioni, poiché, soprattutto per salti di versione più grandi, potrebbero esserci state modifiche nel tempo sui requisiti necessari.
Per informazioni più dettagliate, potete trovare la checklist completa con tutti i controlli consigliati da Veeam qui o sul documento ufficiale di release notes
Come step operativi prima di iniziare l’aggiornamento, ricordarsi di:
controllare che l’ultima sessione di backup sia terminata con successo
disabilitare tutti i job; se è presente qualcosa in running, attendere possibilmente il completamento
effettuare il backup del database SQL
effettuare il backup della configurazione di Veeam
effettuare una snapshot del backup server (in caso di server virtuale)
Ok, partiamo ora con l’installazione!
AGGIORNAMENTO
Start setup
Selezionare il prodotto da aggiornare
Leggere e accettare il license agreement
Verificare i componenti che verranno aggiornati
Inserire un file di licenza con supporto attivo
Installare, se necessario, eventuali componenti aggiuntivi mancanti
Specificare l’account di servizio
Specificare l’istanza SQL e il nome del DB
Confermare l’eventuale upgrade del database
Iniziare l’aggiornamento
Fine aggiornamento
POST-AGGIORAMENTO
Terminato l’aggiornamento, aprire la console, seguire il wizard di upgrade dei componenti remoti (se non selezionato in fase di upgrade) e riattivare i job disabilitati in precedenza.
Riferimenti ufficiali dell’upgrade con maggiori dettagli qui:
