Alexander LuftVon Alexander Luft
JTL Service Partner Gold · Ahrensfelde bei Berlin · 22. August 2025 · 8 Min. Lesezeit
JTL-Wawi Datenbankexport-Dialog mit SQL Server im Hintergrund — Backup-Datei wird geschrieben

JTL-Wawi Datenbank-Backup automatisieren: SSMS-Wartungsplan, SQL Server Agent und der Express-Workaround

Ein JTL-Wawi-Backup ist nicht das, was du dachtest. Der Datenbankexport in der Wawi-Oberfläche ist eine manuelle Sicherung, kein automatischer Schutz. Sobald die Wawi geschlossen ist, sichert nichts mehr — und die meisten Crashs passieren nachts. Wir sehen diese Situation regelmäßig: Ein SQL Server bootet nach einem Windows-Update nicht mehr sauber, die Wawi-Datenbank ist beschädigt, das letzte Backup liegt vom vorletzten Quartalsabschluss vor. Der Restore wird dann teuer. Wer JTL-Wawi produktiv nutzt, braucht ein Backup, das täglich automatisch läuft, eine Restore-Routine, die getestet ist, und einen zweiten Speicherort außerhalb des Servers.

Du hast die Wawi seit Jahren laufen, aber kein Backup, das du im Ernstfall einspielen kannst?

Wir zeigen dir die Einrichtung für SQL Server Standard mit dem Server Agent, den Workaround für die Express-Version mit Windows-Aufgabenplanung, und die typischen Fehler, die wir bei Bestandskunden finden — von fehlenden Schreibrechten bis zum Backup-Laufwerk, das nach drei Wochen voll war.

Auf einen Blick

  • ✓Unsere Erkenntnis aus über 300 Wawi-Projekten: In gut der Hälfte der Notfall-Restores war das letzte verwendbare Backup älter als zwei Wochen — entweder nie automatisiert, voll gelaufen oder nie auf Wiederherstellbarkeit getestet. Ein Backup ohne Restore-Test ist kein Backup.
  • ✓SQL Server Standard und höher: Wartungsplan im SSMS einrichten, Server Agent läuft die Sicherung täglich automatisch, idealerweise außerhalb der Geschäftszeiten plus eine Kopie auf ein zweites Laufwerk oder NAS. Sicherung ohne Externe-Kopie ist nur halb fertig.
  • ✓SQL Server Express hat keinen Server Agent — JTL liefert dafür einen offiziellen Workaround mit `sqlcmd` und einer Windows-Aufgabe. Die Vlarom E-Commerce Agentur richtet bei Express-Kunden diese Variante ein und ergänzt sie um eine Rotation, damit das Backup-Laufwerk nicht leise volläuft.

Ein verlorener SQL-Server kostet nicht nur Datenbank, sondern auch Auftragshistorie, Kundengruppen, Artikelstamm und sämtliche laufende Vorgänge. Jeder dieser Punkte lässt sich aus einem aktuellen Backup wiederherstellen — wenn es eines gibt. Als JTL Service Partner Gold aus Ahrensfelde bei Berlin richtet die Vlarom E-Commerce Agentur die Backup-Strategie bei jedem Wawi-Onboarding mit ein und prüft sie bei Bestandskunden im Rahmen von Wartungsterminen. Der Aufwand ist überschaubar, die Konsequenz im Notfall hingegen ist es nicht.

JTL-Wawi Datenbank-Backup einrichten: 5 Schritte für ein verlässliches Setup

Die folgenden Schritte unterscheiden sich je nach SQL-Server-Variante. Wer eine Lizenz von SQL Server Standard, Web oder Enterprise nutzt, hat den Server Agent und kann den Wartungsplan im SSMS anlegen. Wer SQL Server Express nutzt — die kostenlose Variante, die JTL bei vielen Kleinkunden installiert — braucht den Aufgabenplanungs-Workaround. Vor jeder strukturellen Änderung an der Datenbank gilt: einmal manuell sichern, bevor du Wartungspläne, neue Indizes oder Restore-Tests anwendest. Die offizielle Doku zur manuellen Sicherung findest du im JTL-Guide zur Datensicherung für JTL-Wawi.

