Notfallwiederherstellung ohne Internet: Lokale Restore‑Pfade, Medien‑Strategien und Checklisten

Einleitung: Warum lokale Restore‑Pfadplanung jetzt zählt

Notfallwiederherstellung ohne Internet — dieses Fokus‑Keyword trifft einen realen Betriebsfall: Cloudzugang, zentrale Authentifizierung oder externe Schlüssel sind nicht verfügbar, während Daten wiederhergestellt werden müssen. Entscheider und Administratoren stehen vor konkreten Fragen: Welche Medien halten auch bei Netzausfall? Wie komme ich an Verschlüsselungsschlüssel ohne KMS‑Zugriff? Wie führe ich einen MariaDB‑Restore lokal und reproduzierbar durch? Dieser Beitrag liefert praxisnahe Restore‑Pfade, Medien‑Strategien, MariaDB‑Howtos, typische Stolperfallen und eine ausführliche Checkliste für Live‑Runs.

Risiken und typische Ursachen für einen Offline‑Restore

Ein Restore ohne Internet tritt selten allein auf; meist ist er Folge eines größeren Incidents. Häufige Auslöser sind:

• Provider‑Ausfall oder regionale Cloud‑Störung — Netzwerk zur Cloud nicht erreichbar.
• Ransomware/Netzwerkisolation — produktive Umgebung bewusst vom Netz getrennt.
• Rechenzentrumsausfall der WAN‑Anbindung — nur lokale Infrastruktur bleibt erreichbar.
• Fehlerhafte PKI/KMS‑Konfiguration mit externen Keys — Schlüssel nicht abrufbar.

Jeder dieser Fälle macht zentral gespeicherte Backups oder cloudbasierte Schlüssel unbrauchbar. Ziel ist deshalb ein getesteter, lokaler Restore‑Pfad (Disk, Tape, offline NAS oder physische Medien) inklusive Offline‑Schlüsselzugang und klaren Runbooks.

Grundprinzipien für Restore‑Pfade ohne Internet

Gute lokale Restore‑Pfade basieren auf fünf Prinzipien:

1. Air‑Gap oder physische Trennung: Backupkopien existieren mindestens einmal auf einem Medium, das nicht permanent mit dem Produktionsnetz verbunden ist (z. B. Band, verschlossene USB‑Archivbox, externe NVMe).
2. Medienvielfalt: Nicht nur ein Medientyp nutzen — Kombination aus schnell verfügbaren lokalen Disks und langfristigen Bandarchiven ist sinnvoll.
3. Sichere, lokale Schlüsselverwaltung: Schlüssel für verschlüsselte Repositories müssen offline verfügbar sein (Hardware‑Token, verschlüsselte Schlüsseldatei in Tresor, dokumentierte Passphrase‑Escalation).
4. Testbare, dokumentierte Runbooks: Schritt‑für‑Schritt‑Anleitungen inklusive Prüfungen und Zeitvorgaben (RTO/Aufgabenverteilung).
5. Verifizierbare Integrität: Checksummen und Signaturen für jedes Backup‑Artefakt, die sich lokal prüfen lassen.

Medienstrategie: Auswahl, Vor‑ und Nachteile

Wählen Sie Medien nicht nach Meinungen, sondern nach Betriebsanforderungen (Datenvolumen, RTO, physische Sicherheit). Hier die gängigen Optionen mit praktischen Hinweisen:

Lokale Disk‑Arrays oder NAS (schnell, aber begrenzt)

Vorteil: Schnelle Wiederherstellung, einfache Automatisierung. Nachteil: Standortrisiko (Brand, Diebstahl). Für Offline‑Recovery empfiehlt sich ein dediziertes, abschließbares Backup‑NAS, das nur periodisch angebunden wird.

Externe NVMe/SSD per USB‑Dublikator (sehr schnell, mobil)

