Restic o BorgBackup: quale scegliere per i backup?

Restic e BorgBackup in un paragrafo

Restic e BorgBackup svolgono entrambi la stessa funzione di base: backup deduplicati, crittografati e incrementali di un server Linux. La differenza che determina la scelta è la destinazione del backup. Restic supporta nativamente S3 e altre API di object storage, quindi un bucket è una destinazione di prima classe e non richiede l'installazione di nulla sul sistema remoto. Borg richiede l'installazione del programma borg sul computer che ospita il repository, perché un repository Borg viene reso disponibile da un processo, non da un filesystem o da un'API. Se la destinazione è l'object storage, la scelta è già determinata. Se la destinazione è un secondo sistema Linux sotto il tuo controllo, Borg è un'opzione valida e spesso più veloce.

Tutto il resto rappresenta una differenza secondaria. Entrambi suddividono i file in blocchi usando il content-defined chunking, quindi una directory di 40 GB con 200 MB di modifiche richiede il caricamento di circa 200 MB. Entrambi eseguono la crittografia sul client. Entrambi montano uno snapshot con FUSE (filesystem nello spazio utente), permettendoti di copiare un singolo file. A luglio 2026 Restic è alla versione 0.19.1 e la serie stabile di Borg è la 1.4, precisamente la 1.4.5. Borg 2.0 è in beta da anni ed è ancora indicato solo per i test, quindi oggi dovresti distribuire la versione 1.4.

Il modello del repository è la differenza reale

Un repository restic è una directory di file: config, keys/, snapshots/, index/ e data/, che contengono file pack. Non serve altro per leggerlo. Per questo restic può utilizzare così tanti backend. Qualsiasi archivio in grado di inserire, recuperare, elencare ed eliminare blob può contenere un repository restic. In questo modo un singolo binario supporta percorsi locali, SFTP, il proprio server REST, S3, Backblaze B2, Azure, Google Cloud Storage e qualsiasi destinazione raggiungibile da rclone.

Anche un repository Borg è costituito da file su disco, ma Borg non vi accede tramite un trasporto semplice. Per un repository remoto, Borg avvia borg serve sul sistema remoto tramite SSH e comunica usando il proprio protocollo con quel processo. Il lato server esegue operazioni reali: contiene il repository, applica la transazione e risponde alle richieste sugli indici. Per questo Borg non dispone di un backend S3 e il progetto non ne ha aggiunto uno. Non esiste alcun processo da eseguire all'interno di un bucket.

Questo singolo elemento di progettazione determina la maggior parte delle differenze pratiche riportate di seguito.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

Crittografia: una delle due può essere disattivata

Restic usa sempre la crittografia. Non esiste una modalità non crittografata. restic init richiede una password, ne deriva una chiave con scrypt e crittografa e autentica ogni file pack scritto successivamente. Se perdi la password, i dati sono persi, perché per progettazione non esiste alcun metodo di recupero.

Borg rende la crittografia una scelta al momento della creazione del repository, e la scelta è permanente. borg init --encryption=repokey conserva la chiave crittografata nel repository, quindi per il ripristino basta la passphrase. --encryption=keyfile conserva la chiave sul client in ~/.config/borg/keys/, quindi chi ruba l’intero repository non dispone comunque di nulla; devi quindi eseguire separatamente il backup di quel file di chiave, altrimenti i tuoi archivi non saranno leggibili. Ogni modalità dispone di una variante -blake2 che esegue l’autenticazione con BLAKE2b anziché HMAC-SHA256, più veloce sull’hardware privo di accelerazione SHA. Esiste anche --encryption=none, una scelta appropriata quando il repository si trova su un disco crittografato di tua proprietà.

La regola pratica è: repokey-blake2 per il backup di un normale server, keyfile quando il repository si trova in un ambiente di cui non ti fidi completamente e mai none su una macchina a noleggio.

Compressione e perché restic l'ha introdotta tardi

Borg supporta la compressione fin dall'inizio. L'impostazione predefinita è lz4, scelta perché è abbastanza veloce da poter essere sempre attiva. zstd accetta livelli da 1 a 22 e usa 3 come valore predefinito. zlib e lzma sono disponibili nei casi in cui si preferisce ridurre i byte anziché i minuti. auto applica un'euristica a ogni chunk, in modo che i dati già compressi non vengano compressi una seconda volta.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

Restic non supportava affatto la compressione fino al formato di repository 2, che richiede restic 0.14.0 o versioni successive. Il formato 2 è ora quello predefinito per i nuovi repository e la compressione si imposta con --compression usando i valori auto, off o max. Un repository nel vecchio formato 1 rimane non compresso finché non viene migrato. Quindi, se il repository restic è precedente alla versione 0.14 e non è mai stato migrato, si continua a occupare la dimensione completa per testo, log e dump di database.

