Air‑Gapped Backup‑Nodes im Rechenzentrum einrichten: Netzdesign, Hardware und Synchronisation

Air‑Gapped Backup‑Nodes — also Backup‑Server oder Speichersysteme, die physisch oder logisch vom Produktionsnetz isoliert sind — sind eine bewährte Maßnahme, um Ransomware, lateral movement und Netzwerkkompromittierung entgegenzuwirken. Dieses Praxispapier beschreibt, wie Sie solche Nodes im Rechenzentrum planen, welche Hardware und Netztopologien sinnvoll sind, wie sichere Synchronisation technisch realisiert wird und welche Besonderheiten bei MySQL‑Datenbanken zu beachten sind. Zielgruppe: Administratoren, System Engineers, Operatoren und technische IT‑Dienstleister.

Warum Air‑Gapped Backup‑Nodes? Risiken und Betriebsziele

Ein Air‑Gap bedeutet, dass ein System keinen routinemäßigen Netzwerkpfad zum Produktionsnetz hat. In der Backup‑Praxis sind das zwei Varianten: eine physische Trennung (kein Netzwerkkabel, Medienwechsel) oder eine logische Einweg‑Übertragung (Hardware‑Data‑Diode oder streng kontrollierte Transferfenster). Ziel ist, die Angriffsfläche zu reduzieren und einen letzten sauberen Datensatz zu haben, den Malware im Produktionsnetz nicht erreichen kann.

Wichtig ist die klare Betriebszieldefinition: Geht es um Recovery Time Objective (RTO), Recovery Point Objective (RPO), Compliance oder forensische Integrität? Air‑Gaps helfen vor allem bei Integrität und Compliance, verschlechtern aber in der Regel RTO/RPO im Vergleich zu Online‑Repliken.

Grundvoraussetzungen und Projekt‑Checkliste

Vor dem Design sollten Sie organisatorische und technische Voraussetzungen prüfen. Folgende Minimalpunkte gehören auf die Checkliste:

• Recovery‑Ziele (RTO/RPO) und Aufbewahrungsfristen definieren.
• Welche Daten sind schützenswert? (Produktionsdatenbanken, Konfigurations‑Backups, Zertifikate)
• Budget für Hardware, Medienrotation und ggf. Data‑Diode‑Appliances.
• Operative Prozesse: Wer physisch Medien anstöpselt, wer signiert/prüft Manifeste?
• Testplan für regelmäßige Restore‑Übungen.

Netzdesign: Topologien für Air‑Gapped Backup‑Nodes

Es gibt drei praxisnahe Topologien:

1) Physisch isolierte Nodes mit Medienwechsel

Backup‑Server sind im RZ lokal installiert, haben aber kein permanentes L2/L3‑Routing zum Produktivnetz. Daten werden per Wechselmedium (verschlüsselte HDDs, LTO‑Tapes) offline transferiert. Vorteil: sehr hohe Isolation. Nachteil: manuelle Prozesse, längere RTO.

2) Logische Einwegübertragung mit Data Diode oder unidirektionalem Appliance

Hardware‑Data‑Diode ist ein Gerät, das physisch nur Daten in eine Richtung durchlässt (einfacher: optisch). Alternativ lassen sich Router/ACLs so konfigurieren, dass Verbindungen nur in ein Subnetz initiiert werden dürfen. Vorteil: automatisierbare Transfers, reduzierter manueller Aufwand. Einschränkung: höhere Kosten, Abhängigkeit von Appliance‑Hersteller und deren Firmware‑Sicherheit.

3) Zeitweise verbundene, stark kontrollierte Nodes (Transferfenster)

Der Air‑Gap wird nur temporär geöffnet: Netzwerk‑Kabel wird physisch verbunden oder Firewall‑Regeln werden für ein definiertes Fenster geändert. Transfers laufen verschlüsselt, es folgen sofortige Re‑Isolation und Signaturprüfungen. Geeignet, wenn Automatisierung ohne Data‑Diode erforderlich ist. Risiko: menschliche Fehler beim Re‑Isolieren.

