Backup automatizzati con BorgBackup: deduplicazione, storage remoto e verifiche di ripristino

In questo articolo spiego come impostare in modo tecnicamente solido i backup automatizzati con BorgBackup: dall’architettura del repository e la memorizzazione con deduplicazione dipendente dal contenuto, al trasporto remoto fino alle verifiche di ripristino automatizzate, alle strategie di prune e ai passaggi tipici per la risoluzione dei problemi. L’obiettivo sono procedure operative affidabili per amministratori, ingegneri di sistema e operatori, che pongano al centro disponibilità, integrità e manutenibilità.

Perché BorgBackup? Una breve panoramica dell’architettura

BorgBackup (in breve: Borg) è uno strumento di backup a livello di file che offre deduplicazione dipendente dal contenuto, crittografia end-to-end opzionale e trasferimento efficiente tramite SSH. La deduplicazione significa che sezioni di dati identiche (chunk) vengono memorizzate una sola volta nel repository; ciò riduce significativamente lo spazio occupato dai backup ripetuti. Borg conserva i backup in un repository, che può trovarsi localmente su un server o essere raggiunto via SSH tramite borg serve. La topologia del repository è centrale per pRESTazioni, locking e manutenzione, perciò va pianificata in anticipo.

Backup automatizzati con BorgBackup: architettura e regole operative

Per un funzionamento produttivo sono vincolanti diversi aspetti:

• Separazione per tenant o per servizio: create un repository separato per ogni tenant o servizio critico, se le regole di conservazione o il controllo degli accessi differiscono.
• Compatibilità delle versioni: mantenete sincronizzate le versioni di Borg su client e server; testate i cambi di versione in ambienti di staging prima di introdurli in produzione.
• Sicurezza SSH: utilizzate autenticazione basata su chiave, un account backup dedicato (es. backup-user) e la RESTrizione del comando in AuthorizedKeys per limitare l’accesso SSH a borg serve.
• Pianificazione delle risorse: i backup iniziali sono intensivi in termini di CPU e I/O; prevedete maggiore consumo di RAM/CPU sui client e, se necessario, picchi di carico sull’host del repository.

Inizializzazione del repository, strategie di crittografia e gestione delle chiavi

Borg supporta modalità di crittografia come repokey (chiave nel repository, protetta da passphrase) e keyfile (chiave privata esterna). Repokey è operativamente più semplice, mentre keyfile consente una gestione delle chiavi più rigorosa, poiché la chiave privata è conservata separatamente. La perdita delle chiavi per repository crittografati comporta nella maggior parte dei casi la perdita permanente dei dati — pianificate pertanto processi di rotazione delle chiavi, backup delle chiavi e conservazione.

# Repository lokal initialisieren (repokey)
borg init --encryption=repokey /srv/backup/repo

# Remote-Repository-Init per SSH (auf Backup-Host)
ssh backup-admin@backup.example.com "borg init --encryption=repokey /srv/backup/repo"

Una voce sicura in AuthorizedKeys con RESTrizioni impedisce l’accesso shell interattivo e consente solo operazioni Borg per il repository specificato:

command="/usr/bin/borg serve --RESTrict-to-path /srv/backup/repo",no-agent-forwarding,no-port-forwarding,no-pty ssh-rsa AAAA... backup-client@example

Gestite le chiavi SSH e le passphrase in un secrets‑store dedicato (es. HashiCorp Vault) e archiviate le chiavi secondo policy definite in una sede separata, disponibile offline. Documentazione e rotazione regolare delle chiavi sono determinanti per l’operatività.

Workflow pratico di backup e scripting robusto

I backup dovrebbero essere eseguiti in modo idempotente, atomico e con logging accurato. Utilizzare uno script wrapper con set -euo pipefail, locking (ad es. flock), output strutturato per il parsing del monitoring e gestione dei codici di uscita.

#!/usr/bin/env bash
set -euo pipefail

LOCKFILE=/var/lock/borg-backup.lock
exec 9>&1

flock -n 9 || { echo "Backup läuft bereits"; exit 2; }

export BORG_REPO=ssh://backup-user@backup.example.com:22/srv/backup/repo
export BORG_PASSPHRASE_FILE=/etc/borg/passphrase
export BORG_RSH="ssh -i /etc/borg/backup_key -o StrictHostKeyChecking=yes"

LOGFILE=/var/log/borg-backup/$(date +%F).log
mkdir -p $(dirname "$LOGFILE")

