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 incrementali, crittografati e con deduplicazione di un server Linux. La differenza che determina la scelta è la destinazione del backup. Restic supporta nativamente S3 e altre API per l’object storage, quindi un bucket è una destinazione di primo livello e non richiede l’installazione di nulla all’altra estremità. Borg richiede che il programma borg sia installato sulla macchina che contiene il repository, perché un repository Borg viene esposto 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 costituisce una differenza secondaria. Entrambi suddividono i file in blocchi usando il content-defined chunking, quindi una directory da 40 GB modificata per 200 MB richiede il caricamento di circa 200 MB. Entrambi eseguono la crittografia sul client. Entrambi montano uno snapshot con FUSE (filesystem in userspace), così puoi estrarre 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 contrassegnato come destinato esclusivamente ai test, quindi oggi devi distribuire la versione 1.4.

Il modello del repository è la vera differenza

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

Anche un repository Borg è costituito da file su disco, ma Borg non vi accede mai tramite un trasporto non intelligente. Per un repository remoto, Borg avvia borg serve sull'host remoto tramite SSH e comunica con quel processo usando il proprio protocollo. Il lato server esegue operazioni reali: contiene il repository, applica la transazione e risponde alle richieste relative agli indici. Per questo Borg non dispone di un backend S3 e il progetto non ne ha aggiunto uno. In un bucket non c'è alcun processo da eseguire.

Questo singolo elemento progettuale 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 è sempre cifrato. Non esiste una modalità non cifrata. restic init richiede una password, ne ricava una chiave con scrypt e da quel momento cifra e autentica ogni file pack scritto. Se si perde la password, i dati sono persi, perché per progettazione non esiste alcun metodo di recupero.

Con Borg la crittografia viene scelta durante la creazione del repository e la scelta è permanente. borg init --encryption=repokey conserva la chiave cifrata nel repository, quindi per il ripristino è sufficiente la passphrase. --encryption=keyfile conserva la chiave sul client in ~/.config/borg/keys/, quindi chi ruba l'intero repository non può ricavare nulla; è però necessario eseguire separatamente il backup di quel file di chiave, altrimenti gli archivi non saranno leggibili. Ogni modalità dispone di una variante -blake2, che usa BLAKE2b per l'autenticazione invece di HMAC-SHA256 ed è più veloce sull'hardware privo di accelerazione SHA. Esiste anche --encryption=none, che rappresenta una scelta concreta quando il repository si trova su un disco cifrato di proprietà dell'utente.

La regola pratica è: repokey-blake2 per un normale backup del server, keyfile quando il repository si trova in un ambiente di cui non ci si fida 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é è sufficientemente veloce da poter essere lasciata attiva per tutti i dati. zstd accetta i livelli da 1 a 22 e usa 3 per impostazione predefinita; zlib e lzma sono disponibili nei casi in cui si attribuisce più importanza allo spazio occupato che al tempo di elaborazione, mentre auto applica un'euristica a ogni chunk per evitare di comprimere nuovamente dati già compressi.

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 una versione successiva. Il formato 2 è ora quello predefinito per i nuovi repository e la compressione si configura con --compression usando i valori auto, off o max. Un repository precedente in formato 1 resta non compresso finché non viene migrato. Quindi, se il repository restic risale a prima della versione 0.14 e non è mai stato migrato, stai ancora occupando tutto lo spazio necessario per testi, log e dump di database.

Destinazioni remote: S3 e SSH

È in questo contesto che la scelta viene generalmente effettuata.

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

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. La versione installata sul sistema remoto deve essere compatibile con quella del client. Questo crea un vincolo se il sistema remoto non è amministrato da te. Non è un problema se il sistema remoto è un secondo server che amministri già. In questo caso ottieni anche la protezione più efficace contro il ransomware offerta dai due strumenti: una chiave SSH in modalità append-only. Forza la chiave a eseguire borg serve. Il client potrà aggiungere archivi, ma non eliminarli. In questo modo, un sistema compromesso non potrà cancellare la propria cronologia.

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

Restic offre un equivalente solo quando esegui il suo server REST, che supporta la modalità append-only. Con S3 standard puoi ottenere lo stesso risultato tramite una bucket policy o l’object lock. Questa funzione dipende dal provider, non da restic. Proteggi anche il trasporto, perché il lato SSH richiede la stessa attenzione di qualsiasi altro accesso: applica SSH con sole chiavi e una voce authorized_keys limitata all’account usato per i backup.

Velocità: implicazioni di ogni architettura

Nessuno dei due progetti pubblica un benchmark che sia possibile considerare attendibile per i propri dati. È quindi necessario ragionare in base al funzionamento interno.

Borg over SSH è veloce su una connessione con latenza elevata perché la componente server è intelligente. Il client invia una richiesta, il processo remoto borg serve risponde utilizzando l'indice del repository e la transazione viene confermata in un unico punto. La ricerca dei chunk non genera un round trip di rete per ogni file di piccole dimensioni.

Restic su object storage non dispone di una componente server. Deve quindi ricostruire il proprio stato a partire dai file indice e dai pack file scaricati tramite HTTP. Per mantenere sotto controllo il numero di richieste, raggruppa molti chunk piccoli in pack file di dimensioni maggiori prima dell'upload e conserva una cache locale in ~/.cache/restic, in modo che l'esecuzione successiva non debba scaricare nuovamente l'intero indice. Se si elimina la cache, il backup successivo sarà lento perché dovrà ricostruirla. Su una connessione con latenza elevata e 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 quasi del tutto. Entrambi gli strumenti finiscono per essere limitati dalla velocità con cui riescono a leggere e calcolare l'hash dei dati di origine.

