Tag: VBR

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

Pubblicato il

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

Pubblicato il

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

Pubblicato il

VBR – Mac Backup

Veeam Backup & Replication (VBR) version 11 has a new feature and Mac users will fall in love with it.

It is now available for the backup and restores of your MACOS files.

It supports the last Operating Systems starting from High-Sierra (Big Sur 11.X.X / Catalina 10.15.X / Mojave 10.14.X / High Sierra 10.13.6).

Note 1: The Veeam Agent for Mac (VAM) version 1 supports the M1 processor via Rosetta.

Note 2: The VAM supports consistent data backup with snapshots for the APFS file system.

In the other file systems, the backup is created via a snapshot-less approach.

Note 3: At the moment it’s possible to perform the backup of user data (with a custom scope too). The image of the entire machine and a Bare Metal Restore are not available yet.

The configuration steps are quite easy as shown in the official guide:

To recap, the procedure consists of:

  1. From the VBR console create a resource group using a flexible scope
  2. Copy the files generated from VBR to the MAC to protect
  3. Install the package to your machine and import the created configuration. (It allows the communication between VBR and the Mac)
  4. From the VBR console creating the backup policy and apply it

The following video shows how it works in a managed VBR architecture.

Take care and see you soon.