Destinazioni remote: S3 e SSH

È in questo punto che di solito si decide.

Per raggiungere S3, restic richiede credenziali nell'ambiente e nessun altro componente in esecuzione altrove. Lo stesso modello funziona con un bucket che ospiti autonomamente. È un abbinamento comune: esegui MinIO per un'API S3 sul tuo VPS e configura restic per usarlo.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Per raggiungere un repository remoto, Borg richiede SSH e un'installazione di Borg sul sistema remoto. Inoltre, la versione in esecuzione sul sistema remoto deve essere compatibile con il client. Questo crea difficoltà se il sistema remoto non è sotto il tuo controllo. Non crea problemi se il sistema remoto è un secondo server che amministri già. In questo caso offre anche la protezione più efficace contro il ransomware tra quelle disponibili nei due strumenti: una chiave SSH di sola aggiunta. Imposta la chiave in modo che esegua borg serve. Il client potrà così aggiungere archivi, ma non eliminarli. Di conseguenza, una macchina compromessa non potrà cancellare la propria cronologia.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

Restic offre un meccanismo equivalente solo eseguendo il proprio server REST, che supporta una modalità di sola aggiunta. Con S3 standard, puoi ottenere lo stesso risultato tramite una policy del bucket o il blocco degli oggetti. Questa funzione è gestita dal provider, non da restic. Proteggi anche il trasporto. La configurazione SSH richiede la stessa attenzione di qualsiasi altro accesso: applica SSH con sole chiavi e una voce authorized_keys limitata all'account di backup.

Velocità: implicazioni di ogni progetto

Nessuno dei due progetti pubblica un benchmark affidabile per i propri dati, quindi è meglio ragionare sul meccanismo.

Borg su SSH è veloce su una connessione con latenza perché il lato server è intelligente. Il client invia una richiesta, il processo remoto borg serve risponde usando l'indice del repository e la transazione viene confermata in un unico punto. Le ricerche dei chunk non diventano richieste di rete separate per ogni file piccolo.

Restic su object storage non dispone di un lato server, quindi deve ricostruire la propria visione usando i file indice e i file pack scaricati tramite HTTP. Per mantenere sotto controllo il numero di richieste, raggruppa molti chunk piccoli in file pack più grandi prima del caricamento e mantiene una cache locale in ~/.cache/restic, così l'esecuzione successiva non deve scaricare nuovamente l'intero indice. Se si elimina la cache, il backup successivo è lento mentre la ricostruisce. Su una connessione ad alta latenza con milioni di file piccoli, questo è il caso in cui restic risulta più lento di Borg sugli stessi dati.

Su un disco locale o su una LAN veloce, la differenza si riduce soprattutto e la velocità di entrambi gli strumenti finisce per essere limitata dalla rapidità con cui riescono a leggere e calcolare l'hash dell'origine.

Blocco e backup di più macchine

Borg 1.4 acquisisce un blocco esclusivo sul repository per l'intera operazione. Due client che scrivono contemporaneamente nello stesso repository non funzionano: il secondo attende, quindi termina con un timeout del blocco. Il modello supportato prevede un repository per client. Di conseguenza, la deduplicazione avviene solo all'interno del repository di una singola macchina, quindi dieci server quasi identici memorizzano dieci copie dello stesso sistema di base.

Restic consente a più client di eseguire contemporaneamente il backup nello stesso repository, perché un backup acquisisce un blocco condiviso e solo le operazioni di manutenzione, come prune, ne acquisiscono uno esclusivo. Dieci server simili configurati per usare un unico repository restic eseguono la deduplicazione anche tra loro, e spesso il secondo server memorizza una quantità di dati molto ridotta. Il rischio riguarda l'entità del danno: un'unica password e un unico repository contengono tutto, quindi perdere la password significa perdere tutti e dieci i backup.

Retenzione: dimenticare e poi eliminare, oppure eliminare e poi compattare

Entrambi gli strumenti separano la decisione su cosa conservare dal recupero dello spazio, ed entrambi richiedono l'esecuzione del secondo passaggio.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

La trappola è la stessa in entrambi gli strumenti ed è opportuno dichiararla chiaramente. In Borg, borg prune rimuove gli archivi, ma da solo non libera spazio su disco. Lo spazio viene recuperato quando viene eseguito borg compact. Di conseguenza, un processo cron che esegue l'eliminazione senza mai compattare lascia un repository che cresce indefinitamente, mentre l'elenco degli archivi rimane breve. In restic, forget senza --prune rimuove solo i riferimenti agli snapshot; i dati rimangono fino all'esecuzione di prune.

