„Wir haben ein Backup, das Hosting macht jede Nacht einen Snapshot." Diesen Satz hören wir in jedem zweiten Gespräch über den Schutz eines ERP. Und in jedem zweiten stellt sich heraus, dass es kein Backup gibt — nur ein Maschinen-Abbild, aus dem die Datenbank nicht sauber hochkommt.
Eine Datenbank ist keine normale Datei. Während Comarch Optima, enova365, Subiekt oder Microsoft Dynamics AX läuft, passieren im Innern der Datenbank Dinge, die man vom Betriebssystem aus nicht sieht: offene Transaktionen, Speicher-Puffer, das Transaktionslog, das Änderungen aufzeichnet, bevor sie in den Datendateien landen. Wenn der Hypervisor in einem zufälligen Moment einen Snapshot zieht, fängt er diesen Zustand „mitten im Satz" ein. Nach dem Restore fährt SQL Server hoch, startet das Recovery und erreicht — mit Glück — einen konsistenten Zustand. Ohne Glück landet die Datenbank im SUSPECT-Modus und du rufst beim ERP-Hersteller an.
Das ist keine Theorie. Es ist ein Szenario, das wir bei Kunden jedes Jahr sehen, meistens nach einem Stromausfall oder Ransomware.
Was ein „Server-Snapshot" wirklich tut
Ein VM-Snapshot in Hyper-V, VMware oder Proxmox friert den Zustand der Festplatte (und optional des RAM) zu einem bestimmten Zeitpunkt ein. Aus Sicht des Hypervisors — sehr bequem. Aus Sicht der Datenbank — es ist, als ob jemand den Strom rausgezogen hätte.
Gute Hypervisoren können mit Anwendungen über VSS (Volume Shadow Copy Service) unter Windows zusammenarbeiten. Dann bittet das System vor dem Zug den SQL Server, „kurz beiseitezutreten" — offene Transaktionen zu schließen, Puffer auf die Platte zu schreiben. Das nennt sich application-consistent Snapshot und ist der einzige Snapshot, um den es sich zu kämpfen lohnt.
Das Problem ist: in kleinen Firmen funktioniert das in der Praxis oft nicht. Die Gründe sind einfach:
- Der Snapshot wird auf VPS-Ebene beim Hoster gezogen, der VSS gar nicht aufruft.
- Der VSS-Writer für SQL Server ist seit irgendeinem Update deaktiviert und niemand hat es bemerkt.
- Die Datenbank läuft auf der kostenlosen SQL Server Express Edition, wo manche Mechanismen beschnitten sind.
- Der Snapshot umfasst zwei Platten und nur eine wurde konsistent eingefroren.
Ergebnis: du hast eine VMDK-, VHDX- oder QCOW2-Datei, die wie ein Backup aussieht, und nach dem Restore stellt sich heraus, dass die Datenbank beschädigt ist oder dass die letzten Stunden an Vorgängen fehlen.
Was passiert, wenn man wirklich restoren muss
Bei einem unserer Kunden — einem 25-köpfigen Elektro-Großhändler, der Comarch Optima auf SQL Server Express betreibt — ist am Mittwochabend der RAID-Controller ausgefallen. Der Hoster hatte einen täglichen Snapshot um 3:00 Uhr morgens. Das Wiederherstellen der Maschine dauerte eine Stunde. Optima hochzubekommen dauerte weitere 3 Stunden, weil die Datenbank in „recovery pending" hing und manuellen Eingriff verlangte.
Als sie endlich lief, stellte sich heraus, dass 8 Stunden Transaktionen fehlten — alle Rechnungen, Wareneingänge und Zahlungen des ganzen Arbeitstags. Die Firma verbrachte die nächsten zwei Tage damit, Daten manuell aus Papier-Lieferscheinen und Kontoauszügen zu rekonstruieren. Der Zeitverlust bei Vertrieb und Buchhaltung wurde auf rund 30.000 PLN geschätzt. Der Snapshot war da, „funktionierte" — und die Firma hat trotzdem einen ganzen Arbeitstag verloren.
Hätte stattdessen eine klassische Datenbank-Backup-Strategie gelaufen — Vollsicherung jede Nacht, differentielle Sicherung alle 6 Stunden und Transaktionslog-Sicherung alle 15 Minuten — wäre der Wiederherstellungspunkt (RPO) höchstens 15 Minuten gewesen, nicht 8 Stunden. Der Aufwand: einmalig ein paar Stunden Konfiguration und ein paar Dutzend Gigabyte Speicher pro Monat.
Wie ein sauber gemachtes Datenbank-Backup aussieht
Für die meisten KMU-Installationen von Comarch Optima, enova365, Subiekt GT/Nexo oder Dynamics AX auf Microsoft SQL Server passt ein einfaches Muster:
- Vollsicherung (FULL) einmal täglich, nachts, wenn niemand arbeitet.
- Differentielle Sicherung (DIFF) alle 4–6 Stunden während der Arbeitszeit — wenige Prozent der Größe der FULL.
- Transaktionslog-Sicherung alle 15 Minuten — ermöglicht das Restore zu einem bestimmten Zeitpunkt, minutengenau.
- Backups im FULL Recovery Model, nicht SIMPLE — sonst ist das Log nutzlos.
- Verifizierung (RESTORE VERIFYONLY) nach jeder Sicherung — prüft die Integrität der Datei.
- Backups an mindestens zwei Orten — eine lokal, eine außer Haus (Cloud, zweiter Standort, Offline-Platte).
Das lässt sich alles mit Ola Maintenance Plans, mit dem SQL Server Agent (in der Standard-Edition) oder mit der kostenlosen Ola Hallengren's SQL Server Maintenance Solution automatisieren. Comarch Optima bringt auch einen eigenen Backup-Mechanismus in der Konsole mit — für kleine Datenbanken reicht das völlig aus, man muss ihn nur einschalten.
Ein Hinweis: SQL Server Express hat keinen SQL Server Agent. Den Zeitplan muss man dort über den Windows Task Scheduler oder ein PowerShell-Skript automatisieren. Das funktioniert, aber man muss es tun — sonst bedeutet „wir haben ein Backup" nur „wir hoffen".
Backup außer Haus — weil Ransomware keine Rücksicht nimmt
Selbst das beste Datenbank-Backup ist nutzlos, wenn es auf demselben Server liegt wie die Produktion. Aktuelle Ransomware sucht gezielt nach .bak-, .trn- und .mdf-Dateien und verschlüsselt sie mit dem Rest. Wir haben einen Fall gesehen, in dem eine Firma 60 Tage Backups hatte — alle auf derselben Netzwerkfreigabe, alle in 20 Minuten verschlüsselt.
Die 3-2-1-Regel (drei Kopien, auf zwei Medien, eine außer Haus) gilt auch für ERP-Datenbanken. In der Praxis für ein KMU heißt das:
- eine lokale Kopie auf dem Server,
- eine Kopie auf einem zweiten physischen Gerät (NAS in einem anderen Raum, zweiter Server an einem anderen Standort),
- eine Kopie außer Haus — Azure Blob Storage, AWS S3, ein Backup beim Hoster, oder eine USB-Platte, die abends mit dem Geschäftsführer nach Hause geht.
Die Offsite-Kopie sollte immutable (unveränderlich) sein oder in einem Konto mit eigenen Zugangsdaten liegen, auf das das Domain-Admin-Konto keinen Zugriff hat. Sonst räumt Ransomware, die es auf den Server schafft, auch die Cloud ab.
Restore-Test — der einzige echte Beweis
Ein Backup, das nie zurückgespielt wurde, ist ein Schrödinger-Backup — es existiert und existiert nicht zugleich. Regelmäßig einen Restore in eine Testumgebung zu machen, ist der einzige Weg zu wissen, dass die Kopie wirklich funktioniert.
Unsere Empfehlung: einmal im Monat den letzten FULL plus alle DIFF/LOG-Kopien auf einen separaten Testserver restoren, Optima/enova/AX auf dieser Kopie starten, ein paar Rechnungen öffnen, einen Bericht erzeugen. Für Vorbereitete dauert das etwa 2 Stunden; man kann es einmal durchspielen und eine Schritt-für-Schritt-Anleitung aufschreiben (IT-Dokumentation — siehe unseren gesonderten Beitrag).
Wenn beim Test die Datenbank nicht hochkommt — hast du ein bekanntes Problem, kein Problem, das mitten im Ausfall entdeckt wird. Das ist der ganze Unterschied.
Zusammenfassung
Ein Maschinen-Snapshot ist Teil des Plans, nicht der ganze Plan. Für ein ERP brauchst du eine eigene Datenbank-Backup-Strategie mit kurzem RPO, einer Offsite-Kopie und regelmäßigem Restore-Test. Ohne das kostet dich der erste ernste Vorfall einen Arbeitstag, Verkaufsdaten und Nerven — und oft das Vertrauen der Kunden, deren Rechnungen du ein zweites Mal ausstellen musst.
Wenn du nicht sicher bist, ob deine Firma in der besseren Hälfte ist, buch eine halbe Stunde. Wir sagen dir genau, was zu prüfen ist und wo anzufangen, wenn das Backup in Wirklichkeit nicht existiert.
Ein Backup, das du nie zurückgespielt hast, ist kein Backup — es ist Hoffnung. Und Hoffnung ist keine IT-Strategie.