Per evitare possibili attacchi ransomware, configurare backup immutabili multipli on-prem e cloud in Veeam Backup & Replication v11 rafforza notevolmente la sicurezza dei propri dati.
Una volta che i Repository richiesti sono stati configurati, la configurazione dei job di Backup è lo step successivo da affrontare.
Blog serie
Veeam v11: configurare backup immutabili multipli on-prem e cloud - pt.1
Veeam v11: configurare backup immutabili multipli on-prem e cloud - pt.2
Configurare il Backup Job primario
Accedere all'area Home e selezionare la sezione Backup. Effettuare un click con il tasto destro del mouse sulla voce Backup e selezionare Backup > Virtual machine > VMware vSphere.
Inserire un Name per il Backup Job e cliccare su Next.
Cliccare Add e selezionare le VM da proteggere (in questo esempio sono utilizzati i Tag vSphere). Cliccare Next.
Selezionare il Backup repository locale e specificare la Retention policy (14 giorni nell'esempio). Cliccare Next.
Abilitare il VSS processing se richiesto e cliccare su Next.
Specificare la Schedule e cliccare su Next.
Cliccare Finish per salvare la configurazione.
Il Backup Job creato.
Configurare i backup immutabili con le Backup Copy
Dall'area Home, effettuare un click con il tasto destro del mouse su Backup Copy e selezionare la voce Backup Copy > Virtual machine > VMware vSphere backup.
Inserire il Name per il Backup Copy e specificare Immediate copy (mirroring) come Copy mode da utilizzare. Cliccare Next.
Cliccare Add e selezionare il Backup Job da processare. Cliccare OK.
Una volta selezionati gli oggetti da processare, cliccare Next.
Selezionare lo Scale-out Repository creato in precedenza come Backup repository e specificare la Retention policy. Verificare che la retention sia la stessa o maggiore della retention immutabile specificata nell'Hardened Repository. Come prerequisito per utilizzare l'Immutability, è necessario abilitare l'opzione Keep certain full backups longer for archival purposes e cliccare Configure. Configurare GFS in base ai requisiti aziendali e cliccare su OK.
Configurata la destinazione, cliccare Next.
Selezionare Direct come modalità Data Transfer e cliccare su Next.
Cliccare Apply.
Abilitare l'opzione Enable the job when I click Finish per eseguire il backup immediatamente. Cliccare Finish per salvare la configurazione.
Il Backup Copy job creato.
Testare il backup
Per testare l'intera configurazione del backup, effettuare un click con il tasto destro del mouse sul Backup Job creato e selezionare Start.
Backup primario
Il primo backup viene eseguito e salvato nel Repository primario.
A seconda della quantità di dati da processare, dopo alcuni minuti il Backup Job viene completato correttamente.
Prima Backup Copy immutabile on-prem
Poichè è stata configurata l'Immediate copy (mirroring) come Copy mode nei Backup Copy Job, entrambi i job vengono avviati non appena un restore point appare nel repository corrispondente.
Il primo Backup Copy job salvato nell'Hardened Repository on-premises viene completato correttamente.
Seconda Backup Copy immutabile in cloud
Quando la prima Backup Copy è stata completata, il processo di offload verso l'Object Storage in cloud (Wasabi) si avvia immediatamente (il mirroring è stato configurato come modalità di copia).
Dopo alcuni minuti anche la seconda Backup Copy immutabile viene completata correttamente.
Risultato
Dopo aver processato entrambi i Backup e Backup Copy job, abbiamo i seguenti backup disponibili:
- Un Backup salvato nel Repository primario locale.
- Una Backup Copy immutabile salvata nell'Hardened Repository on-prem.
- Una seconda Backup Copy immutabile salvata nell'Object Storage in cloud.
I backup sono immutabili?
Per testare se i backup sono davvero immutabili, proviamo a cancellarli dai rispettivi repository.
Backup on-prem
Accedere all'area Backups > Disk (Copy) ed effettuare un click con il tasto destro sulla Backup Copy appena processata. Selezionare l'opzione Delete from disk.
L'operazione fallisce perchè i backup non possono essere cancellati dovuto all'immutability. L'errore segnalato è il seguente:
Error [Backup Copy [3-2-1-1-0]\Backup Website [3-2-1-1-0]] Failed to delete backup Error: Unable to delete backup in the Capacity Tier because it is immutable until 22 December 2021 16:11:09.
Immutable Cloud backup
Accedere all'area Backups > Object Storage ed effettuare un click con il tasto destro del mouse sulla Backup Copy appena processata. Selezionare l'opzione Delete from disk.
Anche in questo caso, l'operazione fallisce perchè i backup non possono essere cancellati dovuto all'immutability.
Questa configurazione con Veeam Backup & Replication v11 garantisce un alto livello di sicurezza proteggendo le due copie di backup contro cancellazioni, sovrascritture ed attacchi ransomware.
Veeam Backup & Replication v11 è disponibile per il download come 30-day trial.
Buongiorno Paolo e grazie per condividere queste utilissime guide. Le ho seguite per configurare la mia installazione di veeam ma mi ritrovo con alcuni punti "oscuri". Qui di seguito la mia configurazione:
-- macchina fisica veeam con storage locale usata per la prima copia di backup ( 15 vm, un job per ogni vm)
-- SOBR basata su un server fisico Linux Ubuntu con XFS + 10 TB di spazio S3 con object lock attivo usato per la backup copy. retention 10 giorni e immutability impostata a 7 gg.
Lo spazio dati usato sul server veeam con una retention di 15 giorni e forever forward attivo è di circa 6 TB.
Ho configurato tutto seguendo la tua guida e ha tutto funzionato al primo colpo ma ho alcuni dubbi riguardanti l'occupazione e l'offload copy. Se non ho capito male, impostando la GFS dei backup copy job a 1 weekly backup, una volta alla settimana viene creato un sinthetic full che però sfogliando lo storage ho notato occupare esattamente lo stesso spazio del primo full generato. Ho letto che i full sintetici con xfs attivo occupano pochissimo spazio e vengonod efiniti storage-less.... Io invece vedo 2 .vbk distinti ognuno della stessa dimensione. Inoltre avendo 3 vm che "pesano" ognuna 1,3 TB cadauna, gestire l'offload del sintetico settimanalmente mi diventa impossibile visto che 1 sola macchina impiega 30 ore per completare l'offload del full. Inoltre se di fatto mi serve il doppio dello storage per gestire la questione GFS, il tutto mi diventa ingestibile.... C'è un fondo di verità in quanto scritto o ho solo detto un sacco di idiozie ?
Grazie e buona giornata
Se il file system XFS è stato correttamente formattato per sfruttare la tecnologia Fast-Clone, la dimensione reale del file VBK è molto ridotta anche se la dimensione mostrata è quella di un Full. Se provi a guardare il tempo impiegato per effettuare il Synthetic Full con Fast Clone dovrebbe essere molto poco... indicazione che sono stati elaborati i metadata e non la creazione di un Full completo.
In effetti per un vbk di circa 500 GB ci ha impiegato poco più di un minuto a fare il synthetic. Mi traeva in inganno il fatto di vedere nelle proprietà dei file di backup la stessa dimensione del full "reale". C'è un modo per vedere esattamente quanto spazio occupa il sintetico? Grazie ancora.
max