Skip to main content

ciao, io sono sempre stato molto a favore dell’uso delle tags vSphere per selezionare le VM che vengono salvate dai Job.

Quindi cerco di portare i miei clienti da quella parte.

Ne ho uno dove si è formata una corrente di pensiero che non ama questa procedura perché “si rischia di dimenticare” e vorrebbe fare dei job che catturino tutto un cluster (ad esempio)
Considerato che parliamo di una infrastruttura da centinaia/migliaia di VM la cosa non mi piace per niente. Quali argomentazioni usereste per sconsigliare questo? Io ho pensato

  • un job con centinaia di VM tutte diverse (s.o., applicativi) diventa complesso da gestire nella parte di guest processing
  • un solo job ha un solo repository
  • un job molto grande diventa complicato da gestire nelle backup copy
  • un job solo ha una sola schedulazione possibile
  • un job solo ha una sola politica di retention

altre idee? grazie!

Ciao @atinivelli, anche io cerco sempre di usare i tag di vSphere!

Condivido in buona parte i punti da te indicati, e aggiungo che solitamente preferisco raggruppare i backup job per tipologia di oggetti backuppati (AD, SQL, FS ecc..), anche perchè è strano che in una infrastruttura tutte le VM abbiano le stesse necessità di RPO e/o retention, ad esempio.

In generale, sicuramente suddividere i job ti consente di essere più flessibile su questi aspetti, e non da meno, “obbliga” il cliente ad una sorta di assessment lato hypervisor che fa sicuramente comodo anche a lui (magari andando a scovare VM di cui non ricorda il ruolo o VM da eliminare/non backuppare).

Se poi continua ad insistere sull’argomento “si rischia di dimenticare qualcosa”, è il momento buono per vendergli anche Veeam ONE ed attivare il report “Protected VMs” 😁


sì Veeam ONE l’ho già predicato. Anche perché il metodo suggerito potrebbe assicurare solo che il backup venga tentato. Ma bisogna controllare che riesca e possibilmente testare pure il restore 😉


In una infrastruttura piccola (<50 VM), forse l’utilizzo delle cartelle di VM è più immediato per il cliente, sia come visibilità che come operazioni da eseguire, di conseguenza potrebbe creare dei job per tutte le VM all’interno di una cartella.


P.S. condivido comunque il pensiero sull’utilizzo dei tag 😁


con 50 VM sì ma qui siamo sopra un ordine di grandezza, poi l’obiezione è “non voglio fare niente”, che sia tag o spostamento in cartella.

naturalmente è più una questione politica che tecnica (primo pararsi il….: non è grave se non c’è il backup, basta che non mi prendo la colpa)


Anche io in genere faccio job divisi per servizio erogato.

E varie volte ho creato un job dove metto sotto backup l’intero cluster e vado ad escludere tutte le VM che sono processate dagli altri job (o che non voglio backuppare), così se qualcuno si dimentica di “veeam” quando crea una nuova VM, viene processata da quest’ultimo job. Piuttosto di niente meglio piuttosto.

 

Ciao.

 

Stefano.


con 50 VM sì ma qui siamo sopra un ordine di grandezza, poi l’obiezione è “non voglio fare niente”, che sia tag o spostamento in cartella.

naturalmente è più una questione politica che tecnica (primo pararsi il….: non è grave se non c’è il backup, basta che non mi prendo la colpa)

Ciao Alessandro. 

Purtroppo catechizzare il cliente non è mai una cosa facile però purtroppo si rende necessario dargli evidenza di quelli che possono essere i problemi nel caso in cui tenda a non cambiare idea. 