/usr/bin/borg create -v --stats --compression zstd,6 
  $BORG_REPO::"$(hostname)-$(date +%Y-%m-%d_%H:%M:%S)" 
  /etc /var/www /srv/data 
  --exclude '/var/cache' --exclude '/proc' --exclude '/sys' 2>&1 | tee -a "$LOGFILE"

exit_code=${PIPESTATUS[0]}

if [ "$exit_code" -ne 0 ]; then
  echo "Borg create failed with exit $exit_code" | tee -a "$LOGFILE"
  exit $exit_code
fi

# Prune nur nach erfolgreichem Backup
/usr/bin/borg prune -v --list $BORG_REPO --keep-daily=7 --keep-weekly=4 --keep-monthly=6 --keep-yearly=1 2>&1 | tee -a "$LOGFILE"

Eseguire questo script tramite systemd-timer, non tramite Cron, per ottenere un avvio più affidabile, politiche di retry automatiche e collegamento nativo al logging con journalctl.

Esempio: systemd Service e Timer

# /etc/systemd/system/borg-backup.service
[Unit]
Description=Borg Backup Job
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/run-borg-backup.sh
Nice=10

# /etc/systemd/system/borg-backup.timer
[Unit]
Description=Daily Borg Backup Timer

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Impostare Nice e l’affinità della CPU, se necessario, per ridurre l’impatto dei job di backup sui servizi produttivi.

Deduplicazione: funzionamento e implicazioni operative

Borg utilizza il content-defined chunking: i dati vengono suddivisi in blocchi variabili identificati tramite hash crittografico. La deduplicazione risparmia spazio, ma comporta implicazioni:

• La deduplicazione è a livello di repository: il risparmio avviene solo all’interno dello stesso repository, non tra repository diversi.
• Il chunking genera carico CPU e talvolta RAM; i client con molti file piccoli traggono particolare beneficio, ma la creazione dei chunk grava sulle risorse.
• Durante il RESTore di grandi volumi di dati si verificano molte letture di piccole dimensioni; pianificate i profili di I/O e testate le finestre di ripristino.

Opzioni di storage remoto: valutazione e raccomandazioni

Il repository SSH (borg serve) è l’opzione raccomandata: percorsi di codice testati, corretta gestione dei lock e bassa complessità. Backend alternativi comportano rischi:

• NFS/SMB: possono causare problemi di locking e di consistenza e favorire la corruzione del repository; pertanto, i filesystem di rete montati non sono consigliati.
• Object storage (es. S3): Borg non supporta S3 nativamente; gateway (ad es. bridge SFTP o filesystem) sono possibili, ma aumentano la complessità e devono essere verificati per integrità, latenza e pRESTazioni.

Raccomandazioni hardware per il repository

Per repository con elevato carico di RESTore o di scrittura, backend basati su SSD sono vantaggiosi, in quanto molte operazioni di I/O di piccole dimensioni vengono servite in modo più efficiente. Per la sola archiviazione a lungo termine si possono utilizzare array HDD a basso costo con RAID/erasure coding adeguato, purché si prevedano test di ripristino e larghezza di banda sufficiente.

Strategie di retention, pianificazione del prune e impatti

La retention deve bilanciare i punti di ripristino (RPO) con i costi di storage. Praticamente collaudato:

• Conservazione a breve termine: snapshot giornalieri (es. 7 giorni)
• A medio termine: snapshot settimanali e mensili
• A lungo termine: archivi annuali per conformità

# Prune dry-run zur Überprüfung
borg prune -v --list $BORG_REPO --keep-daily=7 --keep-weekly=4 --keep-monthly=6 --keep-yearly=1 --dry-run

Il prune elimina solo gli archivi; tramite deduplicazione i Chunks vengono cancellati fisicamente non appena non sono più referenziati da alcun archivio rimanente. Eseguite dry-run regolari e documentate quali punti di ripristino sono andati persi per garantire la conformità agli SLA.

Controlli automatizzati di ripristino e workflow di validazione

Un backup è valido quanto il suo ripristino. Due livelli di verifica sono adeguati:

1. Integrità del repository: borg check --repository-only regolarmente; periodicamente borg check --verify-data durante finestre di manutenzione, poiché quest’ultimo è intensivo in I/O.
2. Test di ripristino funzionale: estrarre artefatti critici (es. configurazioni, DB-Dumps) in un ambiente di test e validarli con checksum, test di importazione DB o avvio dei servizi in un ambiente isolato.

