Articoli

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

Enterprise Manager – Delegation of Restores

An article devoted to how you can delegate restores with Veeam Backup & Replication (VBR).

The case study is related to the protection of files in shared folders, but can be extended to many of the objects protected with VBR. (see image 7)

—

  1. Image 1 shows the three shared network folders (SHARE-A, SHARE-B, SHARE-C) that are used as the source of the files to be protected.

share-sourcePicture 1

In the scenario, it is assumed that for each individual shared folder, only a specific user can proceed with the recovery tasks.

  1. Image 2 highlights the creation of three Domain users, ShareA, ShareB, ShareC.

users-ADpicture 2

Files pertaining to a specific shared folder will be restorable by the user with the identical ending letter in the name. For example, files pertaining to SHARE-A will be restorable by the ShareA user.

(
Editor’s note: For simplicity of exposition, the letter X will replace one of the three letters of the alphabet A-B-C)

  1. A Backup job named “BkF-Share-X” was created for each shared folder.

Image 3 shows that the “BKF-Share-A” job (orange arrow) protects the entire SHARE-A (Blue arrow).

Picture 3

  1. Image 4 highlights the “configuration” menu from the Enterprise Manager.

Administration credentials are required at this configuration stage.

Picture 4

  1. From the submenu
    role
     (image 5 – orange arrow) the three previously created users (ShareX) are added (green arrow) and assigned the role of Restore Operator (blue arrow).

rolePicture 5

  1. Image 6 shows the delegation options.

The ShareA user (green arrow) is assigned the ability to restore all VBR-protected objects via the “Choose” button (orange arrow); in the restore options, only in-place restoration can be allowed (blue arrow).

The next images (7-8) show how to make the choice of objects to be displayed during the restoration delegation operations.

role-1Picture 6

scopeimage 7

role-2Image 8

  1. Image 9 illustrates and confirms that when logged in from the Enterprise Manager with ShareX user credentials (Blue arrow), only files in the corresponding shared folder (orange arrow) are visible and restorable.

ProxyImage 9

Final Note:

Pubblicato il

Enterprise Manager – Delegation of Restores

An article devoted to how you can delegate restores with Veeam Backup & Replication (VBR).

The case study is related to the protection of files in shared folders, but can be extended to many of the objects protected with VBR. (see image 7)

—

  1. Image 1 shows the three shared network folders (SHARE-A, SHARE-B, SHARE-C) that are used as the source of the files to be protected.

share-sourcePicture 1

In the scenario, it is assumed that for each individual shared folder, only a specific user can proceed with the recovery tasks.

  1. Image 2 highlights the creation of three Domain users, ShareA, ShareB, ShareC.

users-ADpicture 2

Files pertaining to a specific shared folder will be restorable by the user with the identical ending letter in the name. For example, files pertaining to SHARE-A will be restorable by the ShareA user.

(
Editor’s note: For simplicity of exposition, the letter X will replace one of the three letters of the alphabet A-B-C)

  1. A Backup job named “BkF-Share-X” was created for each shared folder.

Image 3 shows that the “BKF-Share-A” job (orange arrow) protects the entire SHARE-A (Blue arrow).

Picture 3

  1. Image 4 highlights the “configuration” menu from the Enterprise Manager.

Administration credentials are required at this configuration stage.

Picture 4

  1. From the submenu
    role
     (image 5 – orange arrow) the three previously created users (ShareX) are added (green arrow) and assigned the role of Restore Operator (blue arrow).

rolePicture 5

  1. Image 6 shows the delegation options.

The ShareA user (green arrow) is assigned the ability to restore all VBR-protected objects via the “Choose” button (orange arrow); in the restore options, only in-place restoration can be allowed (blue arrow).

The next images (7-8) show how to make the choice of objects to be displayed during the restoration delegation operations.

role-1Picture 6

scopeimage 7

role-2Image 8

  1. Image 9 illustrates and confirms that when logged in from the Enterprise Manager with ShareX user credentials (Blue arrow), only files in the corresponding shared folder (orange arrow) are visible and restorable.

ProxyImage 9

Final Note:

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

XFS – Resize the immutable file system

In the Veeam Backup & Replication environment, it may be necessary to expand the allocated space of a Linux repository.

In my environment, there is an Ubuntu 22.04 server to which a second disk(dev/sdb) was added, formatted as xfs, and made available as mount point /mnt/backup/ .

The server is used in hardened repository mode (immutability)
(https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository.html?ver=120).

Let’s look at the simple procedure:

  • The packages to install are cloud-guest-utils and gdisk:
    “sudo apt -y install cloud-guest-utils gdisk”
  • To find out the structure of the file system use the command:
    “sudo lsblk”

      • The result shows the sizing, and mount point of Ubuntu server file system:
        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
  • To find out if the file system has additional space to allocate:
    “sudo growpart /dev/sdb 1”

    • The result shows the item changed
      CHANGED: partition=1 start=2048 old: size=167770079 end=167772126 new: size=209713119 end=209715166
  • The final command that widens the file system is: sudo “xfs_growfs /mnt/backup/”
  • Check the result through the command already seen: “sudo lsblk”