#222 - [MSP] Restore-Nachweis je Guest — Backups laufen ist nicht Backups funktionieren - chinux/theProx

chinux commented

2026-07-20 23:15:02 +00:00

Owner

BackupLog beantwortet, ob Backups laufen. Die Frage, an der ein MSP tatsächlich haftet, ist eine andere: Wurde je geprüft, ob sie sich zurückspielen lassen?

Warum das ein eigenes Feature ist

Ein erfolgreicher Backup-Lauf ist keine Zusage. Defekte Sicherungen laufen jahrelang grün durch, bis sie gebraucht werden. Im Schadensfall ist „das Backup lief jede Nacht erfolgreich" keine Verteidigung, wenn nie jemand einen Restore versucht hat.

Der Aufwand ist gering, der Wert im Ernstfall hoch — und es ist etwas, das man einem Kunden zeigen kann.

Umfang

Restore-Test-Protokoll je Guest: Datum, Prüfer, Backup-Zeitpunkt der getesteten Sicherung, Ergebnis (erfolgreich / mit Einschränkungen / fehlgeschlagen), Freitext-Notiz, optional Dateianhang.

Fälligkeitslogik: Intervall je Mandant oder je Guest (Vorschlag: 6 Monate Default). Überfällige Tests erscheinen als Arbeitsliste und im Kundenbericht.

Manuell, nicht automatisch. Ein automatischer Restore-Test wäre technisch reizvoll — Sicherung in eine isolierte VM zurückspielen, booten, prüfen — bringt aber erhebliche Risiken mit sich: Ressourcenverbrauch, IP-Konflikte durch eine hochfahrende Kopie, mögliche Schreibzugriffe auf Produktivsysteme durch Dienste in der wiederhergestellten VM. Für v1 bewusst ein Protokoll, das ein Mensch ausfüllt. Der automatische Test kann später als eigenes Vorhaben kommen, dann aber mit sauberem Netzkonzept.

Guests ohne jeden Test sind die eigentlich interessante Liste — prominenter als die Erfolgsquote.

Offene Frage

Soll das Protokoll in die Doku (#209) einfließen? Argument dafür: es ist ein Strukturmerkmal, kein Zustand. Argument dagegen: es ist ein Betriebsnachweis und gehört eher in den Kundenbericht.

Abhängigkeiten

Verfügbarkeits-/Backup-Bericht-Issue

`BackupLog` beantwortet, ob Backups **laufen**. Die Frage, an der ein MSP tatsächlich haftet, ist eine andere: Wurde je geprüft, ob sie sich **zurückspielen** lassen? ## Warum das ein eigenes Feature ist Ein erfolgreicher Backup-Lauf ist keine Zusage. Defekte Sicherungen laufen jahrelang grün durch, bis sie gebraucht werden. Im Schadensfall ist „das Backup lief jede Nacht erfolgreich" keine Verteidigung, wenn nie jemand einen Restore versucht hat. Der Aufwand ist gering, der Wert im Ernstfall hoch — und es ist etwas, das man einem Kunden zeigen kann. ## Umfang **Restore-Test-Protokoll je Guest:** Datum, Prüfer, Backup-Zeitpunkt der getesteten Sicherung, Ergebnis (erfolgreich / mit Einschränkungen / fehlgeschlagen), Freitext-Notiz, optional Dateianhang. **Fälligkeitslogik:** Intervall je Mandant oder je Guest (Vorschlag: 6 Monate Default). Überfällige Tests erscheinen als Arbeitsliste und im Kundenbericht. **Manuell, nicht automatisch.** Ein automatischer Restore-Test wäre technisch reizvoll — Sicherung in eine isolierte VM zurückspielen, booten, prüfen — bringt aber erhebliche Risiken mit sich: Ressourcenverbrauch, IP-Konflikte durch eine hochfahrende Kopie, mögliche Schreibzugriffe auf Produktivsysteme durch Dienste in der wiederhergestellten VM. Für v1 bewusst ein Protokoll, das ein Mensch ausfüllt. Der automatische Test kann später als eigenes Vorhaben kommen, dann aber mit sauberem Netzkonzept. **Guests ohne jeden Test** sind die eigentlich interessante Liste — prominenter als die Erfolgsquote. ## Offene Frage Soll das Protokoll in die Doku (#209) einfließen? Argument dafür: es ist ein Strukturmerkmal, kein Zustand. Argument dagegen: es ist ein Betriebsnachweis und gehört eher in den Kundenbericht. ## Abhängigkeiten - Verfügbarkeits-/Backup-Bericht-Issue

chinux referenced this issue

2026-07-20 23:15:03 +00:00

[MSP] Verbrauchsreport je Mandant + Metrik-Rollup und Retention (Abrechnungsgrundlage) #218

chinux referenced this issue

2026-07-20 23:15:03 +00:00

[MSP] Kundenbericht: Verfügbarkeit und Backup-Erfolg je Mandant und Monat #219

chinux referenced this issue

2026-07-20 23:15:03 +00:00

[MSP] Wartungsfenster und Change-Freeze je Mandant — Voraussetzung für scharfes Auto-Update #220

chinux referenced this issue

2026-07-20 23:15:04 +00:00

[MSP] Alarme als Objekt: Quittierung, Deduplizierung, Eskalation, Bereitschaft, Stummschaltung #221

chinux commented

2026-07-20 23:15:04 +00:00

Author

Owner

Teil des MSP-Themenblocks: #218, #219, #220, #221, #222, #223, #224, #225. Reihenfolge-Vorschlag: #218 (Datengrundlage) → #223 (Vertragsstatus) → #220 (Wartungsfenster) → #219 (Kundenbericht) → Rest.