quando un Server VBR è troppo grosso?

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

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

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

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 😊

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.