Planung von Netzwerksegmenten und Firewalls

Definieren Sie mindestens drei Segmente: Produktionsnetz, Transfer‑DMZ (wenn vorhanden) und Air‑Gapped‑Zone. Verwenden Sie klare ACLs (Access Control Lists), VLANs (Virtual LANs) und physische Trennung der Switchports. Eine einfache Regel ist: keine eingehenden Verbindungen von Produktionsnetz in die Air‑Gapped‑Zone. Testen Sie Regeln mit Netcat bzw. tcpdump vor dem Produktivbetrieb.

Hardware: Server, Storage und Medienauswahl

Hardwareentscheidungen beeinflussen Verfügbarkeit, Integrität und Betriebskosten. Auswahlkriterien:

• Formfaktor: 1U/2U Server oder dedizierte Tape‑Library je nach Volumen.
• Storage‑Typ: HDD‑based Archive (billig, hohe Kapazität), SSD (für schnellen Restore‑Test), LTO‑Tape (langlebig, offline‑freundlich).
• Redundanz: Für Air‑Gapped‑Nodes ist RAID oft ausreichend; bei Tape setzen Sie auf Medienrotation und Offsite‑Kopien.
• Verschlüsselung: Hardware‑Encryption auf Medien oder hostseitige Verschlüsselung vor Transfer.

Achten Sie auf nachvollziehbare Medienkennzeichnung und sichere Lagerung: Zugangskontrollen, CCTV‑Logs und Signaturen.

Synchronisation: Verfahren, Werkzeuge und Integritätsprinzipien

Die zentrale Frage ist: Wie kommen Daten zuverlässig und überprüfbar in die isolierte Node? Gängige Methoden mit Vor‑ und Nachteilen:

• rsync / rclone über Einweg‑Link: flexibel, feingranular, unterstützt Checksums. Braucht Netzverbindung (oder Data Diode).
• Blockbasierte Replikation (ZFS send/receive, btrfs send): effizient für große Datenmengen mit Snapshot‑Konsistenz.
• Physische Medienrotation (scp/physische HDD, LTO‑Tape): sehr isoliert, aber langsam und manuell.
• Percona XtraBackup / MySQL konsistente Backups: für MySQL‑Dumps und inkrementelle Backups notwendig (siehe MySQL‑Abschnitt unten).

Beispiel: rsync über kontrolliertes Fenster

rsync ist praxiserprobt für Dateisynchronisation. Wichtig: nutzen Sie Checksummen und erzeugen Sie ein manifest mit sha256 für jede Transfercharge.

# Auf der Produktionsseite: Backup vorbereiten und Manifest erstellen
rsync -aH --delete /var/lib/appdata/ /staging/backupdir/
find /staging/backupdir -type f -print0 | xargs -0 sha256sum > /staging/backupdir/manifest.sha256
gpg --detach-sign --armor /staging/backupdir/manifest.sha256

Nach Transfer in die Air‑Gapped‑Zone verifizieren Sie die Checksummen und die GPG‑Signatur.

# Auf Air-Gapped-Node: Integritätsprüfung
gpg --verify manifest.sha256.asc manifest.sha256
sha256sum -c manifest.sha256

Signaturen und unveränderliche Manifeste

Signieren Sie Manifeste immer mit einem Offline‑Schlüssel oder einem Key, dessen Geheimteil nicht im Produktionsnetz liegt. Das verhindert, dass ein Angreifer Manifeste in der Transferkette manipuliert.

MySQL‑Spezifika: Konsistenz, Tools und typische Stolperfallen

