NAS backup – GFS su Tape

Molti clienti e partner chiedono se sia possibile implementare una politica di protezione di tipo GFS (Grandfather – Father – Son), quando i dati da proteggere afferiscono ad una NAS (Network Attacched Storage) e la destinazione è una libreria a nastri.

Tale automatismo con la versione attuale di Veeam Backup & Replication (VBR) 12.1 non è ancora disponibile,  cosa invece è già possibile effettuare quando la sorgente del dato è un backup di VM e  Server Fisici.

In questo primo articolo vi aiuterò a raggiungere l’obiettivo, sfruttando la grande flessibilità di  VBR nella creazione dei job di backup.

Nota1: Nel prossimo vi illustrerò come realizzare copie GFS sfruttando una funzionalità poco conosciuta di VBR, il  Tape Copy.

Flessibilità dei Job di Backup:

a. VBR gestisce i nastri utilizzando un architettura che si basa su:

  •  Media Pool (MP) sono i contenitori logici dei nastri e possono afferire ad uno o più job di Backup (nel nostro scenario creeremo un MP per Job).
  • Media Set (MS) identifica i restore point presenti sul nastro (nel nostro scenario creeremo un MS per job di Backup per singolo nastro).

b. La soluzione proprosta è quella di creare job di backup settimanali, mensili e annuali  in modalità full.  Tali backup dovranno essere creati in uno specifica data e i backup dovranno risiedere su pool di nastri creati all’uopo.

Vediamo step by step come procedere:

c.  Creazione dei Media Pool (MP) settimanale e mensile

Immagine 1

Dall’immagine 2 è importante osservare che verrà utilizzato un nuovo nastro per ogni sessione di backup.

Immagine 2

Nell’immagine 3 è mostrato come impostare la retention che in questo scenario è di 4 settimane.

Immagine 3

Per il MP Mensile si utilizza la stessa procedura, modificando la retention in 12 mesi (vedi immagini 4,5,6).

Immagine 4

Immagine 5

Nell’immagine 6 si osserva che la retention per i Full Mensili è di 12 mesi.

Immagine 6

d. Creazione dei job di Backup

Immagine 7

immagine 8

L’immagine 9 evidenzia lo scheduling del job di Backup.

L’ipotesi è di realizzare n job di  backup full per ogni politica GFS.

Nel nostro scenario di esempio è riportato il job della prima settimana (freccia blue) con retention settimanale (freccia verde). Per la seconda, terza e successiva  settimana si procederà in modo del tutto analogo, sostituendo alla voce “Run the full backup automatically” il valore first con second, third ecc.

Immagine 9

L’immagine 10 evidenzia (freccia arancio) che non saranno avviati backup incrementali.

immagine 10

Gli stessi passaggi devono essere  implementati per creare backup GFS di tipo mensile, nell’esempio ho impostato l’avvio del job di backup il 4 sabato del mese (immagine 12 – freccia blue).

Immagine 11

Immagine 12

Immagine 13

Nota 2:

  • Il licensing conteggia le licenze per singolo job di Backup (verisione 12.1).
  • Effettuate dei test per essere certi che lo scenario corrisponda alle vostre necessità. Fatevi aiutare dal supporto Veeam.

Nel prossimo articolo vedremo come utilizzare la funzionalità di Tape Copy.

XFS – Allargare il file system immutabile

In ambiente Veeam Backup & Replication può essere necessario espandere lo spazio allocato di un repository Linux.

Nel mio ambiente è presente un server Ubuntu 22.04 al quale è stato aggiunto  un secondo disco (dev/sdb), formattato come xfs e reso disponibile come mount point /mnt/backup/ .

Il server è utilizzato in modalità hardened repository (immutabilità)
(https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository.html?ver=120).

Vediamo la semplice procedura:

  • I pacchetti da installare sono cloud-guest-utils e gdisk:
    “sudo apt -y install cloud-guest-utils gdisk”
  • Per scoprire la struttura del file system utilizzate il comando:
    “sudo lsblk”

      • Il risultato mostra sizing, mount point del file system del server ubuntu:
        NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
        sda                         8:0    0   16G  0 disk
        ├─sda1                      8:1    0    1M  0 part
        ├─sda2                      8:2    0  1.8G  0 part /boot
        └─sda3                      8:3    0 14.2G  0 part
           └─ubuntu–vg-ubuntu–lv 253:0    0   10G  0 lvm  /
        sdb                         8:16   0  100G  0 disk.                                                                     └─sdb1                      8:17   0   80G  0 part /mnt/backup
        sr0                        11:0    1 1024M  0 rom 
  • Per scoprire se il file system ha spazio ulteriore da allocare:
    “sudo growpart /dev/sdb 1”

    • Il risultato mostra la voce changed
      CHANGED: partition=1 start=2048 old: size=167770079 end=167772126 new: size=209713119 end=209715166
  • Il comando finale che allarga il file system è: sudo “xfs_growfs /mnt/backup/”
  • Verificate il risultato attraverso il comando già visto: sudo lsblk”

