Automatisierte Backups mit BorgBackup: Deduplizierung, Remote-Storage und Restore-Checks

In diesem Beitrag erkläre ich, wie Sie Automatisierte Backups mit BorgBackup technisch belastbar aufsetzen: von Repository-Architektur und deduplizierender Speicherung über Remote-Transport bis zu automatisierten Restore-Checks, Prune-Strategien und typischen Troubleshooting-Schritten. Ziel sind betriebssichere Abläufe für Administratoren, System Engineers und Betreiber, die Verfügbarkeit, Integrität und Wartbarkeit in den Vordergrund stellen.

Warum BorgBackup? Ein knapper Architekturüberblick

BorgBackup (kurz: Borg) ist ein Datei-Level-Backup-Tool, das inhaltsabhängige Deduplizierung, optionale Ende-zu-Ende-Verschlüsselung und effizientes Transferieren via SSH bietet. Deduplizierung bedeutet, dass identische Datenabschnitte (Chunks) nur einmal im Repository gespeichert werden; das reduziert Speicherplatz bei wiederholten Backups stark. Borg speichert Backups in einem Repository, das lokal auf einem Server liegen oder per SSH mit borg serve angesprochen werden kann. Die Repository-Topologie ist zentral für Performance, Locking und Wartung, deshalb sollte sie früh geplant werden.

Automatisierte Backups mit BorgBackup: Architektur und Betriebsregeln

Für einen produktiven Betrieb sind mehrere Aspekte verbindlich:

• Mandanten- oder Service-Trennung: Legen Sie pro Mandant oder kritischem Service ein eigenes Repository an, wenn Aufbewahrungsregeln oder Zugriffskontrolle unterschiedlich sind.
• Versionskompatibilität: Halten Sie Client- und Server-Borg-Versionen synchron; testen Sie Versionswechsel in Staging-Umgebungen bevor Sie diese in Produktion bringen.
• SSH-Sicherheit: Nutzen Sie key-basierte Authentifizierung, ein dediziertes Backup-Konto (z. B. backup-user) und AuthorizedKeys-Command-Restriction, um den SSH-Zugang auf borg serve zu beschränken.
• Ressourcenplanung: Initiale Backups sind CPU- und I/O-intensiv; rechnen Sie mit erhöhtem RAM-/CPU-Bedarf auf Clients und ggf. Spitzenlasten auf dem Repository-Host.

Repository initialisieren, Verschlüsselungsstrategien und Schlüsselmanagement

Borg unterstützt Verschlüsselungsmodi wie repokey (Schlüssel im Repository, durch Passphrase geschützt) und keyfile (privater Schlüssel extern). Repokey ist betrieblich einfacher, während Keyfile strengere Schlüsselverwaltung ermöglicht, weil der private Schlüssel getrennt aufbewahrt wird. Schlüsselverlust bei verschlüsselten Repositories bedeutet meist dauerhaften Datenverlust – planen Sie daher Key-Rotation-, Backup- und Aufbewahrungsprozesse.

# 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"

Ein sicherer AuthorizedKeys-Eintrag mit Einschränkung verhindert interaktiven Shell-Zugriff und erlaubt nur Borg-Operationen für das angegebene Repository:

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

Verwalten Sie SSH-Keys und Passphrasen in einem dedizierten Secrets‑Store (z. B. HashiCorp Vault) und sichern Sie Schlüssel nach definierten Policies an einem separaten, offline verfügbaren Ort. Dokumentation und regelmäßige Key-Rotation sind betriebsentscheidend.

Praktischer Backup-Workflow und robustes Skripting

Backups sollten idempotent, atomar und gut geloggt ausgeführt werden. Verwenden Sie ein Wrapper-Skript mit set -euo pipefail, Locking (z. B. flock), strukturierter Ausgabe für Monitoring-Parsing und Exit-Code-Handling.

#!/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"

Führen Sie dieses Skript über systemd-timer aus, nicht über Cron, um besseres Startverhalten, automatische Retry-Policies und nativen Logging-Anschluss an journalctl zu erhalten.

