Quando si gestisce un’infrastruttura IT complessa, la strategia di backup è una delle decisioni più critiche. Non si tratta solo di salvare i dati, ma di garantire la continuità operativa in caso di disastro. In un ambiente di sala macchine, con centinaia di VM, database e configurazioni, la scelta dello strumento giusto può fare la differenza tra un ripristino rapido e un’interruzione prolungata.
Ho voluto mettere alla prova due dei più apprezzati strumenti di backup open-source: Restic e BorgBackup. L’obiettivo era capire come si comportano su un dataset significativo, simulando una situazione reale. Ho preparato un ambiente con circa 2TB di dati eterogenei, inclusi dischi virtuali, backup di database e file di configurazione, per replicare le sfide di un backup aziendale. Questo test non si è focalizzato solo sulla velocità del backup iniziale, ma anche sull’efficienza della deduplicazione, la velocità dei backup incrementali e, fondamentale, l’affidabilità del ripristino. I risultati hanno evidenziato punti di forza e di debolezza specifici per ciascuno, che possono guidare la scelta in base alle esigenze reali dell’infrastruttura. Leggi anche: Proxmox Replica: WAN Lenta, RPO Basso
Testato su: Debian 12 · Restic 0.16.2 · BorgBackup 1.2.7 · Agosto 2026
Prerequisiti / Ambiente di test
Per il test, ho utilizzato un server dedicato con le seguenti specifiche:
- Sistema Operativo: Debian 12 (Bookworm)
- CPU: Intel Xeon E3-1270 v6 (4 Core, 8 Thread)
- RAM: 64GB DDR4
- Storage: 2x 4TB NVMe in RAID1 (per il source data) e 1x 8TB HDD SATA (per il repository di backup)
- Dataset: 2TB di dati misti, composti da:
1.2TBdi immagini VM (qcow2, vmdk)500GBdi dump di database (PostgreSQL, MySQL)300GBdi file di configurazione, log e documenti vari
Ho assicurato che i filesystem di origine e destinazione fossero montati con opzioni standard per evitare distorsioni nei benchmark di I/O. L’obiettivo era simulare un ambiente di sala macchine con storage performante per i dati di origine e uno storage più lento, ma capiente, per i backup, come spesso accade nelle infrastrutture reali.
Restic: Caratteristiche e Test su 2TB
Restic è noto per la sua semplicità d’uso e la sua architettura basata su contenuti che consente una deduplicazione efficiente e backup incrementali rapidi. La sua capacità di gestire repository su vari backend, inclusi S3, SFTP e filesystem locali, lo rende estremamente versatile.
Inizializzazione e Primo Backup
L’inizializzazione del repository Restic è stata immediata. Ho creato un repository locale sul disco HDD da 8TB.
restic init --repo /mnt/backup_resticIl primo backup, che ha coinvolto tutti i 2TB di dati, ha impiegato circa 8 ore e 30 minuti. Durante questa fase, Restic ha consumato una quantità significativa di RAM, raggiungendo picchi di 12GB. Questo è un aspetto da considerare per dataset molto grandi, dove la RAM disponibile sul server di backup può diventare un fattore limitante. La deduplicazione iniziale ha ridotto i 2TB a circa 1.8TB di dati effettivi nel repository. Leggi anche: PostgreSQL: Trova la Query Killer con pg_stat_statements
restic backup /data --repo /mnt/backup_restic --verboseBackup Incrementali e Performance
Ho poi simulato modifiche ai dati (aggiungendo nuovi log, modificando file di configurazione e alterando piccole porzioni di VMDK) per testare i backup incrementali. Qui Restic ha brillato, completando i backup in un tempo medio di 15-20 minuti, con un consumo di RAM più contenuto (circa 4-6GB). La velocità è stata impressionante, grazie alla sua capacità di identificare e trasferire solo i blocchi di dati modificati.
BorgBackup: Caratteristiche e Test su 2TB
BorgBackup è un altro eccellente strumento di backup, celebre per la sua deduplicazione a livello di blocco e la crittografia integrata. È particolarmente apprezzato per la sua efficienza nello spazio e la capacità di gestire grandi quantità di dati con un overhead minimo una volta che il repository è stabilizzato.
Inizializzazione e Primo Backup
Anche per BorgBackup, l’inizializzazione del repository è stata semplice. Ho creato un repository sulla stessa destinazione HDD.
borg init --encryption=repokey /mnt/backup_borgIl primo backup dei 2TB ha richiesto circa 9 ore e 15 minuti, con un tempo leggermente superiore rispetto a Restic. Tuttavia, la deduplicazione è stata superiore: i 2TB di dati originali sono stati ridotti a circa 1.5TB nel repository, un risparmio di spazio rilevante rispetto a Restic sul primo full backup. Questo è un vantaggio significativo per chi ha vincoli di spazio di storage.
borg create --stats --progress /mnt/backup_borg::{hostname}-{now} /dataBackup Incrementali e Performance
I backup incrementali con BorgBackup hanno richiesto in media 25-30 minuti, un po’ più lenti di Restic, ma comunque molto efficienti. Il consumo di CPU è rimasto moderato, e la RAM utilizzata è stata inferiore rispetto a Restic, attestandosi intorno ai 2-3GB. La sua robustezza e la deduplicazione aggressiva lo rendono ideale per scenari dove lo spazio è una risorsa preziosa e i backup incrementali sono meno frequenti ma devono essere estremamente efficienti.
Confronto Dettagliato e Risultati
Il test ha rivelato che entrambi gli strumenti sono validi, ma eccellono in scenari diversi. Ecco una sintesi dei risultati principali:
| Caratteristica | Restic | BorgBackup |
|---|---|---|
| Tempo Primo Backup | ~8h 30min | ~9h 15min |
| **Tempo Incr. |
La scelta tra Restic e BorgBackup dipende dalle priorità. Se la velocità dei backup incrementali e la semplicità sono al primo posto, Restic è una scelta solida. Se la massima efficienza dello spazio e una deduplicazione superiore sono fondamentali, BorgBackup si distingue. Leggi anche: Honeypot Agosto: 7 Giorni, 1.200 Attacchi SSH
Errori comuni e troubleshooting
Durante i test, ho riscontrato alcuni punti che meritano attenzione:
- Consumo RAM di Restic: Per dataset molto grandi, se il server di backup ha RAM limitata, Restic può esaurire la memoria e fallire. È possibile mitigare questo problema con l’opzione
--limit-uploado segmentando i backup, ma la soluzione migliore è avere RAM sufficiente. - Consumo CPU di BorgBackup: Il primo backup di Borg può essere intensivo per la CPU. Assicurarsi che il server abbia risorse sufficienti o pianificare il primo backup in orari di basso carico.
- Verifica dei Repository: Entrambi gli strumenti offrono comandi per verificare l’integrità del repository. È fondamentale eseguirli regolarmente per assicurarsi che i backup siano recuperabili. Un backup non verificato è un backup inesistente.
restic check --repo /mnt/backup_restic
borg check /mnt/backup_borg- Gestione delle Credenziali: Utilizzare variabili d’ambiente per le password dei repository (
RESTIC_PASSWORDoBORG_PASSPHRASE) è una pratica sicura per l’automazione, evitando di scriverle direttamente negli script.
FAQ — Domande Frequenti
Posso usare Restic/BorgBackup su NAS o storage di rete?
Sì, entrambi supportano repository su storage di rete tramite SSH (sftp) o protocolli cloud (S3 per Restic). È fondamentale assicurarsi che la connessione di rete sia stabile e sufficientemente veloce per non compromettere i tempi di backup e ripristino. La latenza e la banda possono influire significativamente sulle performance.
Qual è il miglior strumento per il ripristino d’emergenza?
Entrambi sono eccellenti. Restic permette di montare il repository come un filesystem virtuale, facilitando il recupero di singoli file. BorgBackup offre un’interfaccia a riga di comando robusta per estrarre archivi o singoli file. La scelta dipende dalla preferenza personale e dal workflow di ripristino.
La crittografia integrata è sicura?
Sì, entrambi utilizzano algoritmi di crittografia standard del settore (AES-256 in modalità CTR per Restic, autenticato con HMAC-SHA256; AES-256 per BorgBackup). È cruciale proteggere la passphrase del repository, poiché senza di essa i dati sono irrecuperabili. Non è consigliabile affidarsi solo a queste crittografie per dati estremamente sensibili, ma sono un ottimo primo livello di protezione.
Come posso automatizzare i backup e la pulizia dei vecchi snapshot?
Entrambi gli strumenti possono essere integrati facilmente in script bash o systemd timers. È buona pratica combinare il comando di backup con un comando di pulizia (ad esempio, restic forget --prune o borg prune) per mantenere il repository snello e rispettare le policy di retention. Leggi anche: ACN Incidente: Checklist Notifica 24 Ore
Conclusioni con takeaway operativi
La scelta tra Restic e BorgBackup non è universale, ma dipende dalle specifiche esigenze del tuo ambiente. Per un’organizzazione con 2.000 endpoint e 300+ VM, dove la velocità di ripristino (RTO) e la frequenza dei backup (RPO) sono cruciali, la comprensione delle loro differenze è fondamentale. Se hai bisogno di backup incrementali estremamente rapidi e una buona versatilità di backend, Restic è un’ottima soluzione, a patto di avere RAM sufficiente. Se invece la priorità è la massima efficienza dello spazio di storage e una deduplicazione aggressiva, BorgBackup offre un vantaggio innegabile, specialmente per archivi a lungo termine. Il consiglio operativo è sempre quello di testare entrambi gli strumenti sul proprio dataset reale, monitorando non solo i tempi, ma anche l’utilizzo delle risorse e, soprattutto, la capacità di ripristinare i dati in modo affidabile. Un backup è utile solo se può essere ripristinato.
Aggiornato: Agosto 2026
