JTL-Wawi Backup: SQL-Server-Sicherung, NAS und Cloud — welche Methode für deinen Betrieb passt

Auf einen Blick

• ✓JTL-Wawi auf eigenem Server braucht einen automatisierten SQL Server Wartungsplan — manuelle Exporte reichen nicht. SQL Server Standard erlaubt Maintenance Plans direkt im SSMS, Express-Edition-Nutzer bauen einen Windows-Aufgabenplaner-Job mit sqlcmd als Workaround.
• ✓NAS als zweite Schicht (Synology, QNAP) schützt vor lokalem Hardware-Ausfall, nicht vor Ransomware oder Brand — deshalb gilt die 3-2-1-Regel: drei Kopien, auf zwei verschiedenen Trägern, eine davon außerhalb des Serverraums.
• ✓Wawi-Erkenntnis aus Cloud-Projekten: ecomDATA sichert die Datenbank alle zehn Minuten — das deckt 99 Prozent der Crash-Szenarien zuverlässig ab. Was es nicht deckt: einen schnellen Self-Service-Restore und Aufbewahrung über mehrere Monate für Audit-Anforderungen.
• ✓Kein Backup ist vollständig ohne Restore-Test. RESTORE VERIFYONLY bestätigt nur die Lesbarkeit einer .bak-Datei — nicht ob die Datenbank danach sauber hochkommt. Wir empfehlen einen echten Test-Restore auf einem zweiten System einmal pro Quartal.

Die häufigste Situation die wir bei neuen JTL-Wawi-Kunden antreffen: kein automatisches Backup, nur ein manueller Export der irgendwann vor Monaten erstellt wurde. Oder bei Cloud-Kunden: das Vertrauen auf ecomDATA ohne zu wissen, wie ein Restore konkret abläuft. Bei der Vlarom E-Commerce Agentur richten wir Backup-Strategien für On-Premise-Server mit SQL Server Wartungsplänen und NAS-Anbindung ein, und wir begleiten Cloud-Kunden durch den ecomDATA-Restore-Prozess aus realen Fällen. Als JTL Service Partner Gold aus Ahrensfelde bei Berlin decken wir beide Szenarien — lokaler Server und Cloud — aus demselben Beratungsansatz heraus: Was passiert im Notfall, und wie schnell kommt der Betrieb wieder hoch?

Die ersten vier Schritte gelten für alle JTL-Wawi-Installationen — ob On-Premise oder Cloud. Sie zeigen, welche Methode für welche Situation passt und wie man den Restore-Test umsetzt, der fast überall fehlt. Die Schritte fünf bis neun gehen tiefer in die Cloud-Besonderheiten, besonders wenn die Wawi über ecomDATA betrieben wird. Wer die Wawi ganz in die Cloud verlagern möchte, findet die Einrichtung auf unserer Seite zum JTL-Wawi in der Cloud.

Wer JTL-Wawi auf einem eigenen Server betreibt, braucht einen automatisierten Backup-Job. Der SQL Server legt die Wawi-Daten in zwei Datenbanken ab: `eazybusiness` (Hauptdatenbank) und `mandant_X` je nach Mandantenzahl. Beide müssen gesichert werden. SQL Server Standard und höher: Im SQL Server Management Studio (SSMS) unter Management > Maintenance Plans einen neuen Wartungsplan anlegen. Drei Backup-Typen stehen zur Wahl. Full Backup sichert die komplette Datenbank — das ist die Basis. Differenzielles Backup sichert nur die Änderungen seit dem letzten Full Backup und läuft deutlich schneller. Transaction Log Backup ermöglicht Point-in-Time-Recovery, setzt aber das Wiederherstellungsmodell FULL voraus (nicht SIMPLE). Für die meisten Händler reicht ein tägliches Full Backup außerhalb der Geschäftszeiten plus ein differenzielles Backup alle zwei Stunden. Speicherort im Wartungsplan: lokal auf eine separate Festplatte, nicht auf dieselbe Festplatte auf der auch die Datenbank liegt. Aufbewahrung: die letzten 14 Tage täglich, ein monatlicher Stand für mindestens drei Monate aufbewahren. SQL Server Express hat keinen SQL Server Agent und damit keine Maintenance Plans. Die Alternative: eine .bat-Datei mit `sqlcmd -S (local)\\JTLWAWI -Q \“BACKUP DATABASE eazybusiness TO DISK = ‚D:\\backup\\jtl_%date%.bak’\“` die über den Windows-Aufgabenplaner täglich ausgeführt wird. Mehr zur SQL-Server-Wartung für JTL-Wawi gibt es im JTL-Guide Tipps zur SQL-Server-Wartung.

