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

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.

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.