Bloccare e sottoporre a backup più macchine

Borg 1.4 acquisisce un lock esclusivo sul repository per l’intera durata dell’operazione. Due client che scrivono contemporaneamente nello stesso repository non funzionano: il secondo resta in attesa, quindi termina con un timeout del lock. Il modello supportato prevede un repository per client. Questo significa anche che la deduplicazione avviene soltanto all’interno del repository di una singola macchina; di conseguenza, dieci server quasi identici archiviano 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 lock condiviso e soltanto le attività 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, dal secondo server in poi, spesso archiviano una quantità di dati molto ridotta. Il costo è il maggiore blast radius: un’unica password e un unico repository contengono tutto, quindi la perdita della password comporta la perdita di tutti e dieci i backup.

Conservazione: dimenticare e poi ripulire, oppure ripulire e poi compattare

Entrambi gli strumenti separano la scelta di cosa conservare dal recupero dello spazio e 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 è importante esplicitarla. 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 job cron che esegue il prune ma non la compact lascia un repository che cresce indefinitamente, mentre l'elenco degli archivi rimane breve. In restic, forget senza --prune rimuove soltanto i riferimenti agli snapshot; i dati rimangono finché non viene eseguito un prune.

Eseguire restic check dopo il prune. Verifica le strutture del repository e segnala eventuali danni. È molto meglio scoprirli in questa fase che 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 recuperare 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 la forma 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 trova corrispondenze e non estrae nulla, senza mostrare un errore che spieghi il motivo. 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.

Un ripristino che termina senza errori non costituisce comunque una prova. L'applicazione sovrastante stabilisce infatti in modo autonomo quando un ripristino è completo: un server Immich ricostruito a partire da una copia della directory dei dati di Postgres può ritrovarsi con tutte le foto presenti sul disco, ma con una timeline vuota. È esattamente il problema che il backup e il ripristino di Immich deve aggirare.

Qualunque strumento tu scelga, la pianificazione è soltanto metà del lavoro. Esegui periodicamente un ripristino in una directory temporanea e verifica effettivamente il risultato, come fa la guida completa alla configurazione del backup restic per un VPS tramite un timer systemd.

Quale soluzione scegliere in base al caso d’uso

Scegli restic quando la destinazione è l’object storage, quando vuoi usare un solo binario senza installare software sul sistema remoto, quando più macchine devono eseguire la deduplicazione tra loro oppure quando il ripristino potrebbe essere eseguito da un’altra persona. È un singolo binario statico a cui si passa l’URL di un repository, una caratteristica difficile da battere 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 di piccole dimensioni, quando vuoi usare una chiave SSH append-only come protezione contro il ransomware oppure quando vuoi configurare la compressione in modo specifico per ogni job. È lo strumento più datato, la sua serie stabile evolve lentamente e, nel software di backup, questo è un vantaggio.

Entrambe sono scelte corrette. La scelta sbagliata è quella che non hai mai testato. Se esegui già i dump a livello applicativo, continua a farlo: lo schema descritto in la configurazione di Nextcloud su Docker con dump del database si applica a entrambi gli strumenti, perché un file di database live copiato in un momento casuale 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, in entrambi i casi, il limite è generalmente la velocità di lettura e calcolo degli hash sul sistema sorgente. 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 chunk. Restic tende a essere più veloce quando la destinazione è un object storage, che Borg non supporta direttamente.

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

Non direttamente. Un repository Borg viene servito dal processo borg serve tramite SSH e nei bucket non viene eseguito alcun processo di questo tipo. Per aggirare il limite, alcuni montano l'object storage come filesystem tramite rclone. Il progetto Borg non lo raccomanda, perché un mount che si interrompe durante una transazione può corrompere il repository. Se serve usare un object storage, utilizzare restic.

Posso usare entrambi gli strumenti sugli stessi dati?

Sì, e alcune persone lo fanno: Borg su un secondo server per un ripristino locale rapido, restic su un object storage per la copia offsite. I due strumenti non condividono nulla, quindi il costo di lettura e calcolo degli hash viene sostenuto due volte e occorre conservare in modo sicuro due password. Usare questa configurazione solo dopo aver verificato entrambi i ripristini.

Cosa succede se perdo la password del repository?

I dati non possono essere recuperati con nessuno dei due strumenti. Restic deriva la chiave dalla password con scrypt e non esiste alcun bypass. In modalità repokey Borg conserva la chiave crittografata nel repository, quindi per ripristinare basta la passphrase; in modalità keyfile serve anche il file della chiave da ~/.config/borg/keys/. Conservare la password in un password manager che non si trovi sul server di cui viene eseguito il backup ed esportare la chiave Borg con borg key export se si utilizza keyfile.

Devo aspettare Borg 2.0?

No. A luglio 2026 Borg 2.0 è ancora in beta, nella versione 2.0.0b22, e il progetto la considera adatta solo ai test. La serie stabile è la 1.4, attualmente alla versione 1.4.5. Iniziare ora con la 1.4. Borg 2 modifica il formato del repository e fornisce una procedura di aggiornamento documentata, quindi iniziare oggi non crea problemi in futuro.