Ein lokales Backup schützt vor Festplattenausfall, aber nicht vor Brand, Diebstahl oder Ransomware. Deshalb gehört eine zweite Schicht außerhalb des Servers in jede Backup-Strategie. Das bewährteste Modell ist ein NAS im selben Netzwerk (Synology DS-Serie oder QNAP), das die .bak-Dateien vom SQL Server täglich abruft oder direkt als Backup-Ziel fungiert. Technisch gibt es dabei einen Haken: Der SQL Server läuft unter einem Windows-Dienstkonto, das standardmäßig keinen Zugriff auf Netzwerkpfade hat. Zwei Varianten funktionieren zuverlässig. Variante 1 (direkter UNC-Pfad im Wartungsplan): Das SQL-Server-Dienstkonto bekommt Schreibrechte auf den NAS-Share, dann kann der Wartungsplan direkt in `\\\\nas-name\\sqlbackup\\jtl-wawi\\` schreiben. Variante 2 (lokales Backup + Robocopy): SQL Server sichert lokal, ein Windows-Aufgabenplaner-Job kopiert die Dateien anschließend per Robocopy auf das NAS. Die zweite Variante ist weniger elegant, aber robuster — weil ein NAS-Ausfall den Backup-Job nicht blockiert. Empfehlung für die Aufbewahrung: täglich Full Backup auf dem NAS, Aufbewahrung 14 Tage, monatlicher Stand für sechs Monate. Wichtig: Das NAS allein ist keine offsite-Kopie — bei Brand oder Ransomware liegt es im selben Raum wie der Server. Die 3-2-1-Regel bedeutet drei Kopien, zwei verschiedene Medien, eine außerhalb des Standorts. Das erreicht man mit NAS plus Cloud-Storage (z.B. Synology Hyper Backup auf einen externen S3-Bucket) oder mit einem USB-Festplatten-Wechselsystem das regelmäßig außer Haus geht.

Wer JTL-Wawi über ecomDATA in der Cloud betreibt, bekommt das Datenbank-Backup vom Anbieter automatisch mitgeliefert: ecomDATA sichert die Datenbank im 10-Minuten-Takt. Das ist für Standard-Crash-Szenarien sehr gut — ein Datenbank-Crash um 14:23 Uhr lässt sich auf den Stand von 14:20 Uhr zurücksetzen. Was das Cloud-Backup nicht abdeckt: Datenstände die älter als die Aufbewahrungsfrist sind (die genaue Dauer ist bei ecomDATA nicht öffentlich standardisiert — per Support-Anfrage klären), Self-Service-Zugriff auf Backup-Dateien (kein direkter Download einer .bak-Datei), und Konfigurationsdateien die außerhalb der Wawi-Datenbank liegen. Ein Restore läuft ausschließlich über ein Ticket im ecomDATA-Kundencenter unter `my.ecomdata.de/supporttickets.php`. Das Ticket sollte von Anfang an vollständige Informationen enthalten: Mandanten-ID, Cloud-Instanz, exakter Ziel-Zeitpunkt und Grund (z.B. Datenverlust durch fehlerhaften Massenimport). Rückfragen-Schleifen verlängern die Restore-Zeit. Das Cloud-Backup von ecomDATA ist für den laufenden Betrieb ausreichend — für Langzeit-Archivierung über mehrere Monate und für Restore-Punkte vor JTL-Updates braucht es ergänzende manuelle Exporte, die in Schritt 7 beschrieben sind. Hintergrund zur Wawi-Cloud-Architektur liefert der JTL-Guide zur Wawi Cloud.

Ein Backup das nie getestet wurde, ist kein Backup. Das ist keine Übertreibung: defekte .bak-Dateien, falsch konfigurierte Speicherpfade oder SQL-Server-Inkompatibilitäten fallen erst beim Restore auf — wenn der Druck hoch und die Zeit knapp ist. Zwei Ebenen des Restore-Tests haben sich bewährt. Ebene 1 — RESTORE VERIFYONLY: Dieser SQL-Befehl prüft ob die .bak-Datei lesbar und intern konsistent ist. Im SSMS ausführen: `RESTORE VERIFYONLY FROM DISK = ‚D:\\backup\\jtl-eazybusiness.bak’`. Er schlägt an wenn die Datei korrupt oder unvollständig ist. Was er nicht prüft: ob die Datenbank nach dem Restore sauber hochkommt. Deshalb ist er als Routinecheck nützlich, aber kein Ersatz für den echten Test. Ebene 2 — Echter Test-Restore auf zweitem System: Einmal pro Quartal das aktuellste Full Backup auf ein Testsystem (zweite SQL-Server-Instanz, Test-VM) einspielen und prüfen ob JTL-Wawi sich damit verbindet und Basisfunktionen laufen. Das dauert 30-60 Minuten — und verhindert das böse Erwachen wenn es darauf ankommt. Für ecomDATA Cloud-Kunden: beim Support anfragen ob ein Test-Restore auf einen bestimmten Zeitpunkt möglich ist. Die Antwortzeit des Supports und die Qualität der Rückmeldung zeigen, wie ein echter Notfall-Restore laufen würde.

