Dimensionare Proxmox Backup Server non significa soltanto verificare che il sistema disponga della RAM minima o di dischi sufficientemente capienti. In un ambiente aziendale devi considerare la quantità di dati da proteggere, la frequenza delle modifiche, la retention, il numero di job simultanei e il tempo entro cui devi riuscire a ripristinare i servizi.
Le prestazioni di PBS dipendono dall’equilibrio tra CPU, memoria, storage e rete. Potenziare un solo componente non risolve necessariamente il problema: una CPU veloce, per esempio, non compensa un datastore con prestazioni insufficienti.
In questo articolo vedremo come raccogliere i dati necessari e trasformarli in una configurazione adeguata a un ambiente di produzione. Proxmox consiglia una CPU con almeno 4 core, 4 GiB di RAM più 1 GiB aggiuntivo per ogni TiB di storage, almeno 32 GiB di spazio su disco per il sistema operativo, unità con buone prestazioni nelle operazioni di accesso casuale e interfacce di rete ridondate multi-Gigabit. Questi valori costituiscono una base tecnica di riferimento, ma non rappresentano un dimensionamento adatto a qualsiasi infrastruttura.
Per conoscere prima le funzionalità della piattaforma puoi consultare la nostra guida a Proxmox Backup Server.
Requisiti minimi e raccomandati per Proxmox Backup Server
La documentazione ufficiale distingue i requisiti minimi per la valutazione da quelli raccomandati per un server utilizzato in produzione.
| Componente | Valutazione e test | Produzione |
| CPU | Processore x86-64 con almeno 2 core | CPU AMD o Intel moderna con almeno 4 core |
| RAM | 2 GB | Almeno 4 GiB più 1 GiB per ogni TiB di storage |
| Disco di sistema | Più di 8 GB | Almeno 32 GiB disponibili |
| Storage dei backup | Non specificato | Storage ad alte prestazioni, adatto a operazioni casuali |
| Rete | Una scheda di rete | Interfacce ridondate multi-Gigabit |
I requisiti minimi sono dichiaratamente destinati alla valutazione del software e non devono essere utilizzati come riferimento per un sistema di produzione. Proxmox raccomanda inoltre hardware server di qualità, SSD enterprise per ottenere le prestazioni migliori e una cache dedicata ai metadati quando il datastore utilizza dischi HDD.
Queste indicazioni rispondono alla domanda “il PBS può funzionare?”, ma non ancora a quella più importante “Il sistema riuscirà a completare backup, verifiche e restore entro i tempi richiesti dall’azienda?”
Per rispondere è necessario analizzare separatamente ogni componente.
Quanti core servono a Proxmox Backup Server
I quattro core indicati da Proxmox rappresentano un punto di partenza. Il numero effettivamente necessario dipende soprattutto dal carico e dalla quantità di attività eseguite contemporaneamente.
La CPU viene utilizzata durante:
- Deduplicazione e compressione
- Calcolo e controllo dei checksum
- Backup simultanei
- Verifica degli snapshot
- Pruning e garbage collection
- Restore di VM, container e file
- Sincronizzazione con datastore remoti
Il numero delle macchine virtuali, da solo, non permette di stimare il carico. Dieci VM di grandi dimensioni e con un elevato tasso di modifica possono richiedere più risorse di cinquanta VM poco attive.
Prima di scegliere la CPU devi quindi conoscere:
- Numero massimo di job contemporanei
- Durata della finestra di backup
- Frequenza delle verifiche
- Quantità di dati elaborati ogni giorno
- Numero di restore che potrebbero sovrapporsi
- Presenza di sincronizzazioni verso sedi remote o storage S3
Se i job vengono eseguiti prevalentemente in sequenza e la finestra disponibile è ampia, una configurazione con pochi core può essere sufficiente. Se invece molti sistemi devono essere protetti nello stesso intervallo, sarà necessario prevedere maggiore capacità di elaborazione.
Quanta RAM serve?
Proxmox raccomanda almeno 4 GiB per il sistema operativo, la cache del filesystem e i servizi PBS, ai quali aggiungere almeno 1 GiB per ogni TiB di storage gestito.
Un sistema con 20 TiB di storage parte quindi da una raccomandazione teorica di almeno 24 GiB:
- 4 GiB per sistema operativo, cache e servizi
- 20 GiB collegati ai 20 TiB di storage
Il risultato non deve essere interpretato come una configurazione definitiva. È opportuno prevedere ulteriore margine quando sono presenti:
- File system ZFS
- Numerosi job simultanei
- Molti snapshot
- Verifiche frequenti
- Finestre di backup ristrette
- Sincronizzazioni remote
- Crescita significativa dello storage
Se prevedi che il datastore passerà da 20 a 30 TiB durante il ciclo di vita del server, la memoria deve essere dimensionata sullo scenario futuro e non soltanto sull’occupazione iniziale.
RAM e ZFS
ZFS utilizza la memoria anche per migliorare la gestione e le prestazioni dello storage. La documentazione dell’installer propone, come riferimento generale, 4 GB più 1 GB di RAM per ogni TB di spazio disco raw quando si utilizza ZFS.
La presenza di ZFS non significa che sia necessario assegnare memoria senza limiti. Significa però che un datastore ZFS non dovrebbe essere progettato utilizzando esclusivamente il minimo previsto per PBS.
Separare il disco di sistema dal datastore
Il disco sul quale è installato Proxmox Backup Server e lo spazio destinato ai backup svolgono funzioni differenti.
Disco del sistema operativo
Lo storage di sistema contiene Debian, Proxmox Backup Server, configurazioni, log e pacchetti. Per la produzione, Proxmox raccomanda almeno 32 GiB disponibili e una configurazione ridondata.
Le opzioni indicate sono:
- Hardware RAID con cache di scrittura protetta da batteria
- Configurazione ZFS ridondata
ZFS non deve essere utilizzato sopra un controller hardware RAID, perché necessita di accedere direttamente ai dischi. In produzione è preferibile separare il sistema operativo dal datastore. Questa scelta facilita:
- Manutenzione e aggiornamenti
- Sostituzione dei dispositivi
- Controllo dello spazio disponibile
- Ripristino della configurazione PBS
- Individuazione dei problemi di I/O
Datastore dei backup
Il datastore contiene snapshot, indici e chunk deduplicati. PBS utilizza directory all’interno di file system supportati, come ext4, XFS o ZFS. Le sue prestazioni non dipendono soltanto dalla velocità sequenziale dei dischi. Durante backup, verifica, garbage collection e restore vengono eseguite numerose operazioni casuali su chunk e metadati. Un array molto capiente ma lento può quindi completare correttamente i backup ordinari e diventare un collo di bottiglia durante:
- Job simultanei
- Verifica di grandi quantità di dati
- Garbage collection
- Restore completi
- Recupero di numerosi file
- Ricostruzione dei servizi dopo un incidente
La capacità non può essere valutata separatamente dagli IOPS e dai tempi di risposta del datastore.
Come calcolare lo spazio necessario
Non esiste un rapporto universale tra dimensione delle VM e capacità richiesta da PBS. Lo spazio effettivo dipende da:
- Quantità iniziale dei dati protetti
- Tasso di modifica giornaliero
- Politica di retention
- Deduplicazione e compressione ottenute sul dataset reale
- Crescita prevista
Dati realmente protetti
Non considerare soltanto la capacità nominale dei dischi virtuali. Una VM con un disco virtuale da 2 TB potrebbe utilizzare solo 600 GB, mentre un database con una capacità nominale inferiore potrebbe generare molti più dati unici nel tempo. Il punto di partenza deve essere il primo backup effettivo, misurato dopo deduplicazione e compressione.
Tasso di modifica
Il tasso di modifica indica quanti dati nuovi o modificati devono essere conservati tra un backup e il successivo. Può essere molto diverso tra:
- Server applicativi
- File server
- Database
- Sistemi documentali
- VM con dati già compressi
- Archivi multimediali
- Workload cifrati
Una percentuale generica applicata a tutte le VM produce facilmente una stima errata.
Retention
La retention stabilisce quanti punti di ripristino conservare e per quanto tempo. Può includere copie:
- Orarie
- Giornaliere
- Settimanali
- Mensili
- Annuali
PBS conserva i chunk finché almeno uno snapshot li utilizza. Per questo motivo una retention più lunga può mantenere occupato lo spazio anche dopo la cancellazione dei dati dai sistemi originali.
Deduplicazione e compressione
La deduplicazione può ridurre significativamente lo spazio quando più VM contengono sistemi operativi, applicazioni o file simili. Il beneficio può essere inferiore con:
- Dati già compressi
- Video e immagini
- Backup applicativi compressi
- Database cifrati
- File modificati integralmente a ogni salvataggio
Non è quindi corretto costruire il dimensionamento su una percentuale di deduplicazione ipotetica. È preferibile misurare il risultato su un campione rappresentativo.
Formula di stima: una prima formula concettuale può essere espressa così:
Capacità richiesta = primo backup effettivo + dati unici conservati dalla retention + crescita prevista + margine operativo
Questa formula non sostituisce un test, ma evita l’errore di moltiplicare semplicemente la dimensione delle VM per il numero dei backup.
Esempio semplificato
Supponiamo che il primo periodo di osservazione rilevi:
- Primo backup dopo deduplicazione e compressione: 3,2 TiB
- Nuovi dati unici medi: 70 GiB al giorno
- Retention giornaliera: 30 punti
- Crescita prevista: 15%
Dopo il primo backup, i 29 punti giornalieri successivi potrebbero richiedere indicativamente: 29 × 70 GiB = 2.030 GiB. La base stimata sarebbe quindi circa: 3,2 TiB + 2 TiB = 5,2 TiB
A questo valore devono essere aggiunti:
- Dati conservati dalle retention settimanali e mensili
- Crescita prevista
- Margine necessario per manutenzione e variazioni del carico
L’esempio serve a illustrare il metodo. Il comportamento reale deve essere verificato sul dataset dell’azienda.
SSD, NVMe o HDD
La scelta dei dischi dipende dal rapporto richiesto tra capacità, prestazioni, tempo di ripristino e budget.
| Tecnologia | Vantaggio principale | Utilizzo indicativo | Aspetto da valutare |
| NVMe enterprise | Elevati IOPS e bassa latenza | Numerosi job e restore molto rapidi | Costo per TiB |
| SSD enterprise | Equilibrio tra capacità e prestazioni | Ambienti aziendali con finestre ristrette | Endurance e protezione dalla perdita di alimentazione |
| HDD enterprise | Elevata capacità a costo inferiore | Retention estesa e carichi meno intensivi | I/O casuale e durata delle verifiche |
| HDD con cache metadati | Capacità elevata con metadati accelerati | Datastore ZFS di grandi dimensioni | Progettazione e ridondanza della cache |
Proxmox raccomanda storage veloce e capace di sostenere carichi di I/O casuale. Per ottenere le prestazioni migliori indica SSD enterprise; in presenza di HDD consiglia una cache dei metadati, per esempio mediante uno ZFS special device in mirror.
Oltre alla tecnologia del disco devi verificare:
- Endurance
- Ridondanza
- Protezione dalla perdita di alimentazione
- Tempi di ricostruzione
- Compatibilità con il controller
- Disponibilità dei ricambi
- Garanzia e supporto
- Prestazioni durante un restore
Non tutti i backup richiedono NVMe. Un’infrastruttura con retention estesa e RTO poco stringenti può utilizzare HDD enterprise correttamente dimensionati. Al contrario, molti job simultanei e restore frequenti possono rendere insufficiente uno storage progettato unicamente sulla capacità.
Come dimensionare la rete
La rete determina quanti dati possono essere trasferiti nella finestra disponibile e quanto tempo richiede il ripristino. Proxmox raccomanda interfacce ridondate multi-Gigabit per i sistemi di produzione. La velocità necessaria deve però essere calcolata sul volume reale. Se devi trasferire 2 TiB in otto ore, non puoi basarti soltanto sulla velocità nominale della scheda. Devi considerare:
- Throughput realmente disponibile
- Traffico generato dagli altri servizi
- Job eseguiti contemporaneamente
- Latenza
- Overhead dei protocolli
- Eventuali sincronizzazioni offsite
- Restore che possono sovrapporsi ai backup
In ambienti articolati è opportuno separare il traffico di backup mediante VLAN o reti dedicate. In questo modo i job PBS non competono direttamente con le attività di produzione. La rete deve essere valutata anche in direzione opposta. Completare rapidamente il backup non è sufficiente se un restore completo richiede tempi incompatibili con l’RTO dell’azienda.
È possibile riutilizzare un vecchio server?
Un server già disponibile può essere riconvertito per PBS se offre capacità, affidabilità e indipendenza adeguate. Prima di riutilizzarlo devi verificare:
- Età e stato dei dischi
- Prestazioni del controller
- Quantità massima di RAM supportata
- Interfacce di rete disponibili
- Ridondanza di dischi e alimentatori
- Possibilità di gestione remota
- Consumi energetici
- Disponibilità dei ricambi
- Supporto del produttore
- Indipendenza dall’infrastruttura protetta
Nel progetto realizzato per Union Gas e Luce, alcuni server preesistenti sono stati riconvertiti per Proxmox Backup Server e disaster recovery. Il riutilizzo è stato possibile perché inserito in una valutazione complessiva dell’infrastruttura, non perché qualsiasi vecchio server fosse automaticamente adatto.
Errori da evitare
Utilizzare in produzione i requisiti minimi
I requisiti minimi servono a installare e valutare PBS, non a progettare un sistema aziendale affidabile.
Dimensionare lo storage sulla capacità nominale delle VM
Lo spazio deve essere stimato partendo dai dati effettivi, dal tasso di modifica e dalla retention.
Dare per scontata la deduplicazione
Il risultato dipende dalla natura dei dati e deve essere misurato.
Riempire il datastore fino al limite
È necessario conservare margine per crescita, variazioni impreviste e attività di manutenzione.
Considerare soltanto la velocità di backup
La configurazione deve rispettare anche il tempo massimo accettabile per il restore.
Ignorare i job di manutenzione
Verify, pruning e garbage collection devono avere risorse e finestre operative adeguate.
Checklist prima di scegliere l’hardware
Prima di definire la configurazione raccogli questi dati:
- Numero di VM, container e host
- Quantità di dati effettivamente protetti
- Tasso medio di modifica giornaliera
- Retention richiesta
- Crescita prevista
- Numero massimo di job simultanei
- Finestra disponibile per i backup
- RPO e RTO
- Frequenza di verify e garbage collection
- Tempo massimo accettabile per un restore
- Necessità di copie remote o S3
- Requisiti di ridondanza
- Durata prevista dell’infrastruttura
- Livello di assistenza richiesto
Queste informazioni permettono di passare dai requisiti generici di Proxmox a una configurazione coerente con i servizi da proteggere. Puoi utilizzare il configuratore AXOL Server per descrivere l’infrastruttura esistente, la capacità richiesta e l’eventuale necessità di backup o disaster recovery.
Dal requisito minimo al progetto reale
I requisiti ufficiali costituiscono il punto di partenza. Il dimensionamento reale dipende invece dai dati, dalla retention e dal tempo entro cui l’azienda deve riuscire a recuperare i servizi. Una configurazione corretta deve mantenere in equilibrio:
- Capacità disponibile
- Prestazioni del datastore
- Potenza di elaborazione
- Memoria
- Velocità di rete
- Ridondanza
- Crescita futura
- Tempi di ripristino
In produzione è opportuno valutare anche l’accesso al repository enterprise e il livello di supporto associato. Puoi approfondire le licenze Proxmox VE e Proxmox Backup Server disponibili tramite AXOL.
Quanta RAM serve per Proxmox Backup Server?
Proxmox raccomanda almeno 4 GiB per sistema operativo, cache e servizi, più almeno 1 GiB per ogni TiB di storage. Il valore deve essere verificato considerando ZFS, crescita e attività simultanee.
Quanto spazio serve per Proxmox Backup Server?
Dipende dal primo backup effettivo, dai dati unici prodotti nel tempo, dalla retention, dalla deduplicazione e dalla crescita. Una prova su dati rappresentativi è più affidabile di una percentuale standard.
Sono obbligatori gli SSD?
No. Proxmox indica gli SSD enterprise per ottenere le prestazioni migliori, ma è possibile utilizzare HDD enterprise quando capacità, cache dei metadati e finestre operative sono dimensionate correttamente.
Serve una rete a 10 GbE?
Non in ogni ambiente. La velocità deve essere scelta in base ai dati da trasferire, alla finestra disponibile e al tempo richiesto per il restore.
I requisiti minimi sono sufficienti per la produzione?
No. I requisiti minimi pubblicati da Proxmox sono destinati esclusivamente alla valutazione del software.
