Articoli

Pubblicato il

NAS Backup – GFS to TAPE – Part II

In the previous article, we saw how to operate on backup jobs to obtain Fulls that can be used to create a GFS retention policy when the destination of the jobs is a tape.

In this second article, we find out how a similar result can be achieved by copying tapes.

Note1: A second tape library must be present in the DataCenter to pursue this protection process.

Note2: The most common use case for Copy-Tape is to migrate data contained on tapes from an old technology (LT06) to a new one (LTO9), since the new technology would not be able to natively read the data contained on the old tapes.

There are two steps that will enable us to achieve our goal:

  • Step 1: Creation of a tape pool afferent to the second library.
  • Step 2: Tape copy job.

Stage 1

The creation of the Media Pool (image 1), will need to be customized by setting:

    • The use of a new tape for each copy session (image 2).
    • Setting a retention that for that tape group coincides with that required by the GFS policy (image 3).

Picture 1

picture 2

Picture 3

Note3: A 4-week retention was set in Image 3, which addresses the need to keep the full weekly for 1 month.

Note4: Image 4 highlights the possibility of implementing a Vault policy for tape storage.

Picture 4

PHASE 2

From the VBR GUI by selecting the tape to be copied with the right mouse button (image 5), the copy command can be initiated.

Picture 5

The simple next steps shown by images 6,7,8 and 9 show how to complete the copying operation.

Picture 6

Picture 7

Image 8

Image 9

Latest notes:

  • Documentation to refer to in order to know how many resources it is essential to allocate to the various components is available at the following link.
  • Automation of copying can be done through scripts in powershell.
  • Copy to Tape does not consume capacitive licensing but refer to the following link, Capacity Licensing item to know all the details.
Pubblicato il

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.

Pubblicato il

Veeam Backup for Salesforce – OS update

My lab has an Ubuntu 22.04.4 LTS server on which Veeam’s Salesforce environment protection software (Veeam Backup for Salesforce) is installed.

During the monthly operation of updating the operating system, some errors appeared that did not allow me to complete the operation.

The ‘output of the “sudo apt update” command, showed three errors highlighted in image 1 with the blue, green, and red arrows.

Picture 1