Beispiel: systemd-Service und 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

Setzen Sie Nice und CPU‑Affinity, falls nötig, um Backup‑Jobs gegenüber produktiven Diensten zu entlasten.

Deduplizierung: Wirkungsweise und Betriebsfolgen

Borg verwendet content-defined chunking: Daten werden in variable Blöcke zerlegt, die mittels Kryptohash identifiziert werden. Deduplizierung spart Platz, hat aber Implikationen:

• Deduplication ist repository-weit: Einsparung erfolgt nur innerhalb desselben Repositories, nicht zwischen Repos.
• Chunking erzeugt CPU- und manchmal RAM-Last; Clients mit vielen kleinen Dateien profitieren besonders, doch die Chunk-Erstellung belastet Ressourcen.
• Beim Restore großer Datenmengen entstehen viele kleine Reads; planen Sie I/O-Profile und testen Sie Wiederherstellungsfenster.

Remote-Storage-Optionen: Bewertung und Empfehlungen

SSH-Repository (borg serve) ist die empfohlene Option: getestete Codepfade, korrektes Lock-Handling und geringe Komplexität. Alternative Backends bringen Risiken:

• NFS/SMB: können Locking- und Konsistenzprobleme verursachen und Repository-Korruption begünstigen; gemountete Netzwerkdateisysteme sind daher nicht empfohlen.
• Objektspeicher (z. B. S3): Borg unterstützt S3 nicht nativ; Gateways (SFTP- oder Filesystem-Bridges) sind möglich, erhöhen aber Komplexität und müssen auf Integrität, Latenz und Performance geprüft werden.

Hardware-Empfehlungen für das Repository

Für Repositories mit hoher Restore- oder Schreiblast sind SSD-basierte Backends vorteilhaft, da viele kleine I/Os effizienter bedient werden. Für reine Langzeit-Archivierung können kostengünstige HDD-Arrays mit geeignetem RAID/Erasure-Coding genutzt werden, solange Sie Restore-Tests und ausreichende Bandbreite berücksichtigen.

Retention-Strategien, Prune-Planung und Auswirkungen

Retention soll Wiederherstellungszeitpunkte (RPO) mit Storage-Kosten abwägen. Praktisch bewährt:

• Kurzfristige Aufbewahrung: tägliche Snapshots (z. B. 7 Tage)
• Mittelfristig: wöchentliche und monatliche Snapshots
• Langfristig: Jahresarchive zur Compliance

# 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

Prune entfernt nur Archive; durch Deduplizierung werden Chunks physisch gelöscht, sobald sie von keinem verbleibenden Archiv mehr referenziert werden. Führen Sie regelmäßige Dry-Runs durch und dokumentieren Sie, welche Restore-Punkte verloren gingen, um SLA-Konformität sicherzustellen.

Automatisierte Restore-Checks und Validierungs-Workflows

Ein Backup ist nur so gut wie sein Restore. Zwei Prüf-Ebenen sind praxisgerecht:

1. Repository-Integrität: borg check --repository-only regelmäßig; periodisch borg check --verify-data in Wartungsfenstern, da letzteres IO-intensiv ist.
2. Funktionaler Restore-Test: Extrahieren kritischer Artefakte (z. B. Konfigurationen, DB-Dumps) in eine Testumgebung und validieren mit Checksummen, DB-Import-Tests oder Start von Services in isolierter Umgebung.

# 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

Automatisierte Restore-Checks sollten ergebnisorientiert alarmieren (Mail/ChatOps/Monitoring-Event) und mindestens wöchentlich für kritische Artefakte laufen. Verwenden Sie Test-Hosts oder Container zur Isolation, damit Validierung keine Produktionsdaten verändert.

Monitoring, Parsing von Outputs und Alerts

Sammeln Sie diese Metriken für Observability: letzte erfolgreiche Laufzeit, Dauer, Größe der übertragenen Daten, Anzahl deduplizierter Bytes, Prune-Ergebnisse und Borg-Exit-Codes. Schreiben Sie einen robusten Parser, der Locale-abhängige Textunterschiede berücksichtigt.