Aktuelles Backup manuell erstellen (Schritt 1)

Bevor du Automatisierung einbaust, lege einmal eine Vollsicherung an. In JTL-Wawi: Start > Datenbank, anmelden, Mandant wählen, unter Mandanten bearbeiten auf Datenbankexport klicken. Die Standardablage ist `c:\\programme\\microsoft sql server\\instanz\\backup` — aus Sicherheitsgründen lässt SQL Server Sicherungen nur in dieses Verzeichnis schreiben. Aktiviere die Option Vor dem Backup Indizes reorganisieren und neu erstellen, das beschleunigt spätere Schreibvorgänge spürbar. Die Datei wird als `.bak` abgelegt. Prüfe danach, dass die Datei tatsächlich existiert und eine plausible Größe hat — eine 0-KB-Datei zeigt einen stillen Fehler an, oft eine fehlende Schreibberechtigung. Diese erste Vollsicherung ist gleichzeitig die Basis für deinen ersten Restore-Test in Schritt 5.

SQL Server Variante prüfen und Strategie wählen (Schritt 2)

Öffne SQL Server Management Studio (SSMS), verbinde dich mit der Wawi-Instanz und schaue oben links unter Server-Name, welche Edition läuft. Express, Web, Standard und Enterprise haben unterschiedliche Möglichkeiten. Express hat keinen SQL Server Agent — der Wartungsplan im SSMS funktioniert dort nicht, du brauchst den Aufgabenplanungs-Workaround. Standard, Web und Enterprise haben den Agent — du kannst Wartungspläne grafisch zusammenklicken und brauchst keine Batch-Datei. Wer auf Express läuft und mehr Headroom braucht (Performance, Datenbankgröße über 10 GB pro Mandant, Anzahl Cores), sollte über ein Upgrade auf eine kostenpflichtige Edition nachdenken — das ist aber ein eigenes Projekt und nicht Voraussetzung für ein automatisches Backup.

Wartungsplan im SSMS einrichten (Standard / Web / Enterprise) (Schritt 3)

In SSMS unter Verwaltung > Wartungspläne, Rechtsklick > Neuer Wartungsplan-Assistent. Wähle als Aufgaben Datenbank sichern (vollständig) und optional Indizes neu organisieren. Wähle die Wawi-Datenbanken aus: `eazybusiness` plus alle `mandant_*`-Datenbanken. Lege als Sicherungsziel ein eigenes Laufwerk oder einen Netzwerkpfad an — nicht die Systempartition. Stelle die Aufgabe auf täglich um drei Uhr morgens, das ist außerhalb der Geschäftszeiten und kollidiert nicht mit Workflow-Aufgaben. Aktiviere Backup-Datei nach Datum benennen, damit nicht jedes Backup das vorherige überschreibt. Trage als Aufbewahrungsdauer mindestens 14 Tage ein. Speichere und prüfe in der Aufgabenhistorie ob der Plan beim ersten Lauf fehlerfrei durchgeht — meistens ist hier das Problem fehlende Schreibrechte des SQL-Server-Dienstkontos auf dem Zielpfad.

Express-Workaround mit sqlcmd und Aufgabenplanung (Schritt 3 alternativ)