1. The first, (blue arrow) indicated that the digital signature linked to the Veeam repository (“https://repository.veeam.com/apt stable/amd64/ In Release”) was no longer valid.

2. The second (green arrow) indicated that the digital signature had also expired for the Ubuntu-security site (“http://security.ubuntu.com/ubuntu bionic-security InRelease”).

3. The third error (actually a warning, red arrow), indicated that the key management methodology named“apt-key” is deprecated recommending the ‘use of a more secure method named “trusted.gpg.d”.

—

Browsing the Internet, I found the solutions that met my needs:

1. The KB2654 on the Veeam website shows how to import a new key. The only real caution is to run the command as the root user (see image 2).

picture 2

2. As shown in ‘image 3, simply request a key update by entering the required identifier at the end of the command in the output of image 1 (green arrow).

image 3

Note 1: apt-key is a comado used to manage a gpg key fob for secure apt. The keychain is stored in the file ‘/etc/apt/trusted.gpg’ (not to be confused with the related but not very interesting /etc/apt/trustdb.gpg). The command apt-key can display the keys in the keyring and add or remove keys.

3. The last line of image 4 shows the command that addresses the security warning. It involves copying the keychain (trusted.gpg) inside the trusted.gpg.d folder.

Picture 4

In the article“Handeling the apt-key deprecation” you will find all the details that illustrate the security benefits of the new approach.

Note 2: Veeam Backup for Salesforce has its own mechanism for checking for new product versions and updates.

The same mechanism later allows the necessary software packages to be downloaded and installed.

I remember that these are product updates, not operating system updates.

Pubblicato il

Veeam Backup for Salesforce – OS update

My lab has an Ubuntu 22.04.4 LTS server on which Veeam’s Salesforce environment protection software (Veeam Backup for Salesforce) is installed.

During the monthly operation of updating the operating system, some errors appeared that did not allow me to complete the operation.

The ‘output of the “sudo apt update” command, showed three errors highlighted in image 1 with the blue, green, and red arrows.

Picture 1

1. The first, (blue arrow) indicated that the digital signature linked to the Veeam repository (“https://repository.veeam.com/apt stable/amd64/ In Release”) was no longer valid.

2. The second (green arrow) indicated that the digital signature had also expired for the Ubuntu-security site (“http://security.ubuntu.com/ubuntu bionic-security InRelease”).

3. The third error (actually a warning, red arrow), indicated that the key management methodology named“apt-key” is deprecated recommending the ‘use of a more secure method named “trusted.gpg.d”.

—

Browsing the Internet, I found the solutions that met my needs:

1. The KB2654 on the Veeam website shows how to import a new key. The only real caution is to run the command as the root user (see image 2).

picture 2

2. As shown in ‘image 3, simply request a key update by entering the required identifier at the end of the command in the output of image 1 (green arrow).

image 3

Note 1: apt-key is a comado used to manage a gpg key fob for secure apt. The keychain is stored in the file ‘/etc/apt/trusted.gpg’ (not to be confused with the related but not very interesting /etc/apt/trustdb.gpg). The command apt-key can display the keys in the keyring and add or remove keys.

3. The last line of image 4 shows the command that addresses the security warning. It involves copying the keychain (trusted.gpg) inside the trusted.gpg.d folder.

Picture 4

In the article“Handeling the apt-key deprecation” you will find all the details that illustrate the security benefits of the new approach.

Note 2: Veeam Backup for Salesforce has its own mechanism for checking for new product versions and updates.

The same mechanism later allows the necessary software packages to be downloaded and installed.

I remember that these are product updates, not operating system updates.

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

NAS backup – GFS to Tape – Part I

Many customers and partners ask whether it is possible to implement a GFS (Grandfather – Father – Son) type of protection policy when the data to be protected pertains to a NAS (Network network-attached storage) and the destination is a tape library.

Such automation with the current version of Veeam Backup & Replication(VBR) 12.1 is not yet available, something that is already possible when the data source is a backup of VMs and Physical Servers.

In this first article, I will help you achieve that goal by taking advantage of VBR ‘s great flexibility in creating backup jobs.

Note1: In the next one I will illustrate how to make GFS copies by exploiting a little-known feature of
VBR
, the Tape Copy.

Flexibility of Backup Jobs:

a. VBR manages tapes using an architecture that is based on:

  • Media Pool(MP) are the logical containers of the tapes and can pertain to one or more Backup jobs (in our scenario we will create one MP per Job).
  • Media Set(MS) identifies the restore points present on the tape (in our scenario we will create one MS per Backup job per single tape).

b. The proposed solution is to create weekly, monthly, and annual backup jobs in full mode. These backups should be created on a specific date and the backups should reside on tape pools created for the purpose.

Let’s see step by step how to proceed:

c. Creation of weekly and monthly Media Pools(MP).

Picture 1

From image 2 it is important to note that a new tape will be used for each backup session.

picture 2

Image 3 shows how to set the retention, which in this scenario is 4 weeks.

Picture 3

For the Monthly MP, the same procedure is used, changing the retention to 12 months (see images 4,5,6).

Picture 4

Picture 5

Image 6 shows that the retention for Full Months is 12 months.

Picture 6

d. Creating Backup Jobs

Picture 7

image 8

Image 9 highlights the scheduling of the Backup job.

The assumption is to make n full backup jobs for each GFS policy.

Our example scenario shows the first week’s job (blue arrow) with weekly retention (green arrow). For the second, third, and subsequent week, we will proceed in a completely similar way, replacing the value first with second, third, etc. under “Run the full backup automatically.”

Image 9

Image 10 highlights (orange arrow) that no incremental backups will be initiated.

image 10

The same steps must be implemented to create monthly type GFS backups, in the example I set the backup job start on the 4th Saturday of the month (image 12 – blue arrow).

Image 11

Image 12

Image 13

Note 2:

  • Licensing counts licenses per individual Backup job (verision 12.1).
  • Conduct tests to make sure the scenario matches your needs. Get help from Veeam support.

In the next article, we will see how to use the Tape Copy feature.