Restic o BorgBackup: quale scegliere per i backup

Restic e BorgBackup a confronto, in un paragrafo

Restic e BorgBackup svolgono la stessa funzione principale: backup incrementali, deduplicati e cifrati di un server Linux. La differenza che determina la scelta è la destinazione del backup. Restic supporta nativamente S3 e altre API di object storage, rendendo un bucket una destinazione di primo livello senza necessità di software installato sul lato remoto. La versione stabile di Borg richiede che il programma borg sia installato sulla macchina che ospita il repository, poiché un repository Borg viene gestito da un processo e non da un filesystem o da un'API. Se la destinazione è un object storage, la scelta è obbligata. Se la destinazione è un secondo server Linux sotto il proprio controllo, Borg è un'opzione valida e spesso più veloce.

Ogni altra differenza è di minore entità. Entrambi suddividono i file tramite chunking basato sul contenuto, quindi una directory da 40 GB modificata per 200 MB caricherà circa 200 MB. Entrambi cifrano i dati sul client. Entrambi permettono di montare uno snapshot tramite FUSE (filesystem in userspace) per estrarre singoli file. A ottobre 2026, restic è alla versione 0.19.1 e la serie stabile di Borg è la 1.4, alla versione 1.4.5. Borg 2.0 è in beta da anni ed è ancora contrassegnato come versione di test, pertanto la 1.4 è la versione da implementare oggi.

Il modello del repository è la vera differenza

Un repository restic è una directory di file: config, keys/, snapshots/, index/ e data/ pieni di file pack. Non serve altro per leggerlo. È per questo che restic può gestire così tanti backend. Qualsiasi archivio in grado di eseguire operazioni di put, get, list e delete su dei blob può ospitare un repository restic; ecco come un singolo binario supporta percorsi locali, SFTP, il proprio server REST, S3, Backblaze B2, Azure, Google Cloud Storage e qualsiasi cosa raggiungibile tramite rclone.

Anche un repository Borg è costituito da file su disco, ma Borg non comunica mai con esso tramite un trasporto passivo. Per un repository remoto, Borg avvia borg serve sul lato remoto tramite SSH e utilizza il proprio protocollo per dialogare con quel processo. Il lato server esegue un lavoro effettivo: ospita il repository, applica la transazione e risponde alle interrogazioni sull'indice. Questo è il motivo per cui la serie stabile Borg 1.4 non dispone di un backend S3. Non c'è alcun processo da eseguire all'interno di un bucket. Borg 2 cambia questo aspetto: sposta l'archiviazione in un nuovo livello chiamato borgstore e la sua documentazione descrive URL di repository sftp://, rclone:remote:path e s3: o b2:. Tuttavia, Borg 2 è ancora una versione beta che il progetto sconsiglia di utilizzare in produzione, quindi per i backup reali di oggi la lacuna S3 rimane.

Questo singolo fatto progettuale determina la maggior parte delle differenze pratiche elencate 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 in ritardo

Borg esegue la compressione fin dall'inizio. Il valore predefinito è lz4, scelto perché sufficientemente veloce da poter essere mantenuto attivo per tutto. zstd accetta livelli da 1 a 22 con un valore predefinito di 3, zlib e lzma sono disponibili per i casi in cui si preferisce risparmiare byte piuttosto che minuti, mentre auto esegue un'euristica per ogni chunk, in modo che i dati già compressi non vengano elaborati due volte.

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

Restic non ha avuto alcuna compressione fino al formato di repository 2, che richiede restic 0.14.0 o versioni successive. Il formato 2 è ora il valore predefinito per i nuovi repository e la compressione viene impostata con --compression su uno dei cinque valori: auto (il predefinito), off, fastest, better o max. Le modalità fastest e better sono state introdotte in restic 0.19.0, pertanto i binari più datati accettano solo auto, off e max. Un repository in formato 1 rimane non compresso finché non viene migrato. Di conseguenza, se il tuo repository restic è precedente alla versione 0.14 e non è mai stato migrato, stai ancora occupando lo spazio massimo per file di testo, 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; entrambi finiscono per essere limitati dalla velocità di lettura e di hashing sulla sorgente. Borg tende a prevalere su un link SSH ad alta latenza con molti file piccoli, poiché un processo borg serve sul lato remoto risponde alle interrogazioni sull'indice senza richiedere un round trip di rete per ogni chunk. Restic tende a prevalere quando la destinazione è un object storage, dove la versione stabile di Borg non può operare.

BorgBackup può eseguire backup su S3 o Backblaze B2?

Non con la serie stabile 1.4. Un repository Borg 1.4 è gestito dal processo borg serve via SSH, e nessun processo di questo tipo può essere eseguito all'interno di un bucket. Borg 2 aggiunge URL di repository s3:, b2: e rclone: tramite il layer borgstore, ma a ottobre 2026 Borg 2 è ancora in beta e il progetto ne sconsiglia l'uso in produzione. Con la 1.4, gli utenti aggirano il limite montando l'object storage come filesystem tramite rclone. Le FAQ di Borg sconsigliano i filesystem di rete per l'archiviazione dei repository e avvertono che FUSE e i filesystem di rete possono causare rallentamenti o corruzione dei dati. Se oggi è necessario utilizzare un object storage per backup in produzione, si utilizzi restic.

Posso utilizzare entrambi gli strumenti sugli stessi dati?

Sì, alcuni utenti lo fanno: Borg verso un secondo server per un ripristino locale rapido, restic verso un object storage per la copia offsite. Non condividono nulla, quindi si pagano due volte i costi di lettura e hashing e si devono gestire due password in modo sicuro. Questa configurazione va adottata solo dopo aver testato il ripristino con entrambi gli strumenti.

Cosa succede se perdo la password del repository?

I dati non sono recuperabili con nessuno dei due strumenti. Restic deriva la sua chiave dalla password tramite scrypt e non esiste alcuna procedura di bypass. Borg in modalità repokey memorizza la chiave cifrata all'interno del repository, quindi la sola passphrase permette il ripristino; in modalità keyfile è necessario anche il file chiave da ~/.config/borg/keys/. Si conservi la password in un password manager non residente sul server oggetto del backup e si esporti la chiave di Borg con borg key export se si utilizza keyfile.

Dovrei aspettare Borg 2.0?

No. A ottobre 2026 Borg 2.0 è ancora in beta, alla versione 2.0.0b25 (rilasciata il 27 settembre 2026), e il progetto la classifica esclusivamente per scopi di test. La serie stabile è la 1.4, attualmente alla 1.4.5. Si inizi con la 1.4. Borg 2 modifica il formato del repository e include un percorso di aggiornamento documentato (borg transfer --from-borg1), quindi iniziare oggi non preclude futuri passaggi. Borg 2 è inoltre la versione in cui arriverà il supporto nativo per S3, B2 e rclone, una volta raggiunta la stabilità.