Vorteil: Sehr kurze Restore‑Zeit bei großen Datenmengen. Nachteil: Kosten pro Terabyte, braucht sicheren Transport und klare Inventur.

Bänder (Tape, z. B. LTO) — langfristig, robust, physisch trennbar

Vorteil: Gutes Langzeitarchiv, einfach offline lagerbar. Nachteil: Lesezeit und Hardwareverfügbarkeit. Tipp: Regelmäßige Tape‑Health‑Checks, Tape‑Catalog lokal archivieren (Datei mit Metadaten und Checksummen).

WORM / Write‑Once Medien (rechtliche Anforderungen)

Wenn Revisionssicherheit gefordert ist, sind WORM‑fähige Repositories sinnvoll. Prüfen Sie Kompatibilität mit Ihrer Backup‑Software und planen Sie Offline‑Zugänge zu den Indexdaten.

Air‑Gapped RZ oder Standort (physisch diversifiziert)

Ein zweites, physisch getrenntes Rechenzentrum mit synchronen Kopien ist teuer, bietet aber echten Schutz gegen Standortausfall. Für kleinere Organisationen kann eine lokale, verschlossene Backup‑Box plus Transportstrategie (georedundant) ausreichend sein.

MariaDB‑spezifische Restore‑Strategien

Bei MariaDB (ein relationales Datenbankmanagementsystem, kompatibel zu MySQL) müssen Sie zwischen physikalischen und logischen Backups unterscheiden. Physische Backups kopieren Datenfiles (InnoDB‑Dateien), logische Backups exportieren SQL‑Dumps. Beide haben unterschiedliche Restore‑Pfadforderungen.

Physische Backups: Percona XtraBackup / Dateisystem‑Snapshots

Physische Backups (z. B. Percona XtraBackup oder LVM/Snapshot‑Kopien) sind für große Datenbanken wegen kurzer Wiederherstellungszeiten bevorzugt. XtraBackup erstellt konsistente Kopien der InnoDB‑Datenfiles, ohne den Server offline zu nehmen. Bei Restore ohne Internet gelten folgende Punkte:

• Sichern Sie das vollständige Backup‑Verzeichnis plus Vorbereitungsmeta (xtrabackup_binlog_info) lokal.
• Bewahren Sie Binärlogs (binary logs) lokal auf, damit Point‑in‑Time‑Recovery möglich ist.
• Stellen Sie sicher, dass die Version von XtraBackup und MariaDB auf dem Restore‑Host kompatibel ist.

Beispiel: Vorbereitung und Restore‑Sequenz mit xtrabackup (vereinfacht):

# Backup-Prepare (offline auf Restore-Medium oder temporärem Host)
xtrabackup --prepare --target-dir=/mnt/backup/xb-2026-07-01