Veeam + ReFS: Quanto spazio si risparmia

ReFS è il file system avanzato di Microsoft che migliora la disponibilità dei dati attraverso tecnologie in grado di:

  1. Garantire una maggiore resilienza dei dati memorizzati sul file system.
  2. Aumentare le prestazioni in lettura e scrittura.
  3. Migliorare la scalabilità (si parla di milioni di TB).

Una delle funzionalità più utili ed utilizzate in ambito backup è la tecnologia di Block-Cloning che permette a Veeam Backup & Replication di creare dei backup full di dimensione pari ad un incrementale.

La logica di funzionamento è semplice e consta di 3 fasi:

  1. L’avvio del processo di Backup copia nel Repository di destinazione (ReFS),  i dati incrementali delle VM / Istanze / Server Fisici/ Client da proteggere.
  2. Il File System ReFS si occuperà di memorizzare i nuovi blocchi e di creare i metadati relativi ai dati appena scritti.
  3. L’ opzione “create a Syntethic-full”  di fatto innesca un’operazione a livello di metadati.  ReFS aggiunge ai metadati appena creati, quelli relativi ai backup precedenti creando così un nuovo full figlio dell’unione di tutti i metadati necessari. Per ulteriormente semplificare è  creato un full logico senza che sia copiato/spostato alcun blocco.

Nota 1: Il risultato è non solo un risparmio di spazio ma anche di tempo necessario a realizzare il full.

Orbene, come è possibile quantificare lo spazio disco risparmiato nel repository (RefS)?

Timothy DeWin ha realizzato un tool (blockstat.exe) perfetto per questo calcolo, al quale vi rimando per tutte le opzioni possibili.

Nel mio caso ho risolto la necessità del cliente attraverso:

  1. Creazione attraverso powershell di un file di testo (formato unicode) che ricercasse tutti i file di Backup generati da Veeam Backup & Replication all’interno del repository ReFS. (Vedi immagine 1)
  2. Catturato l’output del comando bloclstat. (vedi immagine 2)

Immagine 1

Immagine 2

Tips VMware – Module MonitorLoop power on failed

Durante le operazioni di manutenzione del laboratorio, improvvisamente una Virtual Machine non era più in grado di avviarsi.

La console del vCENTER indicava un errore sull’inizializzazione del file di swap del server.

Come ogni buon sistemista, prima di effettuare una qualsiasi modifica all’ambiente, ho provato a realizzare il backup della suddetta VM.

Il job si interrompeva a causa del seguente errore: (“An error occurred while taking a snapshot: Invalid change tracker error code“).

Troubleshooting:

  1. Dato che il file di swap gestisce l’over-commitment della memoria, ho provato a modificare la quantità di RAM assegnata.
  2. Ho aggiunto spazio al Datastore sul quale risiedeva la VM per essere certo che VMware avesse sufficiente spazio per gestire il file di swap.
  3. Ho ricercato all’interno del file di configurazione (vmx) differenze rispetto alla configurazione delle altre VM.

Tutti test e le modifiche effettuate non hanno risolto il problema.

Conscio che avrei dovuto modificare la configurazione della VM ho implementato una semplice strategia per:

  • Realizzare il backup della VM attraverso il Veeam Agent for Linux (Il VAL opera a livello di Guest-OS e non di hypervisor).
  • Annotare tutte le modifiche che avrei apportato alle VM (ndr: avevo indossato il cappello di Pollicino, in grado cioè di tornare alla configurazione iniziale in poco tempo).

Il metodico approccio “cambia, annota, controlla e accendi” mi ha permesso di scoprire che il problema era legato alla configurazione della CPU della Virtual Machine.

Reimpostando infatti i valori “CPU reservation” a Zero e “CPU share” a Normal (vedi immagine 1) il problema è rientrato permettendomi così di avviare la VM e effettuarne il backup.

Sapiens nihil affirmat quod non probet (il saggio non afferma nulla che non possa provare)

Immagine 1

Veeam & Google Cloud Platform – Parte 1

Il primo articolo del 2022 è dedicato a come proteggere le istanze Google (GCP).

Il flusso e l’architettura di protezione è riportato nell’immagine 1 dove sono presenti due componenti Veeam.

  1. L’ istanza Veeam Backup for Google Platform (VBGP) ha il compito di realizzare backup e ripristini delle istanze GCP.
  2. Veeam Backup & Replication (VBR) ha l’onere di gestire centralmente la movimentazione dei dati di Backup da e per il cloud (Data Mobility).

Immagine 1

  • Nota 1: VBGP può essere installato in modalità stand alone oppure utilizzando il wizard di VBR.
  • Nota 2: Il presente articolo mostrerà come agganciare da VBR un istanza VBGP già presente in GCP.

