Ein schönes Beispiel um zu zeigen, wie man Windows Backup-Fehler generell debuggen kann, gültig für Windows Server 2008 und neuer (entspricht den Client-Betriebssystemen Vista und neuer):
(1) FEHLERBESCHREIBUNG
Log des Sicherungsprogramms meldet:
The backup operation stopped before completing.
Detailed error: ERROR – A Volume Shadow Copy Service operation error has occurred: (0x800423f4)
The writer experienced a non-transient error. If the backup process is retried, the error is likely to reoccur.
Die sog. VSS Writer sammeln Daten von der Festplatte, MSSQL, IIS, Exchange, und so weiter ein und schreiben die jeweiligen Daten(-banken) in einem konsistenten Stand ins Backup, übrigens werden die meistens auch bei Drittanbieter-Software verwendet (Acronis, BackupExec, etc…)
(2) WER IST DER SCHULDIGE?
Infos darüber, welches VSS-Writer-Modul den Fehler erzeugt, findet man in der Konsole mit „VSSADMIN LIST WRITERS“
Writer name: ‚SqlServerWriter‘
Writer Id: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a}
Writer Instance Id: {4fb3be04-8d39-4fc4-9b39-dd6abe6061a9}
State: [8] Failed
Last error: Non-retryable error
Ergo: irgendwas mit SQL.
(3) EIN BISSCHEN GENAUER, BITTE
Die Windows-Ereignisanzeige (am besten schaut man immer zuerst bei den „Administrativen Ereignissen“, da bekommt man nur Warnungen und Fehler) sagt zum Zeitpunkt, als das Backup abgebrochen ist:
Source: SQLWRITER
EventID: 8193
SQL writer error: Unexpected error calling routine
IClientVirtualDevice::GetCommand. hr = 0x80770004.
sowie viele dutzende:
Source: MSSQL$MSSQLSERVER2008
EventID: 3041
BACKUP failed to complete the command BACKUP DATABASE MSSQL047.
Check the backup application log for detailed messages.
Ein kurzer Blick nach den beiden Event-IDs und dem Fehlercode 0x80770004 bringt einen dazu, dass es wohl um kaputte Datenbanken geht, die wegen einer Eigenschaft „AutoClose = True“ kaputt gehen, gerade auf hektisch befahrenen MSSQL-Servern.
(4) DIE PROBLEMLÖSUNG
Microsoft sagt dazu, es sei „Best Practice“, die AutoClose Property abzuschalten. AutoClose bringt den SQL-Server dazu, die Datenbank beim disconnect des letzten Clienst die Daten auf die Festplatte zu schreiben. Verbindet wieder ein Client, wird die DB wieder geöffnet, und wieder geschlossen, und auf, und zu, und BUMM.
Das ist nicht nur anspruchsvoll für die DB, sondern macht auch jegliche Caching-Versuche zunichte. Der Server sollte halt bei deaktiviertem AutoClose nicht hart abgeschalten werden.
Schnell das MSSQLMS (Microsoft SQL Server Management Studio) gestartet, als Administrator eingeloggt, „New Query“, und mit folgender Abfrage betroffene Datenbanken gesucht:
SELECT * FROM sys.databases WHERE DATABASEPROPERTYEX (name, ‚IsAutoClose‘) = 1
Die Datenbanken kann man nun mit rechtsklick auf die Datenbank -> Eigenschaften -> Optionen -> AutoClose = false entsprechend konfigurieren.
Manche Datenbanken quittieren das mit einem Fehler 9001, da hilft es die DB offline und online zu nehmen. Die Ursache dafür ist genau der Datenbankdefekt, der durch die angeschaltene AutoClose Option beursacht wurde.
Hint: Microsoft hat ab *irgendeiner* Version (eine neuere als die, an der ich sitze) AutoClose = off direkt in das CREATE DATABASE Statement als Standardwert implementiert. Besser spät als nie.
(5) AUFRÄUMARBEITEN
Hat man alle Datenbanken richtig konfiguriert, werden die kaputten DBs noch repariert. Das kann man sich klicken, schneller geht’s aber mit folgendem Query:
SQL-Kung Fu für „ich habe kein Backup aber will alle Datenbanken jetzt sofort reparieren“:
MSSQL 2005 und früher:
exec sp_MSforeachDB ‚DBCC CHECKDB („?“) WITH ALL_ERRORMSGS, DATA_PURITY‘MSSQL 2008 und später:
exec sp_MSforeachDB ‚DBCC CHECKDB („?“) WITH ALL_ERRORMSGS, EXTENDED_LOGICAL_CHECKS, DATA_PURITY‘
Danach startet man das Backup und freut sich auf das nächste Problem 🙂