Erstelle eine Batch-Datei `jtl-backup.bat` mit dem `sqlcmd`-Befehl `BACKUP DATABASE eazybusiness TO DISK = ‚D:\\backup\\eazybusiness_%date%.bak’`. Wiederhole die Zeile für jeden Mandanten (`mandant_1`, `mandant_2` usw.). Der `%date%`-Platzhalter setzt das aktuelle Datum in den Dateinamen — verschiedene Backups überschreiben sich also nicht. Lege die Batch-Datei und das Zielverzeichnis (`D:\\backup\\` oder ein Netzlaufwerk) vorher manuell an. Der SQL-Server-Dienstbenutzer braucht Schreibrechte auf das Verzeichnis. Öffne dann die Windows-Aufgabenplanung, lege eine neue Aufgabe an, plane sie täglich um drei Uhr und verweise auf die `jtl-backup.bat`. Der detaillierte Workaround-Leitfaden steht im JTL-Guide zur Datensicherung. Ergänze die Batch um eine Aufräum-Routine (z.B. `forfiles /p D:\\backup /d -14 /c \“cmd /c del @file\“`), damit das Laufwerk nicht volläuft.

Restore-Test und externer Speicherort (Schritt 4-5 zusammengefasst)

Ein Backup, das nie wiederhergestellt wurde, ist ein Versprechen ohne Beleg. Nimm ein aktuelles Backup, spiele es auf einem Test-Server oder einer Test-Instanz ein und prüfe ob die Wawi mit der wiederhergestellten Datenbank startet. Der Restore-Befehl in SSMS: Datenbanken > Rechtsklick > Datenbank wiederherstellen, Quelle Gerät, .bak-Datei wählen, Optionen-Tab — bestehende Datenbank überschreiben (WITH REPLACE) — OK. Auf einem Produktivsystem niemals direkt überschreiben, immer in eine separate Test-DB. Für den Restore-Pfad selbst: das physische Backup-Laufwerk kann beim selben Hardware-Defekt verlorengehen wie der SQL Server. Kopiere die `.bak`-Dateien deshalb täglich auf ein NAS, ein zweites Backup-Ziel oder einen externen Speicher. Die offizielle Restore-Doku findest du im JTL-Guide: Datenbank-Backup wieder einspielen. Vor jedem JTL-Update gilt: Backup direkt davor erstellen, nicht das Wartungsplan-Backup von letzter Nacht verwenden — Update-Probleme sind ein klassischer Ernstfall.

Häufige Fragen zum JTL-Wawi Datenbank-Backup

Warum reicht der Datenbankexport in der Wawi nicht aus?

Der Datenbankexport ist eine manuelle Funktion. Du klickst, die Datei entsteht. Sobald die Wawi geschlossen ist, läuft kein Backup mehr. Ein verlässliches Setup braucht eine Aufgabe, die unabhängig von der Wawi-Sitzung täglich läuft. Bei SQL Server Standard übernimmt das der Server Agent, bei Express die Windows-Aufgabenplanung mit `sqlcmd`. Der manuelle Export bleibt nützlich vor JTL-Updates oder Migrationen — als zusätzlicher Sicherheitspunkt vor riskanten Schritten — aber er ersetzt keinen automatischen Wartungsplan.

Beide. `eazybusiness` enthält die Konfiguration, Benutzer, Rechte und plattformübergreifende Einstellungen. Jede `mandant_*`-Datenbank enthält die Geschäftsdaten eines Mandanten — Artikel, Aufträge, Kunden, Bestände. Wenn nur die Mandanten gesichert werden, fehlt nach einem Restore die komplette Verwaltung; wenn nur eazybusiness gesichert wird, fehlen alle operativen Daten. Bei mehreren Mandanten gilt: jeder Mandant einzeln in den Sicherungsplan aufnehmen. Wer einen weiteren Mandanten ergänzt, muss den Plan entsprechend erweitern — das wird gerne vergessen.

SQL Server schreibt aus Sicherheitsgründen nur in den eigenen Backup-Ordner: `c:\\programme\\microsoft sql server\\mssql.X\\mssql\\backup`, wobei X die Instanz-Nummer ist. Wer in ein anderes Verzeichnis sichern will, muss das Zielverzeichnis vorher anlegen und dem SQL-Server-Dienstkonto Schreibrechte geben. Beim Wartungsplan im SSMS oder bei `sqlcmd` lässt sich das Zielverzeichnis frei setzen — vorausgesetzt, die Berechtigungen passen. Ein Händler im JTL-Forum: ‚Mein Backup-Job lief tagelang grün durch, aber die Dateien landeten nie auf dem NAS — der SQL-Service hatte keine Schreibrechte auf den Netzwerkpfad, und SSMS meldete keinen Fehler.‘