# 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"

Für Produktionsumgebungen empfiehlt sich ein dedizierter Exporter oder Connector, der strukturierte Logs (JSON) erzeugt oder Metriken direkt an Prometheus/Grafana schickt. Testen Sie den Parser bei verschiedenen Borg-Versionen.

Typische Fehlerfälle und eine schnelle Prüfsequenz

Bei Backup-Fehlern folgt eine standardisierte Prüfsequenz, die Sie ins Incident-Runbook schreiben sollten:

1. SSH-Verbindung prüfen:
   ShellCode kopieren

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

   — zeigt Key- und Auth-Fehler.

2. Platz prüfen auf dem Repo-Host:
   ShellCode kopieren

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

3. Repo-Status prüfen:
   ShellCode kopieren

   borg list $BORG_REPO
   borg info $BORG_REPO::ARCHIVNAME

4. Lock-Probleme:
   ShellCode kopieren

   borg break-lock $BORG_REPO

   — nur nach Analyse und wenn kein Borg-Prozess aktiv ist.

5. Integrität:
   ShellCode kopieren

   borg check --repository-only $BORG_REPO

Vermeiden Sie voreilige Reparaturversuche wie borg check --repair ohne vorherige Sicherung der Repository-Metadaten; dokumentieren Sie jeden Schritt.

Migrations- und Notfallstrategie

Für Migrationen oder Notfälle empfehlen sich klare Maßnahmen:

1. Sichern Sie Repository-Metadaten und erstellen Sie ein Dateisystem-Snapshot des Backup-Hosts (z. B. LVM oder ZFS-Snapshot).
2. Führen Sie einen Test-Restore auf separatem Host durch und validieren Sie kritische Workloads.
3. Bei Repository-Korruption: zuerst borg check --repository-only, dokumentieren, Community oder Support kontaktieren, dann gezielte Reparaturaktionen planen.

Halten Sie eine Rückfallstrategie bereit: falls ein geplanter Versionswechsel von Borg fehlschlägt, sollten Sie die Möglichkeit haben, auf die vorherige Borg-Version zurückzurollen und mit einem Snapshot des Repository-Dateisystems weiterzuarbeiten.

Performance-Tuning & Dateisystem-Integration

Optimierungen, die sich in der Praxis bewährt haben:

• Compression-Level: --compression zstd,6 ist ein guter Kompromiss zwischen CPU-Last und Größe; höhere Levels sparen mehr Platz, kosten aber CPU.
• Files-Cache: Borg kann Dateiliste-Caches verwenden; testen Sie BORG_FILES_CACHE für sehr große Dateisysteme.
• Snapshots für Konsistenz: Für Datenbanken verwenden Sie Storage‑Snapshots (LVM, ZFS) oder konsistente Dumps (z. B. pg_dump) vor dem Borg-Lauf, da Borg ein Datei-Level-Tool ist.

Repository-Wartung: compact, upgrade und Versionswechsel

Regelmäßige Wartung hilft, die Anzahl der Segmentdateien zu begrenzen und Performance zu erhalten. Nutzen Sie:

# 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

Führen Sie Repository-Wartung in Wartungsfenstern durch und testen Sie den Effekt auf Restore-Dauer und I/O-Last.

Best-Practices-Checkliste für den Betrieb

• Regelmäßige, automatisierte Restore-Checks (z. B. wöchentlich für kritische Dateien)
• Separation von Backup- und Produktiv-Hosts; SSH-Hardening für Backup-User
• Prune-Policy dokumentieren; Prune-Dry-Runs regelmäßig durchführen
• Monitoring auf Exit-Code-Basis und strukturiertes Logging
• Sicheres Key-Management: Backup und Rotation von Passphrasen/Keyfiles
• Staging-Tests für Borg-Versionsupdates und Repository-Maintenance
• Dokumentierte Incident-Runbooks mit klaren Prüfsequenzen

Fazit