MySQL (inkl. MariaDB) stellt besondere Anforderungen: Sie brauchen konsistente Datenbank‑Backups, die beim Restore Anwendungskonsistenz gewährleisten. Wichtige Konzepte: Binlog‑Positionen (binlog = Write‑Ahead‑Log), GTID (Global Transaction ID) für replizierbare Positionierung, und quiesce‑Methoden (LVM‑Snapshot oder Lock‑Strategien).

Option A: Percona XtraBackup (empfohlen für große InnoDB‑Datenbanken)

Percona XtraBackup ermöglicht inkrementelle, nicht‑blockierende Backups von InnoDB‑Datenbanken. Ablauf: XtraBackup erstellt Dateikopie + Transaction Log (redo) und liefert einen Konsistenzpunkt, der vor Restore mit xtrabackup –prepare bereitgestellt wird.

# Volles Backup mit xtrabackup
xtrabackup --backup --target-dir=/backup/xtrabackup/full --datadir=/var/lib/mysql --user=xbackup --password='secret'
# Inkrementelles Backup
xtrabackup --backup --incremental --target-dir=/backup/xtrabackup/inc1 --incremental-basedir=/backup/xtrabackup/full

Typische Fehler: unvollständige Preparation, fehlende binlog‑/GTID‑Metadaten oder vergessene Berechtigungen beim Kopieren von InnoDB‑Systemdateien. Testen Sie Restore‑Prozeduren regelmäßig in einer isolierten Testumgebung.

Option B: mysqldump / Logical Backups

mysqldump ist einfach und portabel, erzeugt aber große Dumps und kann bei sehr großen DBs problematisch für RTO sein. Für InnoDB sollten Sie –single‑transaction verwenden, das eine konsistente Snapshot‑Lesbarkeit (ohne Locks) ermöglicht, solange keine DDL‑Operationen laufen.

# Konsistenter mysqldump für InnoDB
mysqldump --single-transaction --routines --events --triggers --databases appdb > appdb.sql
# Binlog-Position abfragen
mysql -e "SHOW MASTER STATUSG"

Achten Sie bei mysqldump auf binlog‑Positionen oder GTIDs, damit Sie nach Restore Point‑in‑Time‑Recovery (PITR) durchführen können.

Prüfschritte und Restore‑Übungen für MySQL

• Restore‑Prozedur dokumentieren und ein Mal pro Quartal testen.
• Nach Restore prüfen: Tabellenanzahl, Checksummen (pt-table-checksum oder vergleichbare Tools), Anwendungssmoke‑Tests.
• Kontrollieren Sie Benutzerrechte, Binlog‑Zustand und Replikationskonfiguration nach Restore.

Konkrete Restore‑Schritte für XtraBackup

Ein typischer Restore‑Weg nach Übertragung ins Air‑Gapped‑System:

# Vorbereitung des Backups
xtrabackup --prepare --target-dir=/backup/xtrabackup/full
# Stoppen des MySQL-Dienstes
systemctl stop mysql
# Kopieren in datadir (Achtung: Dateirechte)
rsync -aH /backup/xtrabackup/full/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
# MySQL starten
systemctl start mysql

Wenn –prepare fehlschlägt, prüfen Sie die Logdateien von xtrabackup auf fehlende redo‑Logs oder inkrementelle Abhängigkeiten.

Betrieb: Runbooks, Transferprozeduren und Automatisierung

Gute Runbooks sind das Herz des Betriebs. Ein Transfer‑Runbook beschreibt detailliert:

1. Vorbedingungen: verfügbare Medien, Signaturschlüssel, Verantwortliche.
2. Schritt für Schritt: Backup starten, Manifest erstellen, Signieren, Transfer starten, Post‑Transfer‑Prüfungen, Re‑Isolierung.
3. Monitoring und Logging: syslog/central logs, Audit‑Eintrag wer wann Medien angeschlossen hat.
4. Fallback: Was wenn Manifest fehlschlägt? (z. B. Transfer neu starten oder vorherige medienbasierte Kopie verwenden).

Automatisierungsbeispiel: kontrolliertes Transferfenster

