Solved

quando un Server VBR è troppo grosso?


Userlevel 6
Badge +3

ciao, vorrei raccogliere qualche opinione / riscontro sul “dimensionamento” del veeam server. Nel senso che, in contesti molti grossi (scusate il tecnicismo 😉), dove ci sono tante VM e soprattutto tantissimi Job forse sarebbe meglio avere più di una istanza di VBR… oppure no? This is the question.

In un contesto dove sto lavorando, c’è un VBR che impiega 45 minuti a fare un backup della configurazione, producendo un file da oltre 2 GByte. Sarebbe una buona idea “segmentarlo”? Che ne pensate? 

Grazie in anticipo.

P.S.: naturalmente in un contesto frazionato diventa più importante avere l’Enterprise Manager (spesso trascurato) e ONE ben configurati per meglio tenere sotto controllo il tutto.

icon

Best answer by DChiavari 18 July 2023, 16:26

View original

6 comments

Userlevel 7
Badge +8

Ciao @atinivelli 

no, in realtà è necessario scalare con aggiunta di proxy per velocizzare i backup.

Tieni presente che ogni core del proxy prende in carico un disco.

Ovviamente bisogna tenere conto anche della banda a disposizione per i backup.

Ti allego un link per il corretto dimesionamento.

Strumenti per il dimensionamento e Best Practice (veeam.com)

https://calculator.veeam.com/

Veeam Architects Support Site (veeambp.com)

per EM se hai la lic installalo sempre, è necessario ancheper il recovery della key dei backup criptati.

Invece per VONE stesso discorso se hai lic intallao sempre, è molto utile per report specifici, snapshot orfani, report di perfomance etc.

VONE è anche ottimo strumento per il troubleshootin sulla infa virtuale.

saluti

Userlevel 6
Badge +3

sì chiedo scusa se non ho esplicitato che “il dimensionamento dei proxy è un discorso a parte e supponiamo sia fatto correttamente”.

Comunque anche il dimensionamento del VBR deve essere adeguato al numero di job e di vm protette

https://bp.veeam.com/vbr/2_Design_Structures/D_Veeam_Components/D_VBR_server/backup_server.html

per cui avere tutto nello stesso significa avere una VM (se virtuale) di dimensioni molto importanti che rischiano di crescere indefinitamente. Inoltre in caso di incidente (ad es un windows update andato male), avere tutto sulla stessa significa perdere capacità di restore e backup su tutto. E il ripristino diventa più lungo.

Non per ultima la questione delle finestre di manutenzione: avere tutto in un solo VBR comporta una notevole difficoltà nel trovarle. Soprattutto se ci sono tape o copy job che girano di giorno.

Invece frazionando ad esempio i lavori diurni e notturni su due VBR differenti, penso, si possa avere un giovamento anche da questo punto di vista.

Ripeto che parlo in particolare di ambienti grandi dove ci sono molte centinaia di job

Userlevel 7
Badge +8

Nessun problema @atinivelli 

non è consigliato installare due VBR che puntano al medesimo vpshere.

Conviene a questo punto un server fisico all in one carrozzato.

Oppure installi il VBR virtuale su un vspehere dedicato separato dal vspehere di produzione.

Ovviamente se l’installazione deve gestire una considerevole quanrtità di vm da backuppare allora è scontato che la soluzione All-in-One non è adeguata.

Server con ruoli dedicati.

  • VBR application server\scheduler 
  • VBR tape server FISICO unica soluzione supportata.
  • SQL\Postgres dedicato al VBR\EM
  • Proxy
  • Repository standard
  • Repository hardened
  • Enteprise manager
  • Veaam one one

Peril restore con il backup configuration file ( se devi solo rispirtinare il VBR corrotto) è veloce.

Per il discorso del patching fai una snapshot a freddo. 

Comunque se hai job che girano giorno e notte, comunque una finstra di manutenzione la devi sempre trovare per forza metti caso che devi patchare un zero day.

saluti

 

Userlevel 6
Badge +7

Ciao, non mi preoccupano molto i 2 GB di configuration backup… mi preoccupa di più il fatto che ci metta 45 minuti. 😀 Dato che il configuration backup è di fatto poco più che un dump del database di configurazione, avete investigato le performance del database (SQL Server o PostgreSQL che sia)?

Prestazioni dei dischi dove risiede il database, eventuale frammentazione / problemi di indici, query o stored procedures che impiegano molto tempo...

Avere migliaia di oggetti (e/o job) in un singolo server VBR è sicuramente possibile, ovviamente bisogna dimensionarlo adeguatamente, come tutti avete detto - CPU, RAM, disco… e database! (se sullo stesso server).

Poi è sicuramente vero che, laddove si può ed ha senso, segmentare l’ambiente con più VBR gestiti da un unico Enterprise Manager può aiutare.

Userlevel 6
Badge +3

adesso il server verrà migrato su un altro (con SQL esterno) quindi il database si potrebbe/dovrebbe “ripulire”… si vedrà se i tempi sono ancora quelli, speriamo di no 😊

Userlevel 7
Badge +10

Arrivo in ritardo ma mi sto godendo una settimana di ferie in giro per l'Italia. Come diceva @DChiavari è importante verificare le prestazioni del dB. Soprattutto MSSql "mangia" risorse a più non posso. In ambienti "grossi" diventa fondamentale anche pianificare una finestra di nobackup che serve per le manutenzioni. Per esperienze fatte 4 ore bastano e avanzano. 

Comment