Tag: VBR

Pubblicato il

5 Scenari di ripristino del Backup Server

Immaginate un disastro, in cui l’infrastruttura virtuale deve essere ripristinata da zero.

È tutto perso, tranne i file di backup, che sono ancora disponibili su almeno un repository, meglio se immutabile, on-premises o in cloud.

Per ripristinare l’ambiente avete a disposizione cinque differenti opzioni che sono in funzione da come è stata disegnata e implementata l’architettura di protezione e resilenza Veeam Backup & Replication.

Nota 1: Veeam Backup & Replication verrà d’ora in avanti indicato con l’acronimo VBR.

Scenario A (Ripristino da zero):

  • Non avete effettuato il backup application aware del server VBR.
  • Non avete effettuato la Replica application aware del server VBR.
  • Non è disponibile l’export della configurazione del DB del server VBR.
  • Volete ripristinare immediatamente i workload di produzione.

Cosa fare?

Passaggio 1A: Installare Veeam Backup & Replication.

Come: Dal sito web di Veeam  (https://www.veeam.com) scaricate l’ultima versione di VBR.

(link diretto -> https://www.veeam.com/products/data-platform-trial-download.html?tab=cloud-plugins).

Immagine 1

Nota 2: VBR è in grado di leggere file di Backup creati con versioni precedenti.

La semplicità nell’installare Veeam Backup & Replication rende l’operazione semplice,  veloce e può essere realizzata in modalità unattended.

(https://helpcenter.veeam.com/docs/backup/vsphere/silent_mode.html?zoom_highlight=Unattended&ver=120)

In questo passaggio è spesso sufficiente cliccare solo su “next” per completare l’operazione.

Nota 3: si consiglia di utilizzare il proprio file di licenza (può essere scaricato da my.veeam.com) anche se la Community Edition (senza licenza) è spesso sufficiente per la maggior parte ripristini necessari in questa fase. 

Passaggio 2A: Aggiungere l’infrastruttura virtuale di produzione ove si voglia ripristinare i carichi di lavoro protetti da VBR.

Come: dopo aver completato il primo passaggio, dalla console di VBR aggiungete l’infrastruttura virtuale (Menù: “Inventory” -> “Vmware vSphere“-> “Add Server”) (Immagine 2).

Immagine 2

I passaggi seguenti dipendono dalla tipologia di Hypervisor (VMware vSphere, Microsoft Hyper-V, Nutanix AHV, …) ma risultano sempre molto semplici.

Passaggio 3A (opzionale): Aggiungere i proxy di backup.

Anche se stiamo operando a livello di ripristino, è sempre una buona idea per migliorare le prestazioni di aggiungere proxy di backup. 

Passaggio 4A: Aggiunta dei repository di backup Veeam.

L’ultima fase propedeutica prima di avviare i ripristini è quella di aggiungere i repository con i dati di backup.

Come: dalla console selezionare la voce “Backup Infrastructure”, “Backup Repository” e quindi “Add Repository” (immagine 3).

Immagine 3

Passaggio 5A: Avvio dei ripristini.

Come: dalla console di VBR selezionare dalla voce “Home”, “Backup”, “Disk imported”, la VM che si vuole ripristinare e cliccando con il tasto destro del mouse avviare il processo di ripristino (Immagine 4).

Immagine 4

Nota 4: Il ripristino può essere istantaneo. Con questa modalità le VMs sono avviate direttamente dal repository di backup. In questa opzione il repository funge da archivio dati (per VMware il DataStore) per l’ambiente virtuale.

(L’instant VM recovery è stato inventato da Veeam più di dieci anni fa e da allora ne ha migliorato performance e flessibilità).

Ora la vostra architettura di produzione è tornata operativa!

https://www.veeam.com/blog/restoring-infrastructure-from-scratch-with-veeam.html

Scenario B: Il VBR è un server virtuale.

  • Avete effettuato il backup application aware del server VBR.
  • Non avete effettuato la Replica application aware del server VBR.
  • Non è disponibile l’export della configurazione del DB del server VBR.
  • Volete ripristinare immediatamente il server VBR.

Cosa fare?

Passaggio 1B: Effettuare il download dell’utility ”Veeam.Backup.Extractor.exe” dal sito Download di Veeam.

(https://www.veeam.com/products/data-platform-trial-download.html?tab=extensions).

Immagine 5

Nota 5: Esiste anche l’opzione di Extract da linea di comando per piattaforme Windows e Linux.

 Passaggio 2B: Avviare l’Extract, selezionare il backup del VBR e una volta creati i file della VM-VBR copiateli nel Datastore VMware che preferite.

Ora dal vCenter registrate la VM appena copiata.

(Immagine 6)

Nota 6: E’ disponibile l’opzione di extract da linea di comando per piattaforme Windows e Linux.

Nota 7: E’ possibile automatizzare e semplificare la copia verso il Datastore VMware pubblicando una share di rete NFS come indicato nel seguente articolo:

https://www.virtualtothecore.com/veeam-extract-utility-quick-restores-without-veeam-server

Passaggio 3B: Una volta completato il ripristino del passaggio 2B, avviare il VBR e realizzare le operazioni standard di utilizzo (vedi passaggio 5A).

Scenario C: Il VBR è un server fisico

  • Avete effettuato il backup application aware di VBR creando il recovery media.
  • Non è disponibile l’export del file di configurazione di (VBR).
  • Volete ripristinare immediatamente il server VBR. 

Cosa fare?

Passaggio 1C: Rendete disponibile al Server fisico VBR il recovery media (via Rete o via USB).

Passaggio 2C: Avviare l’operazione di Bare Metal Recovery selezionando in fase di ripristino il backup necessario (immagine 7 e immagine 8).

Immagine 7

Immagine 8

(https://helpcenter.veeam.com/docs/agentforwindows/userguide/howto_baremetal_recovery.html?ver=60)

Passaggio 3C: Una volta completato il ripristino del passaggio 2C, avviare il VBR e realizzare le operazioni standard di ripristino come indicato nel passaggio 5A.

Scenario D: Il VBR è una VM replicata.

  • Non avete effettuato il backup application aware del server VBR.
  • Avete effettuato la Replica application aware del server VBR.
  • Non è disponibile l’export della configurazione del DB del server VBR.
  • Volete ripristinare immediatamente il server VBR. 

Cosa fare?

Passaggio 1D: Connettersi al vCenter e ricercare il VBR già replicato.

Immagine 9

Passaggio 2D: Innescare il failover del VBR.

Immagine 10

Passaggio 3D: Realizzare le operazioni di gestione di VBR come da punto 5A.

Scenario E: La configurazione del VBR.

  • Non avete effettuato il backup del server VBR.
  • Non avete effettuato la Replica del server VBR.
  • E’ disponibile l’export della configurazione del DB del server VBR.
  • Volete ripristinare immediatamente il server VBR.

Cosa fare? 

Passaggio 1E: Installare VBR sul server (fisico o virtuale, vedi punto 1A).

Passaggio 2D: Effettuare il ripristino della configurazione del VBR come indicato nella guida.

(https://helpcenter.veeam.com/docs/backup/vsphere/vbr_config_restore.html?zoom_highlight=configuration+restore&ver=120)

Immagine 11

Passaggio 3D: Realizzare le operazioni di gestione di VBR come da punto 5A.

Nota 8: E’ sempre buona norma salvare la configurazione del server di Backup.

Nota Finale:  Il consiglio è di adoperarsi al fine di poter utilizzare tutte le strategie descritte in questo articolo in modo che se una non fosse disponibile, si possa utilizzarne una seconda.

Pubblicato il

NAS Backup – GFS to TAPE – Parte II

Nel precedente articolo abbiamo visto come operare sui job di backup per ottenere dei Full che possano essere utilizzati per creare una politica di retention GFS quando la destinazione dei job è un nastro.

In questo secondo articolo, scopriamo come sia possibile ottenere un risultato simile copiando i nastri.

Nota1: Per perseguire questa processo di protezione  è necessario che nel DataCenter sia presente una seconda libreria a nastro.

Nota2: Il caso d’uso più comune per il Copy-Tape è quello di migrare i dati contenuti sui nastri di una vecchia tecnologia (LT06) verso una nuova (LTO9), visto che la nuova tecnologia non sarebbe in grado di leggere nativamente i dati contenuti sui vecchi nastri.

Le fasi che ci permetteranno di raggiungere il nostro scopo sono due:

  • Fase 1: creazione di un pool di nastri afferente alla seconda libreria.
  • Fase 2: job di copia del tape.

Fase 1

La creazione del Media Pool (immagine 1), dovrà essere personalizzato impostando:

    • L’utilizzo di un nuovo nastro per ogni sessione di copia (immagine 2).
    • Impostazione di una retention che per quel gruppo di nastri coincida con quella richiesta dalla politica GFS (immagine 3).

Immagine 1

Immagine 2

Immagine 3

Nota3: Nell’immagine 3 è stata impostata una retention di 4 settimane che risponde alla necessità di tenere il full settimanale per 1 mese.

Nota4: L’immagine 4 evidenzia la possibilità di realizzare una politica di  Vault per l’archiviazione dei nastri.

Immagine 4

FASE 2

Dall’interfaccia grafica di VBR selezionando con il tastro destro del mouse il nastro da copiare (immagine 5) è possibile avviare il comando di copia.

Immagine 5

I semplici passaggi successivi mostrati dalle  immagini 6,7,8 e 9 mostrano come completare l’operazione di copia.

Immagine 6

Immagine 7

Immagine 8

Immagine 9

Ultime note: 

  • La documentazione alla quale fare riferimento per conoscere quante risorse è indispensabile assegnare ai vari componenti è disponibile al seguente link.
  • L’automazione della copia può avvenire tramite script in powershell.
  • Il Copy to Tape non consuma license capacitive ma fate riferimentoal seguente link,  voce Capacity Licensing per conoscerne tutti i dettagli.
Pubblicato il

NAS backup – GFS su Tape – Parte I

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.

Pubblicato il

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”
Pubblicato il

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

Pubblicato il

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