Im JTL-Guide zur Wawi Cloud steht: ecomDATA sichert die Datenbank im 10-Minuten-Takt. Das bedeutet: Wenn die Datenbank um 14:23 Uhr crasht, kann ecomDATA dich auf den Stand von 14:20 Uhr zurücksetzen. Das ist sehr gut. Was darin nicht enthalten ist: einzelne Dateien außerhalb der Datenbank (Drucker-Vorlagen, externe Bild-Pfade, Konfigurationsdateien außerhalb des Wawi-Kontexts), ältere Stände als die letzten Tage (genaue Aufbewahrung steht nicht in der Doku — frage explizit beim Support nach), und ein Self-Service-Zugriff auf die Backup-Dateien. Wer detaillierte Zahlen zur Aufbewahrungsdauer braucht, sollte sie schriftlich vom ecomDATA-Support bestätigen lassen, bevor er auf das Cloud-Backup als alleinige Strategie setzt. Mehr zur Cloud-Architektur findest du im JTL-Guide zur Wawi Cloud.

Ein Restore in der JTL-Wawi Cloud läuft über ein Support-Ticket bei ecomDATA: Login im Kundencenter unter `my.ecomdata.de`, Bereich Supporttickets öffnen, neues Ticket anlegen, Restore-Anforderung mit Ziel-Zeitpunkt schreiben (z.B. „Restore auf den Stand von gestern 18:00 Uhr“). Der Support setzt das dann manuell um. Wichtig: Das Ticket sollte alle relevanten Informationen direkt enthalten — Mandanten-ID, Cloud-Instanz, exakter Ziel-Zeitpunkt, Grund (z.B. Datenkorruption, fehlerhafte Buchung). Im Notfall vermeidet das Rückfragen-Schleifen. Probiere den Prozess einmal außerhalb des Notfalls aus, indem du beim Support eine Test-Anfrage stellst, ob ein Restore auf einen bestimmten Zeitpunkt möglich ist. Du musst das nicht durchziehen — die Antwort sagt dir aber, wie schnell der Support reagiert und welche Daten er braucht.

Vor JTL-Wawi-Updates, vor strukturellen Änderungen wie Mandanten-Migrationen, vor großen Ameise-Importen oder vor Bestand-Sanierungen: einmal manuell exportieren. In JTL-Wawi unter Start > Datenbank > Datenbankexport klicken (siehe JTL-Guide zur Datensicherung). Die Datei wird in deine Wawi-Cloud-Instanz geschrieben. Lade sie über die ecomDATA-Cloud-Schnittstelle (RDP-Sitzung oder File-Transfer im Cloud-Launcher) herunter und kopiere sie auf einen lokalen Speicher. Damit hast du einen definitiven Restore-Punkt, der nicht vom ecomDATA-Support abhängt. Bei JTL-Updates empfehlen wir ohnehin vier bis sechs Wochen Wartezeit nach dem Release — der manuelle Export plus die Wartezeit ergeben das stabile Update-Setup.

ecomDATA hält Backups einige Tage bis Wochen vor — die genaue Frist ist nicht standardisiert dokumentiert. Wer Buchhaltungsdaten oder DSGVO-relevante Datenstände länger archivieren muss, braucht eine eigene Kopie. Empfehlung: Einmal pro Monat einen manuellen Export ziehen und auf einem externen Speicher (NAS, Cloud-Storage, USB-Festplatte) ablegen. Bei B2B-Händlern mit Steuerberater-Audit lohnt es sich, diesen Monats-Snapshot für mindestens drei Monate aufzubewahren — bei einer steuerlichen Prüfung kann der Berater dann den Datenstand zum Stichtag nachvollziehen. Diese externen Kopien sind kein Konkurrenzprodukt zum ecomDATA-Backup, sondern eine zweite Schicht für lange Aufbewahrung.

Schreibe in eine kurze Notiz, die alle Wawi-Verantwortlichen kennen: Im Notfall — wer macht das Ticket, welche Daten gehören rein, wo liegen die manuellen Backups, wer im Team hat die ecomDATA-Login-Daten. Diese Notiz gehört in dein internes Dokumentations-Tool (Confluence, Notion, ein internes Wiki) oder als ausgedruckter A4-Zettel ins Server-Schrank-Fach. Im Notfall — Datenbank korrupt, niemand kann sich anmelden — verlierst du sonst Zeit beim Suchen der Cloud-Kontodaten oder beim Klären, wer den Support kontaktiert. Die Vlarom E-Commerce Agentur dokumentiert diesen Eskalationspfad mit Cloud-Kunden im Onboarding-Termin und liefert eine Vorlage, die nur noch ausgefüllt werden muss.

Autor

Alexander Luft

JTL Service Partner Gold · Vlarom E-Commerce Agentur · Ahrensfelde bei Berlin