Sicherungen

Die Seite Sicherungen beantwortet pro Datenbank eine Frage: Wenn dieser Server jetzt ausfiele — wie viel bestätigte Arbeit wäre verloren, und ließe er sich überhaupt wiederherstellen?

Woher die Zahlen kommen

Aus msdb.dbo.backupset jeder überwachten Instanz, aktualisiert vom Infrastruktur-Snapshot im Hintergrund. Diese Tabelle verzeichnet ausschließlich erfolgreiche Sicherungen — es gibt also gar keine „fehlgeschlagene Sicherung", nach der man suchen könnte. Ein Fehlschlag zeigt sich hier als Alter: Die letzte Voll- oder Log-Sicherung wird einfach nicht neuer. (Die Fehlermeldung selbst steht im SQL Server-Fehlerprotokoll als Fehler 3041 und wird vom Fehlerprotokoll-Sammler erfasst.)

msdb wird über ein begrenztes Fenster durchsucht (standardmäßig 90 Tage). Eine Datenbank ohne Treffer darin wird als „keine Vollsicherung in den letzten 90 Tagen" gemeldet, nicht als „nie" — eine begrenzte Suche kann „nie" nicht ehrlich behaupten.

Die Statusstufen

Stufe Bedeutung
Kritisch Keine Sicherung, Vollsicherung über dem Grenzwert — oder, am wichtigsten, eine FULL/BULK_LOGGED-Datenbank, deren Log nicht gesichert wird.
Warnung Wiederherstellbar, aber die neueste Voll- oder Differenzsicherung ist so alt, dass eine Wiederherstellung eine lange Kette von Log-Sicherungen nachspielen müsste.
OK Innerhalb der konfigurierten Grenzwerte.
n/z Die Frage stellt sich nicht: Die Datenbank ist offline, in Wiederherstellung oder sonst nicht sicherungsfähig.

Warum die Log-Regel alles andere übertrumpft

Einer Datenbank im Wiederherstellungsmodell FULL, deren Transaktionsprotokoll nie gesichert wird, fehlen nicht bloß Wiederherstellungspunkte. Ihr Protokoll kann nicht abgeschnitten werden und wächst, bis die Platte voll ist — dann stoppen Schreibvorgänge mit Fehler 9002. Das ist keine Berichtslücke, das ist ein bevorstehender Ausfall, und genau deshalb wiegt es schwerer als eine fehlende Vollsicherung.

Datenbanken im Modell SIMPLE werden nie wegen fehlender Log-Sicherungen bemängelt — ihr Protokoll lässt sich gar nicht sichern.

Grenzwerte

Konfiguriert unter BackupMonitoring in appsettings.json. Die Vorgaben beschreiben den üblichen Aufbau, nicht einen Wunschzustand:

Einstellung Vorgabe Bedeutung
FullMaxAgeHours 168 (7 Tage) Wöchentliche Vollsicherung
DiffMaxAgeHours 24 Ist die Vollsicherung älter, wird eine Differenzsicherung erwartet
LogMaxAgeMinutes 90 Stündliche Log-Sicherung, mit Luft nach oben
NewDatabaseGraceHours 24 Eine frisch erstellte oder wiederhergestellte Datenbank wird nicht sofort bemängelt

LogMaxAgeMinutes steht bewusst auf 90 statt 60. Bei einem stündlichen Log-Job und einer 60-Minuten-Grenze überschreitet das Alter den Grenzwert in den Minuten vor jedem Lauf — ein Alarm, der auf einem korrekt konfigurierten Server stündlich feuert, für immer.

Copy-Only-Sicherungen

Eine mit COPY_ONLY erstellte Vollsicherung ist einwandfrei wiederherstellbar, wird aber nicht zur Basis für Differenzsicherungen. Ein Server, der ausschließlich so gesichert wird, sieht daher gesund aus und hat trotzdem keine Differenzbasis. Solche Datenbanken tragen in der Liste ein copy-only-Abzeichen.

Verlauf je Datenbank

Ein Klick auf eine Zeile liest die jüngsten Sicherungen dieser Datenbank live aus msdb: Typ, Größe, komprimierte Größe, Dauer und Gerät. Ein Gerätename, der wie eine GUID statt wie ein Pfad aussieht, ist ein Fremdwerkzeug, das über die Virtual Device Interface schreibt — die Sicherung ist echt, sie ist nur keine Datei.

Alarme

Ein Alarm pro Server, nicht pro Datenbank: Ein nächtlicher Job, der auf einem Server mit sechzig Datenbanken fehlschlägt, ist einmal fehlgeschlagen. Der Alarm nennt die Anzahl der betroffenen Datenbanken und den Grund der schlimmsten — und er löst sich selbst auf, sobald alle Datenbanken wieder innerhalb ihrer Grenzwerte liegen. Anders als ein Fehlerprotokoll-Alarm ist der Sicherungsstatus ein Zustand, kein Ereignis.

Azure SQL-Datenbank

Dort gibt es kein msdb und damit keine Sicherungshistorie zu lesen. Sicherungen sind dort Sache der Plattform; die Seite überspringt solche Instanzen.