# RESTore-Validierung: Beispiel für nginx-Konfiguration
set -euo pipefail
TMPDIR=$(mktemp -d /tmp/borg-RESTore-test-XXXX)
trap 'rm -rf "$TMPDIR"' EXIT

ARCHIVE=$(borg list --short $BORG_REPO | tail -n1)

borg extract $BORG_REPO::"$ARCHIVE" etc/nginx/nginx.conf --target "$TMPDIR"
sha256sum "$TMPDIR/etc/nginx/nginx.conf" | awk '{print $1}' > /tmp/RESTore-check-actual
# Vergleichen Sie die resultierende Prüfsumme mit einer erwarteten Prüfsumme

I controlli automatizzati di ripristino dovrebbero generare allarmi basati sui risultati (mail/ChatOps/evento di monitoring) e devono essere eseguiti almeno settimanalmente per gli artefatti critici. Usate host di test o container per l’isolamento, in modo che la validazione non modifichi dati di produzione.

Monitoraggio, parsing degli output e alert

Raccogliete queste metriche per l’osservabilità: ultimo avvio riuscito, durata, dimensione dei dati trasferiti, quantità di byte deduplicati, risultati del prune e codici di uscita di Borg. Scrivete un parser robusto che consideri differenze di testo dipendenti dalla locale.

# Beispiel: sehr simples Parsing (nur Ausgangspunkt)
transferred_bytes=$(grep "Transferred" $LOGFILE | awk '{print $2}')
processed_files=$(grep "Number of files" $LOGFILE | awk -F: '{print $2}' | tr -d ' ')

# Senden an Monitoring (pseudo)
# curl -X POST http://monitoring.example.local/metrics -d "borg_transferred_bytes=$transferred_bytes"

Per ambienti di produzione è consigliabile un exporter o connector dedicato che produca log strutturati (JSON) o invii metriche direttamente a Prometheus/Grafana. Testate il parser con diverse versioni di Borg.

Casi di errore tipici e una rapida sequenza di controllo

In caso di errori di backup segue una sequenza di controllo standardizzata che dovRESTe inserire nel runbook degli incidenti:

1. Verificare la connessione SSH:
   ShellCode kopieren

   ssh -vvv backup-user@backup.example.com

   — mostra errori di chiave e di autenticazione.

2. Verificare lo spazio sul host del repo:
   ShellCode kopieren

   ssh backup@backup.example.com df -h /srv/backup

3. Controllare lo stato del repo:
   ShellCode kopieren

   borg list $BORG_REPO
   borg info $BORG_REPO::ARCHIVNAME

4. Problemi di lock:

borg break-lock $BORG_REPO

— solo dopo analisi e se non è attivo alcun processo Borg.

borg check --repository-only $BORG_REPO

Evitate tentativi di riparazione affrettati come borg check --repair senza aver prima salvato i metadati del repository; documentate ogni passaggio.

Strategia di migrazione e di emergenza

Per migrazioni o emergenze si raccomandano misure chiare:

1. Salvate i metadati del repository e create uno snapshot del filesystem dell’host di backup (ad es. snapshot LVM o ZFS).
2. Eseguite un RESTore di test su un host separato e validate i workload critici.
3. In caso di corruzione del repository: prima borg check --repository-only, documentare, contattare la community o il supporto, quindi pianificare azioni di riparazione mirate.

Tenete pronta una strategia di rollback: se un cambio di versione pianificato di Borg fallisce, dovRESTe poter tornare alla versione precedente di Borg e continuare a lavorare usando uno snapshot del filesystem del repository.

Performance-Tuning & integrazione del filesystem

Ottimizzazioni che si sono dimostrate efficaci nella pratica:

• Livello di compressione: --compression zstd,6 è un buon compromesso tra carico CPU e dimensione; livelli superiori risparmiano più spazio ma aumentano il carico CPU.
• Cache dei file: Borg può utilizzare cache di liste dei file; testate BORG_FILES_CACHE per filesystem molto grandi.
• Snapshot per consistenza: per i database utilizzate snapshot dello storage (LVM, ZFS) o dump consistenti (ad es. pg_dump) prima dell’esecuzione di Borg, poiché Borg è uno strumento a livello di file.

Manutenzione del repository: compact, upgrade e cambio di versione

La manutenzione regolare aiuta a limitare il numero di file di segmento e a mantenere le pRESTazioni. Usate:

# Repository komprimieren/neu packen
borg compact $BORG_REPO

