Backup schlägt fehl — Fehleranalyse mit System

Ein fehlgeschlagenes Backup ist keine Lappalie, sondern eine tickende Uhr. So findest du die Ursache — und so verhinderst du das nächste Mal.

Es ist Freitagmorgen, 07:38 Uhr. Die erste Mail des Tages kommt vom Monitoring der Trendforge Digital GmbH und hat einen unangenehmen Betreff: „SQL Backup Job FAILED — 3 nights in a row.“ Drei Nächte. Niemand hat es bemerkt, weil der Job „nur“ eine rote Zeile im Verlauf hinterlässt und sonst nichts kaputtgeht — der Server läuft, die Anwendung läuft, alles fühlt sich normal an. Aber unter der Oberfläche tickt eine Uhr: Seit drei Tagen gibt es kein gültiges Backup mehr, und das Transaktionslog der größten Datenbank wächst bedrohlich, weil die Log-Sicherung Teil desselben fehlgeschlagenen Jobs ist.

Willkommen beim Symptom, das am leisesten auftritt und am lautesten endet. Ein fehlgeschlagenes Backup ist keine Lappalie, die man „nächste Woche mal anschaut“ — es ist der eine Notfall, der erst dann sichtbar wird, wenn es zu spät ist: beim Restore, der nicht klappt. Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) bringt dir bei, die echte Fehlerursache hinter der nichtssagenden Sammelmeldung zu finden, die häufigsten Stolperfallen gezielt abzuräumen — und das Backup so aufzustellen, dass die nächste rote Zeile gar nicht erst entsteht.

Was bedeutet ein Backup-Fehler technisch?

Ein BACKUP DATABASE ist eine Kette aus vielen Schritten: SQL Server liest die Datenseiten, schreibt sie auf das Zielmedium, sichert den nötigen Teil des Transaktionslogs für die Konsistenz und schließt das Medium ab. Fehlschlagen kann jeder einzelne Schritt — und genau das macht die Diagnose tückisch, denn die Meldung, die du im Job-Verlauf siehst, ist fast immer dieselbe nichtssagende Sammelmeldung: Error 3041, „BACKUP failed to complete the command“. Das ist ungefähr so hilfreich wie „das Auto springt nicht an“ — wahr, aber kein Befund.

Die eigentliche Ursache steht eine bis zwei Zeilen tiefer im ERRORLOG, und sie fällt fast immer in eine von vier Kategorien. Erstens ein Betriebssystem-Fehler auf der Zielseite: Zugriff verweigert (OS error 5), Pfad nicht gefunden (OS error 3), Datenträger voll (OS error 112). Zweitens ein VSS-Problem, wenn eine Backup-Software per Snapshot sichert und der SQL Writer streikt oder mit dem nativen Backup kollidiert. Drittens ein Medien- oder Quell-Defekt (Error 3201, oder schlimmer: Error 824 — dann ist nicht das Backup das Problem, sondern die Datenbank selbst). Und viertens, die unterschätzte Kategorie, ein reines Strategie-Problem: Das Backup läuft technisch, ist aber wertlos, weil nie jemand einen Restore getestet hat. Die ersten drei Kategorien werfen eine rote Zeile und schreien um Aufmerksamkeit — diese vierte ist die heimtückischste, weil sie grün aussieht und trotzdem im Ernstfall versagt.

Diese Vierteilung ist der Schlüssel. Wer sie kennt, googelt nicht stundenlang „3041“, sondern liest die Begleitzeile, ordnet sie ein und ist in Minuten beim eigentlichen Problem. Die Skizze im nächsten Abschnitt macht aus dieser Logik einen Entscheidungsbaum.

Der Diagnose-Pfad: vom Fehler zur Ursache

Der folgende Entscheidungsbaum bündelt die vier Kategorien: Du startest beim abgebrochenen Job, identifizierst die echte Fehlernummer — und landest auf dem kürzesten Weg bei der passenden Maßnahme. Ganz rechts der einzige Zweig, der kein Backup-Problem ist, sondern ein Korruptions-Notfall.

Erste Diagnose: konkrete Skripte

Schritt eins: die echte Fehlernummer aus dem ERRORLOG holen. Der Job-Verlauf zeigt dir 3041 — das ERRORLOG zeigt dir die Begleitzeile mit der eigentlichen Ursache:

Schritt zwei: Wann lief das letzte erfolgreiche Backup pro Datenbank — und welcher Typ? Das beantwortet die Gretchenfrage „Wie alt ist mein Notfall?“ und deckt gleich auf, ob nur die Log-Sicherung oder auch das Voll-Backup betroffen ist:

Steht bei einer Datenbank im Recovery-Model FULL ein uraltes LetztesLog, hast du nicht nur ein Backup-Problem, sondern bald auch ein volllaufendes Transaktionslog — das Symptom hat dann einen eigenen Notarztwagen-Beitrag (/sql-server-transaktionslog-voll/). Schritt drei bei Verdacht auf ein VSS-Problem: den Zustand der Writer prüfen. Das läuft auf dem Betriebssystem, nicht in T-SQL:

Die häufigsten Ursachen — und was du dagegen tust

1. Berechtigungen — der Service-Account, nicht du

Die mit Abstand häufigste Ursache bei Backups auf Netzlaufwerke: Du testest den Pfad in SSMS, er funktioniert — und das Backup scheitert trotzdem mit OS error 5. Der Grund: Es zählt nicht dein Login, sondern das Konto, unter dem der SQL-Dienst läuft. Hat dieser Service-Account keine Schreibrechte auf dem Ziel, ist Schluss. Bei UNC-Pfaden müssen Share- und NTFS-Berechtigungen für den Service-Account stimmen, und gemappte Laufwerksbuchstaben (Z:\backup) sieht der Dienst überhaupt nicht — die existieren nur in deiner angemeldeten Sitzung. Immer den UNC-Pfad (\\server\share\backup) verwenden und die Rechte für den Dienst-Account prüfen, nicht für dich.

2. Zielpfad weg oder Datenträger voll

OS error 3 (Pfad nicht gefunden) und OS error 112 (kein Platz) sind die banalen, aber häufigen Klassiker. Ein Netzlaufwerk wird gewartet und ist nachts für zwei Stunden weg — genau im Backup-Fenster. Oder das Backup-Volume läuft voll, weil die Aufbewahrung (Retention) nicht aufräumt und sich Wochen alte Vollsicherungen stapeln. Gegenmittel: Backups auf ein dediziertes Ziel mit eigener Kapazitätsüberwachung, eine funktionierende Retention (Ola Hallengrens Maintenance Solution erledigt das Aufräumen gleich mit), und ein Alarm auf Plattenfüllstand bevor die 100 Prozent erreicht sind.

3. VSS-Kollision — zwei Backups streiten sich

Ein klassisches Eigentor: Die Infrastruktur sichert den Server per Snapshot (Veeam, Windows-Server-Sicherung, Storage-Snapshot) und gleichzeitig läuft das native SQL-Backup. Beide wollen das Transaktionslog anfassen, und plötzlich ist die Log-Kette zerrissen oder das eine Backup blockiert das andere. Symptome reichen von VSS-Fehlern im ERRORLOG bis zu rätselhaft „abgeschnittenen“ Logs. Die Lösung ist Koordination, nicht Technik: Entweder das Snapshot-Backup ist VSS-aware und übernimmt die SQL-Sicherung sauber (dann das native Log-Backup darauf abstimmen), oder die beiden Jobs werden zeitlich entzerrt, damit sie sich nicht ins Gehege kommen. Wer beide unkoordiniert laufen lässt, sägt an seiner eigenen Wiederherstellbarkeit. Besonders heimtückisch: Beide Backups melden einzeln betrachtet „erfolgreich“ — der Schaden zeigt sich erst, wenn du im Ernstfall eine lückenlose Log-Kette brauchst und feststellst, dass das Snapshot-Backup mittendrin das Log abgeschnitten hat.

4. Das Backup läuft — aber das Medium ist faul

Error 3201 und Schreibfehler mitten im Lauf deuten auf ein defektes oder wackeliges Zielmedium: eine kränkelnde Platte, ein überlastetes NAS, eine instabile Netzwerkstrecke zum Backup-Ziel. Tückischer ist der Fall, in dem das Backup scheinbar durchläuft, aber unbrauchbar ist — weil die Quelldatenbank selbst korrupt ist. Wirft das Backup Error 824 oder Konsistenz-Meldungen, ist nicht mehr das Backup dein Problem, sondern die Datenbank: sofort DBCC CHECKDB, und weiter geht es im DBCC-CHECKDB-Beitrag bzw. bei Suspect-Status im entsprechenden ROT-Beitrag.

5. Der teure Backup-Lauf — Performance statt Fehler

Manchmal „schlägt“ das Backup nicht fehl, sondern läuft so lange, dass es ins Tagesgeschäft hineinragt oder ein Timeout-Fenster reißt. Hier helfen zwei Stellschrauben: Backup-Compression (oft per Default empfehlenswert — kleineres Medium, weniger I/O, kürzere Laufzeit) und die Feinjustierung von MAXTRANSFERSIZE und BUFFERCOUNT auf schnellem Storage. Ein robustes Beispiel:

Das CHECKSUM ist kein Tuning, sondern Lebensversicherung: Es lässt SQL Server beim Backup Prüfsummen schreiben und die gelesenen Seiten validieren — ein erster, billiger Schutz davor, eine bereits korrupte Datenbank ahnungslos zu sichern.

Was du auf keinen Fall tun solltest

Nachsorge: Damit es nicht wiederkommt

Drei strukturelle Maßnahmen heben dich vom „Backup läuft hoffentlich“ zum „Backup beweisbar wiederherstellbar“: Erstens, Verifikation automatisieren — jedes Backup mit CHECKSUM schreiben und per RESTORE VERIFYONLY gegenlesen lassen. Zweitens, Restore-Tests einplanen: regelmäßig eine echte Wiederherstellung auf einen Testserver, mit anschließendem DBCC CHECKDB — das ist der einzige Beweis, der zählt, und zugleich die Generalprobe für den Ernstfall. Drittens, Monitoring auf die Backup-Frische: Das Skript aus diesem Beitrag, das das letzte erfolgreiche Backup je Datenbank zeigt, gehört in einen täglichen Check mit Alarm — dann sind es nie wieder „drei Nächte am Stück, die keiner bemerkt hat“. Wie all das in eine durchdachte Sicherungs-Architektur passt, zeigt der Backup-Strategie-Beitrag der GRÜN-Stufe.

Vertiefung in der Buchreihe

Backup, Restore und Wiederherstellbarkeit sind das Kerngeschäft eines DBAs — und füllen in der Buchreihe „SQL Server in der Praxis“ einen ganzen Band. Die Übersicht aller Bände findest du auf der SQL-Pillar-Seite unter /sql-server/.

Verwandte Notfälle im Notarztwagen

Backup-Probleme haben enge Nachbarn — diese Beiträge aus dem Cluster lohnen den Blick:

Drei Wege, wenn das Backup jetzt gerade streikt

Festpreis-Analyse

Die Backups laufen mal, mal nicht, niemand traut der grünen Statusmeldung mehr so recht — und die Frage „könnten wir im Ernstfall wirklich wiederherstellen?“ lässt sich keiner ehrlich beantworten? Dafür gibt es die Festpreis-Analyse: Ich prüfe die komplette Sicherungskette — Job-Konfiguration, Fehlerhistorie, Berechtigungen, VSS-Setup, Recovery-Modelle und die Backup-Frische jeder Datenbank — und führe einen echten Restore-Test durch. Ergebnis ist ein Bericht mit konkreten Maßnahmen und einer ehrlichen Antwort auf die Wiederherstellbarkeits-Frage. Zum vereinbarten Festpreis, ohne Stundenzähler.

Akut-Hotline

Wenn gerade ein Restore ansteht und das Backup zickt — oder das Log überzulaufen droht, weil die Sicherung seit Tagen klemmt: anrufen. Halte das ERRORLOG bereit und die Information, wohin gesichert wird (lokal, UNC, Snapshot-Software) und unter welchem Konto der SQL-Dienst läuft. Mit der echten Fehlernummer ist die Ursache meist in Minuten eingegrenzt.

Selbst-Diagnose-Kit

Du willst die Sicherungskette selbst prüfen? Genau richtig. Das Diagnose-Kit bündelt die Skripte aus diesem Beitrag — ERRORLOG-Auswertung, Backup-Frische je Datenbank, VSS-Writer-Check, Verifikations-Vorlagen — als ausführbares Paket mit Auswertungshilfe und einer Checkliste für den nächtlichen Backup-Job.

Häufige Fragen (FAQ)

Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.

Was tun, wenn SQL Server Backup fehlschlägt?

Nicht in Aktionismus verfallen, sondern die echte Fehlernummer suchen. Die Meldung im Job-Verlauf ist meist nur Error 3041 — eine Sammelmeldung, die sagt „irgendwas ist schiefgegangen“. Der eigentliche Grund steht im ERRORLOG ein bis zwei Zeilen darunter: ein Betriebssystem-Fehler (Zugriff, Pfad, Platz), ein VSS-Problem oder ein Defekt am Medium. Lies also zuerst das ERRORLOG, ordne die Fehlernummer ein und handle gezielt. Der Entscheidungsbaum in diesem Beitrag führt dich von der Nummer direkt zur Ursache — und vergiss anschließend die Verifikation nicht.

Was ist der VSS Writer?