Mindestens 14 Tage. Begründung: Bei Datenbank-Korruption fällt das Problem oft nicht am selben Tag auf, sondern erst beim nächsten Geschäftsabschluss oder Quartalsbericht. Wer nur die letzten drei Tage sichert, hat dann keine sauberen Daten mehr. Praxisempfehlung: 14 tägliche Backups plus eine wöchentliche Vollsicherung, die vier Wochen aufgehoben wird. Wer mit empfindlichen Daten oder Buchhaltungspflichten arbeitet, sollte die wöchentlichen Backups extern speichern und mindestens drei Monate aufbewahren — das ist auch DSGVO-relevant für die Nachvollziehbarkeit von Datenständen.

Mindestens einmal pro Quartal. Ein Backup, das nie wiederhergestellt wurde, ist ein Versprechen ohne Beweis. Wir testen bei Wartungskunden quartalsweise einen Restore auf einer Test-Instanz und prüfen, ob die Wawi anschließend mit den wiederhergestellten Daten sauber startet. Der häufigste Fehler im Test: Backup-Datei ist da, aber die `mandant_*`-Datenbank wurde vergessen, weil ein neuer Mandant nicht im Plan ergänzt wurde. Das fällt nur beim Restore-Test auf — und bevor es im Ernstfall auffällt.

Nein, ein Restore erfordert exklusiven Zugriff auf die Datenbank. Alle JTL-Wawi-Sitzungen, der JTL-Worker und ggf. JTL-Shop-Connector-Verbindungen müssen geschlossen sein. Bei einem produktiven Restore: Wartungsfenster ankündigen, alle Wawi-Sitzungen schließen, JTL-Worker stoppen, Restore durchführen, prüfen ob die Datenbank konsistent ist, dann erst die Wawi wieder freigeben. Bei einer Test-Instanz auf einem separaten Server gilt das nicht — dort kannst du parallel zur Produktiv-Datenbank einen Restore-Test fahren. Für Restores in produktive Systeme begleitet die Vlarom E-Commerce Agentur den Vorgang gerne, weil dort ein Bedienfehler die Datenbank zerstören kann.

Direkt vor dem Update ein zusätzliches manuelles Backup ziehen. Das nächtliche Wartungsplan-Backup ist im Zweifel mehrere Stunden alt und enthält nicht die letzten Stunden. Reihenfolge: alle Wawi-Sitzungen schließen, JTL-Worker stoppen, manuelle Vollsicherung über den Datenbankexport oder via SSMS, dann Update starten. Wir empfehlen JTL-Updates ohnehin nicht direkt am Release-Tag — vier bis sechs Wochen Wartezeit lassen Hotfixes und Plugin-Kompatibilitäten reifen. Den Reifungsprozess plus aktuelles Backup zusammen ergibt das Setup, mit dem Updates verlässlich durchgehen.

JTL Service Partner Gold — Wawi-Backup aus der Praxis

Backup-Strategie für deine JTL-Wawi sauber aufsetzen

Wir richten Wartungspläne, Restore-Tests und externe Backup-Kopien für JTL-Wawi-Datenbanken bei mittelständischen Händlern ein. Als Vlarom E-Commerce Agentur, JTL Service Partner Gold aus Ahrensfelde bei Berlin, übernehmen wir Setup, Test und Dokumentation in einem Termin. Ruf uns direkt an unter +49 30 91473862, schreibe an info@vlarom.de oder nutze unser Kontaktformular für eine unverbindliche Ersteinschätzung.