# Vor einem Versionswechsel: Backup aller Repository-Metadaten und Tests in Staging
borg upgrade --help  # prüfen, wenn Versionswechsel nötig ist

Eseguite la manutenzione del repository durante finestre di manutenzione e testate l’effetto sui tempi di RESTore e sul carico I/O.

Checklist delle best practice per il funzionamento

• Controlli di RESTore regolari e automatizzati (es. settimanali per file critici)
• Separazione tra host di backup e host di produzione; hardening SSH per gli utenti di backup
• Documentare la policy di prune; eseguire regolarmente dry-run di prune
• Monitoring basato sui codici di uscita e logging strutturato
• Gestione sicura delle chiavi: backup e rotazione di passphrase/file di chiavi
• Test in staging per aggiornamenti di versione di Borg e manutenzione del repository
• Runbook per incidenti documentati con sequenze di controllo chiare

Conclusione

BorgBackup è una soluzione consolidata per backup automatizzati e deduplicanti, a condizione che la topologia del repository, la sicurezza SSH, la crittografia e la validazione dei RESTore siano pianificate con cura. Essenziali sono controlli di RESTore automatizzati, un processo di prune verificabile e il monitoraggio dei risultati dei job. La deduplicazione riduce in modo significativo il fabbisogno di spazio e larghezza di banda, ma richiede attenzione nella pianificazione delle risorse e nella gestione delle chiavi. Con runbook chiari, test regolari e un workflow di monitoraggio rigoroso si ottiene una strategia di backup solida che supporta in modo affidabile l’operatività e il ripristino.

Se avete bisogno di un piano di implementazione concreto o di un audit per la vostra topologia di backup, da questo si può ricavare un runbook operativo e affidabile che copra sia i requisiti di storage sia quelli di ripristino.

Backup automatizzati con BorgBackup: georedundanza, audit e attributi dei file

Oltre alla pianificazione di routine, dovRESTe considerare esplicitamente tre ambiti pratici: archiviazione georedundante, tracciabilità degli accessi e gestione degli attributi dei file/ACL. Questi punti influenzano direttamente la recuperabilità, la compliance e la incident response.

Georedundanza e pattern di replica

Borg non offre una replica multi‑site integrata. Pattern consolidati sono:

• Push sequenziale: scrivete il backup successivamente in due repository (locale → Remote A → Remote B). Vantaggio: logica semplice; Svantaggio: durata complessiva maggiore.
• Replica a livello di storage: utilizzate ZFS‑Send/Receive, replica a blocchi o replicazione a livello di object‑store al di sotto del file system per generare repliche atomiche. Vantaggio: copie consistenti; Svantaggio: maggiore complessità infrastrutturale.
• Snapshot come punto di trasferimento: generate uno snapshot coerente dello storage (LVM/ZFS) e replicate quello nella sede secondaria, invece di copiare singoli file del repository.

Assicuratevi di integrare lock, controlli di consistenza e pianificazione della banda. La replica senza verifica di integrità può moltiplicare la corruzione.

Audit, controllo degli accessi e tracciabilità

Limitate l’accesso SSH tramite AuthorizedKeys-Command, registrate centralmente tutte le operazioni di Borg (journal/syslog → SIEM) e strumentate l’account di backup con regole di audit (auditd) per eventi su file e processi. In questo modo individuate esportazioni o ripristini non autorizzati e potete ricostruire tempi di accesso e responsabili.

Attributi dei file, ACL e contesti Selinux

Verificate se i vostri backup necessitano di Extended Attributes, POSIX‑ACLs e SELinux‑Kontexte (file di configurazione, directory home). Attivate le opzioni di archivio corrispondenti e validate al RESTore che permessi e contesti vengano preservati; questo è determinante per i riavvii in produzione.

Runbook di emergenza rapido (sintesi)

1. Assicurare la raggiungibilità: indirizzare DNS/LoadBalancer sull’host di RESTore.
2. Controllo rapido: eseguire borg list / borg info sul repository secondario.
3. Verifica di integrità: borg check –repository-only.
4. RESTore di failover: estrarre e validare prima le configurazioni critiche.
5. Audit e documentazione: registrare tutti i passaggi, ruotare le chiavi se compromesse.

Queste misure colmano il divario tra „il backup funziona“ e „in caso di disastro possiamo ripartire in produzione“ e dovrebbero far parte del vostro runbook operativo.

Anche le operazioni di pruning dei backup sono importanti per questo argomento. L’articolo inquadra questi aspetti in modo chiaro e mostra su cosa è importante concentrarsi nella pratica.