BorgBackup ist für automatisierte, deduplizierende Backups eine bewährte Lösung, wenn Repository-Topologie, SSH-Sicherheit, Verschlüsselung und Restore-Validierung sauber geplant werden. Entscheidend sind automatisierte Restore-Checks, ein prüfbarer Prune-Prozess und Monitoring der Job-Ergebnisse. Die Deduplizierung reduziert Speicher- und Bandbreitenbedarf erheblich, erfordert aber Sorgfalt bei Ressourcenplanung und Schlüsselverwaltung. Mit klaren Runbooks, regelmäßigen Tests und einem strikten Monitoring-Workflow erreichen Sie eine belastbare Backup-Strategie, die Betrieb und Wiederherstellung zuverlässig unterstützt.

Wenn Sie einen konkreten Implementierungsplan oder ein Audit für Ihre Backup-Topologie benötigen, lässt sich daraus ein betriebssicheres Runbook ableiten, das sowohl Storage- als auch Wiederherstellungsanforderungen abdeckt.

Automatisierte Backups mit BorgBackup: Georedundanz, Audit und Dateiattribute

Ergänzend zur Routineplanung sollten Sie drei praxisrelevante Bereiche ausdrücklich berücksichtigen: georedundante Ablage, Nachvollziehbarkeit von Zugriffen und die Behandlung von Dateiattributen/ACLs. Diese Punkte wirken sich direkt auf Wiederherstellbarkeit, Compliance und Incident-Response aus.

Georedundanz und Replikations-Patterns

Borg bietet kein eingebautes Multi‑Site-Replication. Bewährte Muster sind:

• Sequenzielles Pushen: Schreiben Sie das Backup nacheinander in zwei Repositories (lokal → Remote A → Remote B). Vorteil: einfache Logik, Nachteil: längere Gesamtdauer.
• Storage‑Level‑Replikation: Verwenden Sie ZFS‑Send/Receive, Block‑Replication oder object‑store‑Replikation unterhalb des Dateisystems, um atomare Replikate zu erzeugen. Vorteil: konsistente Kopien, Nachteil: höhere Infrastrukturkomplexität.
• Snapshots als Transferpunkt: Erzeugen Sie ein konsistentes Speicher-Snapshot (LVM/ZFS) und replizieren dieses in die Sekundärsite, statt einzelne Repository-Dateien zu kopieren.

Achten Sie darauf, Locks, Consistency-Checks und Bandbreitenplanung einzubauen. Replikation ohne Integritätsprüfung kann Korruption multiplizieren.

Audit, Zugriffskontrolle und Nachvollziehbarkeit

Beschränken Sie SSH‑Zugriff per AuthorizedKeys-Command, loggen Sie alle Borg-Operationen zentral (journal/syslog → SIEM) und instrumentieren Sie den Backup‑Account mit Audit‑Rules (auditd) für file‑ und process‑events. So erkennen Sie unautorisierte Exporte oder Wiederherstellungen und können Zugriffszeiten sowie Verantwortliche rekonstruieren.

Dateiattribute, ACLs und Selinux-Kontexte

Prüfen Sie, ob Ihre Backups Extended Attributes, POSIX‑ACLs und SELinux‑Kontexte benötigen (Konfigurationsdateien, Home‑Verzeichnisse). Aktivieren Sie die entsprechenden Archiv‑Optionen und validieren Sie bei Restore, dass Rechte und Kontexte erhalten bleiben; das ist entscheidend für produktive Restarts.

Schnelles Notfall‑Runbook (Kurzfassung)

1. Erreichbarkeit sichern: DNS/LoadBalancer auf Restore‑Host umschalten.
2. Schnellcheck: borg list / borg info auf sekundärem Repo ausführen.
3. Integritätsprüfung: borg check –repository-only.
4. Failover‑Restore: kritische Konfigurationen zuerst extrahieren und validieren.
5. Audit & Dokumentation: alle Schritte protokollieren, Keys rotieren falls kompromittiert.

Diese Maßnahmen schließen die Lücke zwischen „Backup läuft“ und „wir können im Desasterfall produktiv wieder starten“ und sollten Teil Ihres operativen Runbooks sein.

Für dieses Thema sind auch Backup-Prune wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.