Eseguire restic check dopo l'eliminazione. Verifica le strutture del repository e segnala eventuali danni. È molto meglio rilevare un problema in questo modo che scoprirlo durante un ripristino.

Il ripristino è l'unico test che conta

Entrambi gli strumenti montano uno snapshot per consentirti di esplorarne il contenuto. È il modo più rapido per ripristinare un singolo file.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

Nota il formato del percorso in borg extract. I percorsi all'interno di un archivio vengono memorizzati senza la barra iniziale. Per questo etc/nginx è corretto, mentre /etc/nginx non corrisponde a nulla e non estrae alcun file, senza segnalare il motivo dell'errore. L'estrazione scrive inoltre nella directory di lavoro corrente. Devi quindi spostarti prima in una directory temporanea, altrimenti sovrascriverai i file attivi con versioni precedenti.

Qualunque strumento tu scelga, la pianificazione è solo metà del lavoro. Esegui periodicamente un ripristino in una directory temporanea e controllalo davvero, come fa la procedura completa in la guida al backup di restic per un VPS, utilizzando un timer di systemd.

Quale strumento è adatto a quale attività

Scegli restic quando la destinazione è l'object storage, quando vuoi usare un solo binary senza installare software sul sistema remoto, quando più macchine devono deduplicare i dati tra loro o quando il ripristino potrebbe essere eseguito da un'altra persona. È un singolo binary statico a cui si associa un URL per il repository, una soluzione difficile da superare dal punto di vista operativo.

Scegli Borg quando la destinazione è un sistema Linux che controlli, quando la connessione presenta latenza e il dataset contiene milioni di file piccoli, quando vuoi usare la chiave SSH append-only come misura di protezione contro il ransomware o quando vuoi configurare la compressione per ogni attività. È lo strumento più datato, la sua serie stabile evolve lentamente e, nel software di backup, questo è un vantaggio.

Entrambe sono risposte corrette. La risposta sbagliata è quella che non hai mai testato. Se esegui già dump a livello applicativo, continua a usarli: il modello descritto in la configurazione di Nextcloud su Docker con dump del database si applica a entrambi gli strumenti, perché un file di database copiato in un momento casuale mentre il database è in uso non costituisce un backup del database.

FAQ

restic o BorgBackup è più veloce?

Su un disco locale o su una LAN veloce, le prestazioni sono simili e alla fine entrambi sono limitati dalla velocità di lettura e calcolo degli hash sull'origine. Borg tende a essere più veloce su una connessione SSH ad alta latenza con moltissimi file piccoli, perché un processo borg serve sul sistema remoto risponde alle richieste sull'indice senza un round trip di rete per ogni blocco. restic tende a essere più veloce quando la destinazione è l'object storage, dove Borg non può operare direttamente.

BorgBackup può eseguire il backup su S3 o Backblaze B2?

Non direttamente. Un repository Borg viene fornito dal processo borg serve tramite SSH e nessun processo di questo tipo viene eseguito all'interno di un bucket. Per aggirare il problema, alcuni montano l'object storage come filesystem con rclone. Il progetto Borg non lo consiglia, perché un mount che si interrompe durante una transazione può danneggiare il repository. Se ti serve l'object storage, usa restic.

Posso eseguire entrambi gli strumenti sugli stessi dati?

Sì, e alcune persone lo fanno: Borg su un secondo server per un ripristino locale rapido, restic sull'object storage per la copia fuori sede. Non condividono nulla, quindi il costo di lettura e calcolo degli hash viene sostenuto due volte e devi conservare in sicurezza due password. Esegui questa configurazione solo dopo aver verificato entrambi i ripristini.

Cosa succede se perdo la password del repository?

I dati non sono recuperabili con nessuno dei due strumenti. restic deriva la propria chiave dalla password usando scrypt e non esiste alcun metodo per aggirare questa protezione. Borg in modalità repokey memorizza la chiave crittografata all'interno del repository, quindi per il ripristino è sufficiente la passphrase. In modalità keyfile serve anche il file della chiave da ~/.config/borg/keys/. Conserva la password in un password manager che non risieda sul server sottoposto a backup ed esporta la chiave Borg con borg key export se usi keyfile.

Devo aspettare Borg 2.0?

No. A luglio 2026 Borg 2.0 è ancora in versione beta, precisamente 2.0.0b22, e il progetto lo indica esclusivamente per i test. La serie stabile è la 1.4, attualmente alla versione 1.4.5. Inizia ora con la versione 1.4. Borg 2 modifica il formato del repository e fornisce un percorso di aggiornamento documentato, quindi iniziare oggi non ti impedirà di effettuare l'aggiornamento in seguito.