# Kopieren der vorbereiteten Daten ins Datenverzeichnis (auf eigenem Restore-Host)
systemctl stop mariadb
rm -rf /var/lib/mysql/*
cp -a /mnt/backup/xb-2026-07-01/* /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
systemctl start mariadb

Warum funktioniert das? XtraBackups „bereitet“ die Dateien so vor, dass InnoDB sie ohne Recovery‑Lauf starten kann. Wann es scheitert: unterschiedliche MariaDB‑Versionen, fehlende ibd‑ oder system‑tablespace‑Dateien oder fehlende Schlüssel bei verschlüsselten Tablespaces.

Logische Backups: mysqldump und schnelle Teilrestores

mysqldump erzeugt SQL‑Statements. Vorteil: einfache Portabilität, Restore auf unterschiedlichen Versionen möglich. Nachteil: Restore bei sehr großen DBs langsam. Empfohlen als Ergänzung für kleinere, kritische Schemas (z. B. Benutzerverwaltung, Konfigurationstabellen).

mysqldump --single-transaction --routines --events --triggers --databases appdb > /media/backup/appdb.sql

# Restore lokal auf Restore-Host
mysql -u root -p < /media/backup/appdb.sql

Point‑in‑Time‑Recovery mit Binärlogs

Binärlogs (binary logs) zeichnen alle Änderungs‑Events auf. Wenn Sie Binärlogs lokal archivieren, können Sie nach einem physischen Restore Änderungen bis zu einem spezifischen Zeitpunkt nachspielen. Beispiel: Anwendung von Binärlogs mit mysqlbinlog:

# Extrahieren relevanter Statements zwischen Zeiten
mysqlbinlog --start-datetime="2026-07-01 09:00:00" --stop-datetime="2026-07-01 12:00:00" /media/backup/mysql-bin.000123 | mysql -u root -p

Wichtig: Achten Sie auf das Binlog‑Format (ROW, STATEMENT, MIXED). ROW‑Format ist bei Replikation/Point‑in‑Time oft zuverlässiger, weil es Datensatzänderungen statt SQL‑Text speichert.

Notfallwiederherstellung ohne Internet: MariaDB‑Praxischeck

Dieser Abschnitt fasst konkrete Prüfungen und Befehle zusammen, die Sie unmittelbar in einem Offline‑Restore‑Szenario brauchen. Ziel: schnell den korrekten Binlog‑Startpunkt finden, Version prüfen und Keys verifizieren.

xtrabackup_binlog_info lesen und anwenden

Die Datei xtrabackup_binlog_info enthält die Binlog‑Datei und die Position, die beim Backup gültig war. So nutzen Sie die Information:

# Beispielinhalt einer xtrabackup_binlog_info-Datei
cat /mnt/backup/xb-2026-07-01/xtrabackup_binlog_info
# Ausgabe z.B.: mysql-bin.000123    456789

# Anwenden: nur die späteren Binlogs wieder einspielen
mysqlbinlog --start-position=456789 /media/backup/mysql-bin.000123 | mysql -u root -p

Warum das hilft: So stellen Sie sicher, dass nach dem physikalischen Restore keine doppelten Transaktionen eingespielt werden. Problemquelle: Wenn Binlogs fehlen oder rotiert wurden, ist eine Nachschau im Tape/NAS‑Katalog nötig.

Version und Plugin‑Check auf Restore‑Host

Ein häufiger Fehler ist Inkompatibilität zwischen MariaDB‑Versionen oder fehlenden Storage‑Engine‑Plugins (z. B. TokuDB, MyRocks). Prüfen Sie lokal:

# MariaDB-Version prüfen
mysql -u root -e "SELECT VERSION();"

# Installierte Storage-Engines prüfen
mysql -u root -e "SHOW ENGINES;"

Fehlt ein Plugin, planen Sie die Installation vor Datenwiederherstellung oder nutzen Sie einen Host mit passender Software‑Umgebung.

Tape‑Restore: Praxis Schritte und Fallstricke

Viele Organisationen verlassen sich auf Tape als Offline‑Archiv. Im Notfall müssen Sie wissen, wie Sie ein Band mounten und Daten extrahieren. Wichtige Aspekte: Tape‑Drive Gerät (/dev/st0), Positionierung (mt), Leseschema (tar, dar, amanda). Beispiel mit tar:

# Band zum Anfang spulen
mt -f /dev/st0 rewind

# Inhaltsliste erstellen (falls tar verwendet wurde)
tar -tvf /dev/st0

# Entpacken auf Zielpfad
tar -xvf /dev/st0 -C /mnt/restore

Stolperfallen: unterschiedliche Blockgrößen beim Schreiben/Lesen, beschädigte Bänder und inkompatible Tape‑Software. Testen Sie Tape‑Restores regelmäßig und führen Sie ein Band‑Inventar mit Prüfphasen.

Schlüsselmanagement offline: Shamir, HSM und Hardware‑Token

Wenn Backups verschlüsselt sind, ist der Zugriff auf Schlüssel der kritische Pfad. Bewährte Optionen:

• Shamir’s Secret Sharing (SSS): Schlüssel in mehrere Teile aufteilen, verteilt auf sichere Tresore. Für Wiederherstellung müssen ausreichende Shares zusammengeführt werden.
• Hardware‑Token (z. B. YubiKey mit PGP/OpenPGP‑Slot) oder Smartcards als offline verfügbare Schlüsselquelle.
• HSM‑Fallback: Wenn primäres HSM ausfällt, sollte ein physisch getrennter Notfall‑HSM vorbereitet und dokumentiert sein.

Wichtig: Testen Sie die gesamte Entschlüsselungs‑Kette in einer isolierten Testumgebung. Eine Schlüsselkopie ohne Zugriffsfähigkeit auf die Entschlüsselungssoftware hilft im Notfall nicht.

Operational: Rollen, Chain of Custody und Inventar

Verantwortlichkeiten müssen klar definiert sein: Wer darf Medien anfordern, wer unterschreibt Übergaben, wer führt Restore‑Operationen aus. Eine einfache Inventar‑CSV erleichtert Nachvollziehbarkeit und Auditierbarkeit.

# Beispielinventar CSV (backup_inventory.csv)
# media_id,media_type,serial,created_at,checksum,checksum_sig,responsible,location
TAPE-20260701-01,tape,LT02-12345,2026-07-01T02:15:00Z,sha256:abcd1234,checksums.sha256.sig,admin-max,tresor-raum-3
NVME-20260701-01,nvme,SN987654,2026-07-01T02:10:00Z,sha256:efgh5678,checksums.sha256.sig,admin-anna,safe-depot

Bei Übergabe dokumentieren: Uhrzeit, IDs, Unterschrift (digital oder physisch) und Zweck. So gelingt später ein Audit- oder Compliance‑Nachweis.

MariaDB Troubleshooting: typische Fehlermeldungen und Gegenmaßnahmen

Ein paar häufige Fehler und konkrete Abhilfen:

• Fehler: „InnoDB: unable to open table space file“ → Ursache: fehlende .ibd oder falsche file‑per‑table Konfiguration. Maßnahme: Prüfen Sie backups auf ibd-Dateien, vergleichen Sie mit .frm/.cfg und importieren Sie Tablespaces falls möglich.
• Fehler: „Table is marked as crashed“ → Ursache: unsauberes Herunterfahren oder Dateisystemfehler. Maßnahme: mysqlcheck oder myisamchk für MyISAM; InnoDB: xtrabackup‑Restore oder innodb_force_recovery zum Extrahieren.
• Fehler: „Binary log not found“ beim Anwenden von mysqlbinlog → Ursache: Binlog rotiert oder fehlt. Maßnahme: Suchen Sie Binlogs auf anderen Medien (Tape/NAS) oder rekonstruieren Sie über Anwendungslayer‑Logs.

Regelmäßige Tests, Dokumentation und Lessons Learned

Praktische Erfahrung zeigt: Jedes erfolgreiche Restore ist das Ergebnis vieler kleiner Vorbereitungen. Führen Sie nach jedem Drill ein Lessons‑Learned‑Protokoll: Welche Schritte dauerten zu lang? Welche Medien waren nicht auffindbar? Haben Schlüssel oder Signaturen gefehlt? Aktualisieren Sie Runbooks entsprechend.

Checkliste: Notfallwiederherstellung ohne Internet (Kurzversion für Einsatzleiter)

1. Verfügbarkeit prüfen: Welche Medien sind physisch zugänglich? (Tape, USB, NAS)
2. Schlüssel abrufen: Wer hat Offline‑Zugriff? Sind Passphrases verfügbar?
3. Restore‑Host bereitstellen: Kompatible MariaDB‑Version, Speicherplatz, Netzwerkisolation.
4. Integritätsprüfung: Checksums validieren.
5. Backup vorbereiten: XtraBackup prepare oder SQL‑Dump bereitstellen.
6. Daten zurückspielen: Dateien kopieren / SQL importieren.
7. Binärlogs anwenden: mysqlbinlog (kontrolliert).
8. Service starten und Logs prüfen: journalctl, mysql‑Errorlog.
9. Smoke‑Tests durchführen: Applikationskritische Pfade prüfen.
10. Dokumentation: Wiedergabe der Schritte, Zeiten und Fehler für Nachbereitung.

Fazit: Praxisorientierte Vorbereitung ist der Schlüssel

Notfallwiederherstellung ohne Internet ist kein theoretisches Szenario: Angesichts Providerausfällen, Ransomware oder regionaler Störung müssen Teams lokal und offline handlungsfähig sein. Entscheidend sind wiederholte Tests, medienübergreifende Strategien, dokumentierte Schlüssel‑Recovery und klare Runbooks für MariaDB‑Restores. Planen Sie Restore‑Pfad, testen Sie ihn unter realistischen Bedingungen, und halten Sie Schlüssel sowie Inventar physisch sicher, aber erreichbar. Nur so wird ein Restore im Ernstfall reproduzierbar und zeitlich planbar.

Weiterdenken: Interne Links und nächste Schritte

Dieser Beitrag ist als betriebliches How‑to gedacht: Ergänzen Sie ihn durch ein konkretes Runbook in Ihrem ITSM, verknüpfen Sie die Checkliste mit Ihren Notfall‑Kommunikationsprozessen und führen Sie ein Ersttest‑Drill im nächsten Wartungsfenster durch. Interne Verlinkungen zu Backup‑Policies, PKI‑Runbooks und Tape‑Inventar bieten sich als nächste Maßnahmen an.

Notfallwiederherstellung ohne Internet: Offline‑Restore‑Umgebung und Integrationsfallen

Ein oft unterschätzter Pfad bei Notfallwiederherstellung ohne Internet ist die Wiederherstellungs‑Umgebung selbst: Server, Pakete, Konfigurations‑Artefakte und Container‑Images müssen offline startbereit sein. Fehlende Paketquellen oder inkompatible Bibliotheken blockieren Restore‑Skripte schneller als fehlende Backups.

Empfohlene Maßnahmen:

• Lokale Paket‑Repos und Container‑Image‑Cache: Spiegeln Sie wichtige Pakete (OS, MariaDB, XtraBackup, libaio) auf einem offline verfügbaren Medium. Prüfen Sie GPG‑Signaturen lokal.
• Version‑Pinning und Build‑Artefakte: Heben Sie exakte Versionen von Datenbank‑Binaries und Storage‑Treibern für Restore‑Hosts auf (inkl. Release‑Notes für Breaking‑Changes).
• Vorkonfigurierte, minimale Restore‑Images: Bereiten Sie ein goldenes, unveränderliches Restore‑Image vor (VM oder Container) mit allen Abhängigkeiten; speichern Sie es als bootfähiges ISO oder qcow2 auf NVMe/Tape.
• Konfigurations‑Inventar und Secrets‑Escrow: Halten Sie konfigurierte my.cnf, systemd‑Units und verschlüsselte Secrets nahe am Backup, mit dokumentiertem Entsperrungsablauf.
• Offline‑Monitoring und Log‑Aggregation: Stellen Sie einfache Health‑Checks und lokale Log‑Sammlung bereit, damit Sie nach dem Restore schnell Integritäts‑ und Performance‑Checks durchführen können.

Architekturhinweis: Behandeln Sie die Restore‑Umgebung wie Infrastruktur‑Code. Versionskontrollierte IaC‑Templates (Ansible, Terraform) und signierte Artefakte, die offline ausgeführt werden können, reduzieren Fehler und beschleunigen das Recovery deutlich.

Für dieses Thema sind auch Lokale Restore-Pfade und Offline-Backups wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.