Articoli

Pubblicato il

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.

Pubblicato il

Enterprise Manager – Delega dei ripristini

Un articolo dedicato a come poter delegare i ripristini  con Veeam Backup & Replication (VBR).

Il case study è legato alla protezione di file in cartelle condivise, ma può essere esteso a molti degli oggetti protetti con VBR. (vedi immagine 7)

—

  1. Nell’immagine 1 sono illustrate le tre cartelle di rete condivise (SHARE-A, SHARE-B, SHARE-C) che sono utilizzate come sorgente dei file da proteggere.

share-sorgenteImmagine 1

Nello scenario si ipotizza che per ogni singola cartella condivisa, solo uno specifico utente possa procedere alle attività di ripristino.

  1. L’ immagine 2 evidenzia la creazione di tre utenti di Dominio, ShareA, ShareB, ShareC.

utenti-ADImmagine 2

I file afferenti ad una specifica cartella condivisa saranno ripristinabili dall’utente che ha nel nome l’identica lettera finale. Ad esempio, i file afferenti alla SHARE-A saranno ripristinabili dall’utente ShareA.

(NDR: Per semplicità espositiva la lettera X sostituirà una delle tre lettere dell’alfabeto A-B-C)

  1. Per ogni cartella condivisa è stato creato un job di Backup denominato “BkF-Share-X”

L’immagine 3 evidenzia che il job “BKF-Share-A” (freccia arancio) protegge l’intera SHARE-A (freccia Blue).

Immagine 3

  1. Nell’immagine 4 viene evidenziato il menù “configurazione” dall’ Enterprise Manager.

In questa fase di configurazione sono necessarie le credenziali amministrazione.

Immagine 4

  1. Dal sotto menù role (immagine 5 – freccia arancio) vengono aggiunti (freccia verde) i tre utenti precedentemente creati (ShareX) ai quali viene assegnato il ruolo di Restore Operator (freccia blue).

roleImmagine 5

  1. L’immagine 6 mostra le opzioni di delega.

All’ utente ShareA (freccia verde) viene assegnata la possibilità di effettuare il ripristino di tutti gli oggetti protetti da VBR attraverso il pulsante “Choose” (freccia arancio); nelle opzioni di ripristino è possibile permettere il solo ripristino in-place  (freccia blue).

Nelle immagini successive (7-8) viene indicato come effettuare la scelta degli oggetti da visualizzare durante le operazioni di delega del ripristino.

role-1Immagine 6

scopeimmagine 7

role-2Immagine 8

  1. L’immagine 9 illustra e conferma che effettuato il login dall’Enterprise Manager con le credenziali dell’utente ShareX (freccia Blue), siano visibili e ripristinabili solo i file della corrispettiva cartella condivisa (freccia arancio).

DelegaImmagine 9

Nota Finale:

Pubblicato il

VMware Broadcom – Cosa fare ?

Broadcom's Acquisition of VMware Closed: What Now?

Broadcom ha dato una grande scossa al  2024.

Dagli ultimi rumors, sembra che il licensing della appena acquisita VMware verrà pesantemente rivisto.

Uno dei primi risultati è che molti clienti si chiedono cosa sia giusto fare.

Non ho la pretesa di conoscere la risposta corretta.

Ho effettuato alcune riflessioni che mi hanno portato a pensare a quattro futuri scenari  dei quali vi parlerò nel presente articolo.

  1. Il cliente continua la collaborazione con VMware/Broadcom.
  2. Il cliente sostituisce la tecnologia Hypervisor.
  3. Il cliente migra il proprio datacenter verso un Hyperscaler o  un Service Cloud Provider Locale.
  4. Il cliente trasforma il proprio Datacenter in un  “Datacenter as a Software”.

Per ogni scenario andrò ora a descrivere i macroscopici pro e contro.

1. Credo che il desiderato di Broadcom sia quello di semplificare il più possibile il licensing al fine di avere a portfolio soluzioni snelle e semplici da proporre.

Ciò implica eliminare alcune delle soluzioni ora presenti per concentrare le  energie unicamente su quelle a maggior rilevanza d’uso e guadagno.

Ora vi domando: Le soluzioni VMware ora presenti nel vostro datacenter sono quelle strategiche anche per Broadcom?

E ancora, siamo certi che l’ottimizzazione Broadcom non toccherà il dipartimento R&D di VMware che sviluppa le soluzioni divenute ora strategiche?

E non per ultimo, quale sarà il prezzo per poter rimanere nell’ecosistema Broadcom-VMware?

2. La prima sfida è quella di fornirsi di strumenti in grado di migrare le VM da una tecnologia HyperVisor all’altra.

La seconda è quella di proteggerle.

(NDR. Meno male che Veeam Backup & Replication permette di realizzare con un solo strumento entrambe le cose 🙂 )

Aggiungo, che bisognerà essere anche fortunati nello scegliere un vendor che non sia nel mirino di una nuova Broadcom, perché finire nello stesso giro dantesco sarebbe diabolico.

Pensare ad una tecnologia open-source based?

3. Il modello degli Hyper-Scaler è quello di fornire una serie di servizi  personalizzabili.

Spesso sento qualcuno affermare che esistano dei “costi nascosti”.  Non è vero, sono tutti ben illustrati, solo che capirli preventivamente è spesso molto difficile.

Avrà quindi particolare importanza la fase di creazione del progetto di migrazione che dovrà essere particolarmente accurata al fine di non ritrovarsi brutte sorprese  a fine mese .

4. Data Center as a Software è sinonimo di un’architettura Cloud Native.

Ciò implica riscrivere applicazioni e servizi in modo tale che siano  indipendenti dal HyperVisor.

E’ il nuovo approccio che negli anni diventerà un comune standard per scrivere codice.

Nel sito troverete una serie di articoli sul mondo Container e kubernetes ai quali vi rimando.

Tante domande, una sola risposta giusta?

No, credo che la migliore strategia sia quella di ricercare il miglior bilanciamento nell’utilizzo delle diverse opzioni disponibili, per arrivare a regime con la soluzione che si adatta al meglio alle necessità della vostra azienda in un corretto bilanciamento tra costi e benefici.

Ultima nota: Non dimenticate mai di aggiungere dei piani di formazione del personale perchè il training on the job in scenari particolarmente complessi NON è mai la via migliore per rendere sicuri i vostri sistemi ovunque questi siano

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