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.

Veeam Backup for Salesforce – OS update

Nel mio laboratorio è presente un  server Ubuntu 22.04.4 LTS, sul quale è installato il software Veeam di protezione degli ambienti Salesforce (Veeam Backup for Salesforce).

Durante l’operazione mensile di  aggiornamento del sistema operativo, sono apparsi alcuni errori che non mi hanno permesso il completamento dell’operazione.

L’ output del comando “sudo apt update”,  mostrava tre errori evidenziati nell’immagine 1 con le frecce di colore blue, verde e rosso.

Immagine 1

1. Il primo, (freccia blue) indicava che la firma digitale legata al repository Veeam (“https://repository.veeam.com/apt stable/amd64/ In Release”) non fosse più valida.

2. Il secondo (freccia verde) indicava che anche per il sito Ubuntu-security (“http://security.ubuntu.com/ubuntu bionic-security InRelease”) la firma digitale fosse scaduta.

3. Il terzo errore (nella realtà un warning, freccia rossa), indicava che la metodologia di gestione delle chiavi denominata “apt-key” è deprecata consigliando l’ utilizzo di un metodo  più sicuro denominato “trusted.gpg.d”.

Navigando su internet ho trovato le soluzioni che hanno risposto alle mie necessità:

1. Sul sito Veeam è presente la KB2654 che indica come importare una nuova chiave. L’unica vera attenzione è avviare il comando da utente root (vedi immagine 2).

Immagine 2

2. Come mostrato nell’ immagine 3, è sufficiente richiedere l’aggiornamento della chiave inserendo a fine comando l’identificativo richiesto nell’output dell’immagine 1 (freccia verde).

immagine 3

Nota 1: apt-key è un comado utilizzato per gestire un portachiavi di chiavi gpg per apt sicuro. Il portachiavi è conservato nel file ‘/etc/apt/trusted.gpg’ (da non confondere con il correlato ma non molto interessante /etc/apt/trustdb.gpg). Il comando apt-key può essere utilizzato per mostrare le chiavi nel portachiavi e per aggiungere o rimuovere le chiavi.

3. Nell’ultima riga dell’immagine 4 viene indicato il comando che indirizza il warning di sicurezza. Si tratta di copiare il portachiavi (trusted.gpg) all’interno della cartella trusted.gpg.d.

Immagine 4

Nell’articolo “Handeling the apt-key deprecation” trovete tutti i dettagli che illustrano i vantaggi in ambito di sicurezza del nuovo approccio.

Nota 2: Veeam Backup for Salesforce ha un proprio meccanismo  che consente di verificare la presenza di nuove versioni di prodotto e aggiornamenti.

Lo stesso meccanismo consente successivamente di scaricare e  installare i pacchetti software necessari.

Ricordo che sono aggiornamenti di prodotto, non di sistema operativo.

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:

MySQL Backup & Veeam Backup & Replication Parte 2

In questo secondo articolo è illustrato dove ricercare gli script per realizzare backup consistenti di DataBase MySQL con Veeam Backup & Replication.

Per scoprire perché sia necessario utilizzare script, vi raccomando di leggere il precedente articolo.

Hot Backup Database Online Dump (Linux)

L’opzione prevede di integrare negli script il comando mysqldump.

Due esempi sono consultabili al seguente sito:

HotBackup Database Freeze (Linux)

L’opzione prevede di effettuare a caldo il flush delle tabelle.

Due esempi sono consultabili al seguente sito:

Cold Backup Database Shutdown (Linux)

L’opzione prevede di fermare il servizion MySQL prima di realizzare il backup.

Due esempi sono consultabili al seguente sito:

Hot Backup Database Online Dump (Windows)

Il seguente esempio in poweshell è puramente dimostrativo. Il mio consiglio è quello di chiedere al vostro esperto in powershell di crearne uno che rispetti le politiche aziendali di gestione e sicurezza.

Pre command (avvia lo script mySQLdump.ps1 sul server YOURMYSQLSERVER)

$password = ConvertTo-SecureString “YOURPWD” -AsPlainText -Force

$Cred = New-Object System.Management.Automation.PSCredential (“DOMAIN\USER”, $password)

New-PSSession -ComputerName mySQL-WIN -Credential $Cred

#Enter-PSSession -ComputerName YOURMYSQLSERVER

#Invoke-Command -Session 6 -FilePath “C:\Script\script-7.ps1” -ComputerName mySQL-WIN

Invoke-Command -ComputerName mySQL-WIN -Credential $Cred -ScriptBlock { C:\Script\mySQLdump.ps1}

mySQLdump.ps1 (Crea il file .sql che viene memorizzato in una specifica cartella sul server YOURMYSQLSERVER)

# Declare variables

$path = “/backups”                      # path of backup folder

$logFile = “automate-mysqldump.log”     # path of log file

$configFile = “C:\ProgramData\MySQL\MySQL Server 5.6\my.ini”           # path of my.cnf file

# Navigate to the backups folder

Set-Location $path

# get today’s date to name today backup folder

$date = Get-Date -UFormat “%Y-%m-%d”

# Check for log file

# Create if not found

if (-NOT (Test-Path $logFile)) {

    New-Item -Path . -Name $logFile -ItemType “file”

    Add-Content $logFile “Created on: $date`n”

}

# enter directory

# create today’s backup directory if it does not exist

if (-NOT (Test-Path $date)) {

    New-Item -ItemType “directory” $date

    Add-Content $logFile “[$date]: New $date directory is created”

}

# Set-Location $date

Add-Content $logFile “[$date]: Starting mysqldump”

# invoke mysqldump – insert mysqldump statement

mysqldump –defaults-file=$configFile -r $date/database-backup.sql –all-databases

Add-Content $logFile “[$date]: Backup for databases are completed”

Add-Content $logFile “”

# pause

 Post command (chiude la sessione remota)

Remove-PSSession -ComputerName YOURMYSQLSERVER

Nel prossimo articolo sarà illustrato come integrare gli script in Veeam Backup & Replication.

MySQL Backup e Veeam Backup & Replication – Parte 1

Il presente articolo illustrerà come implementare una strategia di protezione dei dati in ambienti MySQL.

Partiamo da una considerazione.

Per realizzare backup consistenti da un punto di vista applicativo, è necessario che prima che sia avviato  il processo di copia, l’applicazione abbia scritto su disco tutti i dati in memoria (flush).

Ad esempio, le applicazioni Microsoft® utilizzano una tecnologia denominata Shadow Copy che attraverso il coordinamento di driver VSS realizza la consistenza applicativa.

Una tecnologia simile non è disponibile su Linux ed in più MySQL non la supporta in ambiente Microsoft®.

Come ovviare?

Attraverso la creazione di script che automatizzino la consistenza applicativa prima di avviare la creazione della Snapshot.

Compreso questo aspetto, torniamo all’ambito dell’articolo, introducendo le opzioni disponibili per MySQL.

Nota 1: La consistenza applicativa avviene prima della creazione della snapshot.

  • 1. Backup Logico: Lo script crea un file con l’estensione .sql che in caso di ripristino permette la ricreazione del database e dei suoi dati.

Il file .sql è creato attraverso il comando nativo MySQL “mysqldump”.

I vantaggi del backup logico possono essere riassunti in:

  • Non vi sono dipendenze con software di terze parti.
  • I backup possono essere ripristinati su altri server.
  • 2. Backup Fisico/Cold: Sono create copie a freddo dei file del DB (ad esempio: ibdata, .ibd, .frm, ib_logfile, my.cnf).

Per essere certi che i backup siano realizzati in modalità “consistenza applicativa“, prima di effettuare la snapshot, è      indispensabile fermare i servizi MySQL.

E’ una strategia di backup di norma implementata in ambienti che non richiedano operatività 24×7.

Nota 2: Il servizio viene fermato solo per il tempo necessario alla creazione della snapshot e non per l’intera durata del backup.

  • 3. Backup Fisico/Hot: Se è in esecuzione il motore InnoDB, lo script permette la realizzazione di copie consistenti senza fermare i servizi (utilizzando ad esempio il comando mysqlbackup componente della suite Enterprise di MySQL (MySQL Product)).

Ora che conosciamo le opzioni di scripting disponibili, vediamo come le soluzioni Veeam possano integrarsi nativamente con gli  ambienti MySQL.

La prima opzione disponibile è il Veeam Agent for Linux (VAL) che automatizza le seguenti quattro fasi:

  1. Flush dei dati dalla memoria al disco (consistenza applicativa).
  2. Creazione della snasphot.
  3. Rilascio delle tabelle.
  4. Avvio del processo di Backup.

Nota 3: Come indicato nella prima parte dell’articolo, se il DB è del tipo MyISAM è possibile effettuare il backup con il blocco di tutte le tabelle.

I pre-requisti del VAL sono:

  • Versione di MySQL maggiore o uguale alla 5.8.
  • Sistema operativo sia Linux.

Domanda: E’ possibile effettuare il backup in ambienti Windows e dove la versione di MySQL è inferiore alla versione 5.8?

La risposta è si e gli scenari disponibili sono:

Backup Logico -> Hot-Backup Database Online Dump -> Comando mysqldump.

Backup Fisico/Cold -> Cold-Backup Database Shutdown -> Fermo temporaneo dei Servizi.

Backup Fisico/Hot -> Hot-Backup Database Freeze -> Comandi nativi mysql.

Nota4: Esiste anche la possibilità di effettuare Backup Parziali. In questo scenario si effettua il backup di specifiche tabelle e database. E’ utile quando si devono realizzare strategie di protezione differenti sullo stesso Server.

Nel prossimo articolo scopriremo come creare gli script e come integrarli in Veeam Backup & Replication.

Veeam & Google Cloud Platform – Parte 2

Nel precedente articolo, è stato illustrato come utilizzare VBR (Veeam Backup & Replication) come framework per proteggere le istanze (VM) presenti nella Piattaforma Google Cloud (GCP).

Il componente integrato di VBR che automatizza i processi di backup e restore, è il VBGP (Veeam Backup for Google Platform), giunto ad oggi (gennaio 2022) alla sua seconda versione.

Il VBGP permette di salvare a livello di immagine le istanze Google, ma ad oggi non è in grado di ripristanre in modalità granulare le applicazioni.

Nota 1: Il VBGP permette di realizzare backup “Application Consistency” delle istanze attraverso:

  • le VSS (Windows Volume Snapshot Copy Services) per i sistemi operativi Microsoft-Windows.
  • Script personalizzabili per i sistemi operativi Linux.

Nei casi in cui sia richiesto il backup dei transaction log o il ripristino granulare di oggetti applicativi, è necessario utilizzare il Veeam Agent (VA).

Nota 2: Nel sito www.gable.it troverete molti articoli che dettagliano come implementare i Veeam Agent.

Nota 3: Il Backup Server VBR può essere installato sia in cloud (ad esempio come istanza in GCP) che on-premises. In tutti gli scenari è necessario garantire la corretta connettività tra i componenti.

Nota 4: La versione 12 di VBR (in uscita nel 2022) aggiungerà una serie di miglioramenti in ambito Cloud. Ad esempio la possibilità di gestire il deploy e i componenti Veeam Agent, senza dover creare a priori una VPN tra il VBR on-premises e le istanze da proteggere.

Vediamo ora le due fasi principali per realizzare il Backup dell’istanza:

La prima fase ha lo scopo di realizzare discovery e il deploy dell’Agent sull’istanza (vedi immagine 1) (menù Inventory, Create a Protection Group).

Immagine 1

Nella seconda fase, la creazione del job di Backup selezionando la voce Veeam Agent for Windows (Immagine 2)

Immagine 2

Durante il Wizard selezioniamo alla voce Backup Mode,  Entire Computer (immagine 3) e alla voce Storage il Repostitory di Backup (immagine 4).

Immagine 3

Immagine 4

Il punto focale del presente articolo è la gestione della protezione delle applicazioni (in questo scenario MS-SQL).

Dopo aver abilitato l’application aware processing (immagine 5), è possibile operare a livello di Transaction Log, selezionando se cancellarli dopo ogni operazione di Backup (Trunking) oppure ancora se effettuare il backup dei soli T-Log. (immagini 6-8).

Immagine 5

Immagine 6

Immagine 7

Immagine 8

Dopo aver avviato il job, controlliamo che alla voce Disk sia presente almeno un punto di ripristino (vedi immagine 9).

Immagine 9

Concludiamo il presente articolo illustrando le opzioni di ripristino del Veeam Agent for Windows: (immagine 10)

  • Verso architetture virtuali VMware & Hyper-V
    • Instant Recovery
    • Ripristino di Volumi
    • Esportazione dei Dischi (VMDK, VHD, VHDX)
  • Verso architetture Public Cloud
    • AWS
    • Azure
    • GCP
  • La creazione di  un Recovery Media per realizzare un Bare Metal Restore
  • Il ripristino di File e Cartelle (immagine 10, disponibile anche con il VBGP)
  • Il ripristino di oggetti applicativi (immagine 11 & 12, disponibile unicamente via VA)

Immagine 10

Immagine 11

Immagine 12

Tutte le opzioni di ripristino utilizzando il Veeam Explorer per SQL sono disponibili al seguente sito.

Nota 5: Nell’ esempio è stato scelto uno Scale Out Backup Repository che ha il vantaggio di copiare i dati verso l’Object Storage di Google (vedi immagine 13). La versione 12 di VBR permetterà la scrittura diretta verso l’Object Storage

Immagine 13

A presto