Automatisieren Sie das Öffnen/Schließen von Firewall‑Regeln per API oder Konfigurationsmanagement (Ansible/Chef). Führen Sie vor dem Öffnen automatische Preflight‑Checks aus (Integritätscheck, Quota‑Prüfung).

Integrität, Signaturen und Auditing

Integrität ist auf drei Ebenen zu sichern: Dateiintegrität (Checksums), Transferintegrität (TLS, Data‑Diode), und Authentizität (GPG‑Signaturen). Zusätzlich sollten Sie Audit‑Logs erstellen, die physische Medienbewegungen und Benutzeraktionen nachweisen.

# Manifest erstellen und signieren (Beispiel)
find /backupdir -type f -print0 | xargs -0 sha256sum > manifest.sha256
gpg --default-key backup-admin --detach-sign --armor manifest.sha256

Monitoring, Alerting und automatische Sanity‑Checks

Beobachten Sie folgende Metriken: letzte erfolgreiche Transferzeit, Anzahl geprüfter Dateien, Ergebnis der sha256 Prüfung, verfügbare Medienkapazität. Integrieren Sie Alarme (z. B. per Prometheus Alertmanager oder RZ‑Monitoring) für fehlende Transfers oder fehlerhafte Manifeste.

Beispiel: einfacher Healthcheck‑Script für Air‑Gapped‑Node

Dieses Script fasst Integritätsprüfung und Dateizählung zusammen und liefert Exit‑Codes für Monitoring‑Systeme.

#!/bin/bash
MANIFEST=/var/airgap/manifest.sha256
MANIFESTSIG=/var/airgap/manifest.sha256.asc
BACKUPDIR=/var/airgap/data
# Signatur prüfen
if ! gpg --verify "$MANIFESTSIG" "$MANIFEST" >/dev/null 2>&1; then
  echo "GPG verification failed" >&2
  exit 2
fi
# Checksums prüfen
if ! sha256sum -c "$MANIFEST" >/dev/null 2>&1; then
  echo "Checksum mismatch" >&2
  exit 2
fi
# Dateizahl prüfen
FILECOUNT=$(find "$BACKUPDIR" -type f | wc -l)
if [ "$FILECOUNT" -lt 10 ]; then
  echo "Too few files: $FILECOUNT" >&2
  exit 2
fi
echo "OK: $FILECOUNT files verified"
exit 0

Typische Stolperfallen und wie Sie sie vermeiden

• Vertrauen auf eine einzige Methode: Kombinieren Sie Checksums + Signaturen + physische Auditierung.
• Menschliche Fehler beim Re‑Isolieren: Automatisieren Sie Re‑Isolation wo möglich oder verlangen Sie Zwei‑Augen‑Prinzip.
• Fehlende Restore‑Tests: Ohne regelmäßige Tests wissen Sie nicht, ob Backups wirklich nutzbar sind.
• Key‑Management: Private Keys niemals in produktiven Systemen halten; nutzen Sie Offline‑HSM oder separate Air‑Gapped‑Keys.
• Unzureichende Dokumentation: Runbooks und Verantwortlichkeiten müssen aktuell und zugreifbar sein.

Kapazitätsplanung, Durchsatz und Performance‑Aspekte

Planen Sie Kapazität nicht nur nach aktuellem Volumen, sondern nach Restore‑Fenstern und Wachstum. Faktoren, die RTO beeinflussen:

• Schreibdurchsatz der Quelle (Backup‑Job‑Dauer)
• Transferdurchsatz (Netzwerk oder Tape‑Streaming‑Rate)
• Restore‑I/O im Ziel (wie schnell können Daten wiederhergestellt werden)

Beispiel: Eine Data‑Diode mit 1 Gbit/s hat theoretisch ~125 MB/s. Nach Overhead, Protokoll und Verschlüsselung rechnen Sie realistisch mit 80–90 MB/s bei guten Bedingungen. Für mehrere Terabyte bedeutet das viele Stunden; dokumentieren Sie diese Zeitfenster in Ihrem Runbook.