VSS (Volume Shadow Copy Service) ist der Windows-Mechanismus, mit dem Backup-Software konsistente Snapshots erstellt. Der SQL Writer (Dienst „SQL Server VSS Writer“) ist die Brücke dorthin: Er sorgt dafür, dass Dritt-Backups (Veeam, der Windows-Server-Sicherung, Storage-Snapshots) die Datenbanken in einem sauberen Zustand erwischen. Probleme entstehen, wenn dieser Dienst hängt, wenn mehrere Snapshot-Backups kollidieren oder wenn ein VSS-Job mit dem nativen SQL-Backup um dieselben Ressourcen ringt. Mit vssadmin list writers prüfst du den Zustand der Writer — Details im VSS-Abschnitt dieses Beitrags.

Wie behebe ich Fehler 3041 im SQL Server?

Error 3041 behebt man nicht direkt — er ist nur die Verpackung. Die Meldung „BACKUP failed to complete the command“ ist eine generische Sammelmeldung; der behebbare Fehler steht im ERRORLOG unmittelbar darüber oder darunter, oft mit einer Betriebssystem-Fehlernummer (etwa OS error 5 für Zugriff verweigert oder 112 für Datenträger voll). Such also nach der Begleitzeile, ordne die echte Ursache ein und behebe diese. Wer nur nach „3041“ googelt, jagt ein Phantom. Wie du die Begleitmeldung gezielt aus dem ERRORLOG ziehst, steht im Diagnose-Abschnitt.

Was bedeutet die Fehlermeldung BackupDevice failed?

Das ist die Storage- bzw. Zielseite des Problems: SQL Server kann das Backup-Gerät — also die Zieldatei oder den Pfad — nicht beschreiben. Typische Begleitnummern sind OS error 3 (Pfad nicht gefunden, etwa ein getrenntes Netzlaufwerk), OS error 5 (Zugriff verweigert, dem Service-Account fehlen Rechte auf dem Ziel) oder OS error 112 (kein Platz mehr). Prüfe in dieser Reihenfolge: Existiert der Pfad aus Sicht des SQL-Dienstes? Hat der Service-Account Schreibrechte darauf? Ist genug Platz da? Network-Shares brauchen dabei UNC-Pfade und passende Berechtigungen — lokale Laufwerksbuchstaben des angemeldeten Benutzers sieht der Dienst nicht.

Wie teste ich, ob mein Backup wirklich wiederherstellbar ist?

Mit zwei Stufen, die du nicht verwechseln darfst. RESTORE VERIFYONLY prüft, ob das Backup-Medium lesbar und in sich stimmig ist — das ist Pflicht-Hygiene, beweist aber nur die Lesbarkeit, nicht die Wiederherstellbarkeit. Den echten Beweis liefert nur ein Test-Restore auf einen anderen Server oder unter anderem Namen, idealerweise mit anschließendem DBCC CHECKDB auf der zurückgespielten Datenbank. Erst dann weißt du, dass aus dem Backup im Ernstfall wieder eine funktionierende Datenbank wird. Ein Backup, das nie restored wurde, ist eine Hoffnung — kein Backup.

Was ist MAXTRANSFERSIZE und wie setze ich es?

MAXTRANSFERSIZE steuert die Größe der Datenblöcke, die SQL Server beim Backup auf einmal überträgt — Standard sind 1 MB, das Maximum liegt bei 4 MB (4194304 Bytes). Auf schnellem Storage oder bei großen Datenbanken kann ein höherer Wert den Durchsatz spürbar verbessern; in Kombination mit BUFFERCOUNT lässt sich der Backup-Durchsatz feinjustieren. Wichtig: Bei TDE-verschlüsselten Datenbanken mit Backup-Compression ist ein MAXTRANSFERSIZE über 65536 sogar Voraussetzung, damit beides zusammen funktioniert. Beispiele und die Syntax stehen im Performance-Abschnitt dieses Beitrags.

Welche Berechtigungen braucht das Backup-Konto?

Zwei Ebenen: Auf SQL-Ebene braucht der Ausführende die Server-Rolle dbcreator oder die Datenbank-Rollen db_owner bzw. db_backupoperator. Entscheidend ist aber die zweite Ebene — das Betriebssystem-Konto, unter dem der SQL-Dienst läuft (nicht dein Login!), braucht Schreibrechte auf dem Zielpfad. Genau hier scheitern die meisten Backups auf Netzlaufwerke: Du hast Rechte, der Dienst-Account nicht. Bei UNC-Zielen müssen sowohl die Share- als auch die NTFS-Berechtigungen für den Service-Account stimmen. Wie du das prüfst, steht im Abschnitt zu den häufigsten Ursachen.