Vediamo in modalità dettagliata i passaggi:

Dalla console di VBR scegliamo la voce Backup Infrastructure.

Cliccando con il tasto destro del mouse, selezioniamo la voce add server e successivamente Google Cloud Platform (vedi immagine 2)

Immagine 2

Il prossimo passaggio è quello di inserire le credenziali di accesso al Service Account di Google (immagine 3)

Immagine 3

Il wizard prosegue chiedendovi di inserire il nome del server VBGP già creato (immagine 4)

Immagine 4

Dopo aver selezionato la tipologia di rete presente (immagine 5) il passaggio successivo è quello di inserire le credenziali di accesso al Repository (immagine 6).

Ricordo che la best practice di protezione è quella di effettuare il backup dell’istanza come snapshot, successivamente riversare la snapshot verso il Cloud Object Storage di Google.

Si rispetta così la regola del 3-2-1, avere cioè 3 copie dei dati (Produzione + Snapshot + Object Storage) su due differenti media (Storage primario + Object Storage) con una copia offsite (Object storage dovrebbe afferire ad un’altra region).

Immagine 5

Immagine 6

Concluso il wizard, sempre dalla console di VBR possiamo collegarci alla console al server VBGP (immagine 7) per iniziare a creare policy di protezione.

Immagine 7

Dopo aver inserito le credenziali di accesso (immagine 8)

Immagine 8

è possibile monitorare l’ambiente attraverso un overview delle istanze presenti, di quelle protette (immagine 9 & 10)

Immagine 9

Immagine 10

Gestire le politiche di protezione attraverso:

La creazione delle policy di Backup, indicando nome (immagine 12), selezionando il progetto (immagine 13), la region (immagine 14), le risorse (immagine 15), il target di Backup (immagine 16), la schedulazione e la tipologia di backup (immagini da 17 a 19)

Immagine 11

Immagine 12

Immagine 13

Immagine 14

Immagine 15

Immagine 16

Immagine 17

Immagine 18

Immagine 19

Le ultime due voci indicano la stima dei costi mensili per realizzare la policy di backup (immagine 20) e l’impostazione dei retry e delle notifiche (immagine 21)

Immagine 20

Immagine 21

Terminata la configurazione e dal monitoraggio verificato che la policy si è completata con successo, è possible procedere al ripristino (immagine 22).

Immagine 22

Le opzioni disponibili sono:

  • Intera Istanza
  • File e Cartelle

Le prossime immagini  (23-24-25) mostrano i passaggi chiave per ripristinare l’ìntera istanza.

Immagine 23

Immagine 24

Immagine 25

Nel prossimo articolo vedremo come poter proteggere e rispristinare un DB Sql presente in un’istanza GCP

A presto

Veeam Backup & Replication: Conteggio delle licenze

A partire dal 1 luglio 2022, la vendita di licenze perpetue per socket di Veeam Backup & Replication™, Veeam Availability Suite™, Veeam Backup Essentials™ e Veeam ONE™ cesserà sia ai clienti nuovi che a quelli esistenti.

I prodotti attualmente in esercizio, continueranno a funzionare ma non sarà possibile acquistare nuove licenze a Socket per effettuare un upgrade.

Le licenze acquistabili e disponibili sono le Veeam Universal License (VUL) che utilizzano come unità di misura il singolo workload.

I vantaggi più importanti del modello VUL possono essere riassunti in:

  1. Possibilità di proteggere qualsiasi workload supportato (ad esempio le istanze in AWS, Azure e GCP) e non solo le Virtual Machine VMware e Hyper-V.
  2. Libertà di muovere le licenze a seconda della necessità tra tutti i workload supportati.

Nota 1: Ogni istanza può essere utilizzata per proteggere 500 GB dati sorgente di un NAS

Nota 2: Facciamo un esempio per semplificare il conteggio: ipotizziamo di dover proteggere un ambiente composto da 50 VM Hyper-V, 30 istanze in Azure (oppure in Aws oppure in GCP), 10 server fisici e 5 TB di dati.

Il numero totale di istanze è la somma algebrica di:

a. 50 (VM-HV) + 30 (Azure) + 10 (Server) + 10 (NAS)=  100 istanze = 10 VUL

Se in un processo di ammodernamento 20 VM in Hyper-V sono migrate in Azure, il conteggio si trasforma in

b. 30+50+10+10 = 100 istanze = 10 VUL

Come potete osservare il numero totale di istanze non cambia.

La buona notizia è che Veeam ha messo a disposizione un piano per aiutare i clienti nella fase di migrazione delle licenze.

Il vostro referente commerciale in Veeam potrà indicarvi le migliori opzioni disponibili.

Nota 3: In questo scenario è indispensabile fornire al referente Veeam i file di log.

Quello che descrive le licenze utilizzate è denominato VMC.log

A presto