Deduplication, Kompression und Storage‑Strategien

Deduplizierung und Kompression reduzieren Datenvolumen, können aber Restore‑Pfad und Kompatibilität beeinflussen. Deduped‑Stores erfordern in der Regel spezialisierte Restore‑Tools; im Air‑Gapped‑Kontext bevorzugen viele Teams einfache, portable Formate (tar, compressed streams) für langfristige Aufbewahrung. Wenn Sie Dedupe nutzen, testen Sie unbedingt komplette Wiederherstellungen aus deduplizierten Stores.

Schlüsselverwaltung, HSM und forensische Anforderungen

Für Signaturen und Verschlüsselung sollten Secrets niemals im Online‑Produktivnetz liegen. Optionen:

• Offline‑GPG‑Keys auf einem Air‑Gapped‑Laptop
• HSM (Hardware Security Module) oder Cloud‑HSM mit Zugriffsbeschränkungen
• Smartcard/Token‑basierte Zwei‑Personen‑Freigabe für kritische Signaturen

Dokumentieren Sie Key‑Rotation, Aufbewahrung und Schlüsselzugriffsprotokolle. Bei forensischer Beweissicherung ist eine nachvollziehbare Chain‑of‑Custody essenziell: wer hat welches Medium wann verschoben und geprüft.

Praktische Troubleshooting‑Checkliste

Wenn ein Transfer fehlschlägt oder die Manifestprüfung Fehler liefert, folgen Sie systematisch:

1. Prüfen Sie Logdateien (rsync/xtrabackup/gpg/syslog).
2. Vergleichen Sie Dateianzahl und Gesamtgröße zwischen Quelle und Ziel.
3. Prüfen Sie GPG‑Keyfingerprints gegen eine vertrauenswürdige Liste.
4. Falls –prepare bei XtraBackup scheitert: prüfen Sie, ob alle erforderlichen redo‑Logs vorhanden sind und ob inkrementelle Backups korrekt verknüpft wurden.
5. Wenn Medien fehlerhaft: versuchen Sie bitweise Kopie (dd) und Analyse der fehlerhaften Sektoren; katalogisieren Sie das fehlerhafte Medium für Audits.

Migration und schrittweiser Aufbau

Ein kompletter Umstieg auf Air‑Gapped‑Nodes ist operativ aufwändig. Empfohlener schrittweiser Pfad:

1. Pilot mit geringer Datenmenge (Konfigurationsdaten, weniger kritische Datenbanken).
2. Automatisieren der Manifest‑Erstellung und Signierung.
3. Einführung eines Healthcheck‑Monitors und vierteljährlicher Restore‑Drills.
4. Skalierung auf größere Volumen und Nachjustierung der RTO/RPO‑Ziele.

Abschließendes Fazit

Air‑Gapped Backup‑Nodes sind ein wirkungsvolles Element in einer ganzheitlichen Backup‑Strategie, speziell wenn Integrität und Manipulationsschutz Priorität haben. Sie erfordern jedoch Disziplin in Prozessen, solide Key‑ und Medienverwaltung sowie regelmäßige Restore‑Tests. Technisch bieten Data‑Diodes, kontrollierte Transferfenster und physische Medienrotation unterschiedliche Kompromisse zwischen Automatisierung, Kosten und Isolation — wählen Sie die Variante, die zu Ihren RTO/RPO‑Zielen und Ihrem Betriebsteam passt.

Konzentrieren Sie sich operational auf überprüfbare Manifeste, offline verwaltete Signaturschlüssel, dokumentierte Runbooks und regelmäßige Restore‑Proben. So vermeiden Sie die häufigsten Stolperfallen und stellen sicher, dass Ihre Air‑Gapped Backup‑Nodes im Ernstfall verlässlich reagieren.

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