# Application Recovery: Orchestrierung komplexer Dienst-Wiederherstellungen

TL;DR / Management Summary Ein erfolgreiches Recovery endet nicht beim Booten der VM. Application Recovery umfasst die Wiederherstellung der vollen Funktionalität eines Dienstes, der oft aus mehreren Komponenten (Webserver, Datenbank, Cache, Auth-Service) besteht. Ein Senior Admin nutzt Wiederherstellungs-Playbooks und Orchestrierungstools, um Abhängigkeiten zu wahren (z.B. Datenbank muss vor dem Webserver laufen) und die Integrität der Daten zwischen den Schichten zu validieren.

# 1. Das Ebenen-Modell des Recovery

Die Schichten der Wiederkehr.

  1. Infrastructure Level: Blech, Hypervisor, Storage, Netzwerk (VLANs).
  2. OS Level: Bootfähigkeit, Treiber, Systemdienste.
  3. Data Level: Datenbanken (Artikel 640), Fileshares (Artikel 638).
  4. Application Level: Logik, Konfigurationsdateien, Zertifikate.
  5. Access Level: DNS-Einträge, Firewall-Regeln, Loadbalancer (Artikel 562).

# 2. Abhängigkeiten managen (Boot Order)

Wer darf zuerst?

In einem modernen Stack ist die Reihenfolge entscheidend:

# 3. Deep Dive: Web-Applikation Recovery (LOB Apps)

Vom Code zum Dienst.

Häufiges Szenario: Eine interne Web-App ist abgestürzt.

  1. Code Restore: Wiederherstellung des /var/www oder /inetpub Verzeichnisses.
  2. Config Sync: Prüfen, ob Passwörter in der .env oder web.config noch zum wiederhergestellten SQL-Server passen.
  3. Perms Check: Sicherstellen, dass der User www-data oder IIS_IUSRS wieder Schreibrechte auf dem Upload-Verzeichnis hat.

# 4. Day-2 Operations: Disaster Recovery Playbooks

Wissen unter Druck.

Schreiben Sie “Kochrezepte” für Ihre wichtigsten Applikationen.

# 5. Troubleshooting & “War Stories”

Wenn die App ‘Nein’ sagt.

# Top 3 Fehlerbilder

  1. Symptom: VM läuft, aber Webseite zeigt “Database Connection Error”.

    • Ursache: Datenbank-Server hat nach dem Restore eine neue IP bekommen oder der Dienst-Account ist im AD gesperrt.
    • Lösung: /etc/hosts oder Config-Files prüfen.

  2. Symptom: “Permission Denied” im Browser nach dem Restore.

    • Ursache: Die User-IDs (UID/GID) im Backup passen nicht zum neuen Linux-System (Mismatch bei LDAP/Local User).
    • Fix: chown -R www-data:www-data /var/www.

  3. Symptom: Applikation ist extrem langsam.

    • Ursache: Der Cache (Redis/Memcached) wurde nicht wiederhergestellt oder ist noch leer (Cold Cache Problem).

# “War Story”: Die “DNS-Falle” beim Schwenk

Ein Unternehmen schwenkte nach einem Brand auf sein DR-Rechenzentrum um. Alle Server waren nach 2 Stunden online. Das Problem: Niemand kam auf die Webseiten. Die Ursache: Die TTL (Time To Live) der öffentlichen DNS-Einträge stand auf 24 Stunden. Obwohl die OPNsense im neuen RZ die richtige IP hatte, leiteten die Internet-Provider den Traffic immer noch an die abgebrannte Brandruine weiter. Lehre: Application Recovery beinhaltet auch das DNS-Management. Setzen Sie die TTL für kritische Dienste präventiv auf 5-10 Minuten.

# 6. Monitoring & Reporting

Funktionstest automatisieren.

# Synthetic Monitoring

Nutzen Sie Tools wie Uptime Kuma oder Nagios, um nach dem Restore sofort die End-to-End Funktionalität zu prüfen.

# 7. Fazit & Empfehlung

Application Recovery ist das eigentliche Ziel des Backups.

# Anhang: Cheatsheet (App Health Check)

Befehl (Linux) Zweck
systemctl status <dienst> Läuft der Prozess?
ss -tlpn Lauscht die App auf dem Port?
tail -f /var/log/<app>/error.log Wo klemmt es?
df -h Ist Platz für Uploads da?

# Referenzen