Il detto (in Campania) “Attacca 'o ciuccio 'a 'ddò vole 'o padrone” (Lega l'asino dove vuole il padrone), troppe volte ci porta ad accontentare i clienti ma questo si ripercuote sulle normali attività operative. 

Ti posso dare la mia esperienza su un cliente con 2500 server. Abbiamo organizzato tutto per cartelle con una profondità accurata e questo ha portato ad un miglioramento nella gestione in ambito Hypervisor (prima) e in ambito backup (di conseguenza). 

la prima classificazione è stata

  • Produzione
  • Pre-produzione
  • Test

 e facendo capire al cliente che le vm che erano nelle tre cartelle potevano avere retention diverse e con un notevole risparmio in termini di spazio sul repository e quindi in termini di costi monetari. 

Al loro interno abbiamo suddiviso in varie cartelle:

  • Infrastruttura
  • Applicativi
  • Altro

e di conseguenza varie sub-folder di terzo livello a seconda dei servizi infrastrutturali e delle applicazioni. 

Ti garantisco che il cliente ha apprezzato il tutto dopo avergli dato evidenza di quanto avrebbe risparmiato. 

Bisogna colpirli nei “Sentimenti” come diceva un mio ex collega. 

E i sentimenti si traducono nel vil denaro. 

Fagli capire che risparmia soldi e vedrai come accetta i consigli. 

Ah...i job prendevano in carico le vm all’interno delle singole folder di terzo livello. E in ultimo un job del DC ad esclusione delle 3 folder principali. 

My 2 cents.


ciao, quel detto lo ripeteva sempre un mio ex capo di anni fa, e non era campano 😉

purtroppo una riorganizzazione di quel tipo è “out of scope” nel caso di cui mi sto occupando.

Anche la questione dei “sentimenti” aka risparmio non è utile: si tratta di un’organizzazione grande, quelle dove almeno per alcuni vige la regola “primo pararsi il ….”

In altre parole per chi obietta non è tanto importante se le VM hanno il backup o no, mentre è importantissimo che, nel caso succeda un problema, io non rischi di prendermi la colpa perché non ho messo il tag o la cartella giusta 😊 


In altre parole per chi obietta non è tanto importante se le VM hanno il backup o no, mentre è importantissimo che, nel caso succeda un problema, io non rischi di prendermi la colpa perché non ho messo il tag o la cartella giusta 😊 

 

Trasforma il problema in opportunità: proponigli un backup gestito, dove loro non devono fare nulla se non dirti di quali VM fare i backup, al resto ci pensate voi (con buona pace del paraculismo italico).


Ciao a tutti,

il vero problema sono i processi che sono completamente insistenti nella maggior parte delle aziende italiane.

La tecnologia fornisce automazione e strumenti per pararti.… ed evitare banali errori… mancanze\errori etc (ma bisgna investire denaro\ investire learning e dedicare tempo e analisi accurate e prevedere l’impossibile.. esagero :P)

Ma se alla base non essite un flusso di processo che tutti rispettano nulla si puo fare.

  • Se usi i tag e poi che delivera la VM Vsphere non applica il tag ..
  • Se usi le Direcotry Vsphere e chi delivera la VM  non la inserisce in nessuna Directory o la inserisce nella directory errata..
  • Se inserisci una VM senza backup application aware etc..
  • Se deployano una Vm e non ti dicono di inserirla sotto backup con le rispettive policy di retention
  • Se non hai i backup 3-2-1-1-0 poi piangi lacrime amare 

La mancanza di analisi e rispettiva messa in sicurezza del data backup o di security in generale è completamente sconoisciuta alle aziende italiane, vuoi per mancanza di budget,obsolescenza tecnologica dovuto la mancato refresh tecnologio, vuoi per ingoranza, vuoi per troppo effort, vuoi perchè tanto non gestisco la securiy…

Tendenzialemente una azioneda corre ai ripari quando gli hanno spiantoa l’infrastruttura.. corrono a chiedere soccorso chiedendoti cosa possiamo fare… 

la situazione in ita sta migliorando ma siamo ancora all’età della pietra purtroppo.

Ma su con la vita almeno qualcuno queste domande se le fa 😄

saluti 


Trasforma il problema in opportunità: proponigli un backup gestito, dove loro non devono fare nulla se non dirti di quali VM fare i backup, al resto ci pensate voi (con buona pace del paraculismo italico).

 

eh sì quando si può si fa ma qui non si riesce. Ho lavorato anche all’estero (Germania) e non pensate che lì sia diverso.
Quando mi imbatto in qualcuno che pensa in primis a difendersi non lo giudico perché non so quante volte l’abbiano fregato 😉


Comment