Datensicherung von JTL-Wawi automatisieren
Wie du Backups zuverlässig planst und ohne Zusatztools ausführst
TL;DR: Automatisierte JTL-Wawi Backups sind zuverlässig, wenn du sie per sqlcmd oder PowerShell ausführst, über die Aufgabenplanung zeitgesteuert laufen lässt und Backups nicht nur lokal speicherst. Mit Rotation, sauberem Logging und regelmäßigen Restore-Tests stellst du sicher, dass die Sicherungen im Ernstfall wirklich funktionieren – auch ohne SSMS.
Backups sind ein Prozess, kein Einmal-Klick.
Mit einer automatisierten Datensicherung schützt du deine JTL-Wawi-Daten im Alltag – planbar, nachvollziehbar und ohne SSMS. Entscheidend sind Offsite-Ziel, Rotation und Tests, damit das Backup im Ernstfall wirklich nutzbar ist.
Warum automatisierte Backups für JTL-Wawi Pflicht sind
Automatisierte Backups verhindern „vergessene Sicherungen“ und machen Wiederherstellung planbar, weil sie regelmäßig, nachvollziehbar und ohne manuelle Schritte laufen.
In JTL-Wawi stecken deine zentralen Geschäftsdaten: Artikel, Preise, Bestellungen, Kunden und Lagerbewegungen. Manuelle Sicherungen funktionieren am Anfang oft noch, werden im Alltag aber schnell vergessen oder uneinheitlich durchgeführt.
Mit einer automatisierten Datensicherung entstehen Backups in einem festen Rhythmus. Das reduziert das Risiko bei Serverausfällen, fehlerhaften Updates oder versehentlichen Änderungen an der Datenbank.
Gerade wenn Datenmengen wachsen oder mehrere Arbeitsplätze beteiligt sind, brauchst du eine Lösung, die unabhängig von Personen funktioniert: geplant, dokumentiert und prüfbar. Genau dafür ist eine stabile Warenwirtschaftssysteme-Strategie mit klaren Prozessen wichtig.
Voraussetzungen: Rechte, Zielpfad und Offsite-Strategie
Du brauchst SQL-Rechte für BACKUP DATABASE, Schreibrechte auf den Zielpfad und mindestens ein Offsite-Ziel (NAS/Cloud/anderer Server), damit das Backup auch bei Totalausfall hilft.
Für automatisierte Backups brauchst du kein SSMS. Technisch reicht ein Skript, das den SQL Server per Kommandozeile anspricht (z. B. sqlcmd oder PowerShell) und eine Sicherungsdatei erstellt.
Entscheidend sind die Basics, sonst scheitert die Automatisierung still: Der ausführende Benutzer benötigt SQL-Berechtigungen für die Sicherung und Schreibrechte auf das Zielverzeichnis. Wenn du auf ein Share sicherst oder hochlädst, kommen Netzwerk- und Zugriffsrechte dazu. Sobald Offsite-Ziele, Shares oder weitere Systeme beteiligt sind, wird eine saubere Schnittstellen- und Systemintegration besonders wichtig.
Wichtig ist außerdem der Speicher- und Aufbewahrungsplan: Wie viele Backups willst du vorhalten (z. B. 7/14/30 Tage) und wie läuft die Rotation? Ohne Rotation füllt sich das Volume irgendwann – und das nächste Backup scheitert genau dann, wenn du es brauchst.
Und bitte nicht unterschätzen: Ein Backup nur auf dem gleichen Server ist kein echtes Notfallkonzept. Plane mindestens ein Offsite-Ziel ein, sonst bist du bei Ransomware oder Hardware-Defekt schnell blank.
Backup per Skript: sqlcmd/PowerShell, Naming und Upload
Ein gutes Backup-Skript erzeugt eine eindeutig benannte .bak-Datei, prüft den Erfolg, schreibt Logs und überträgt die Sicherung optional auf ein Offsite-Ziel.
Sicherung per Kommandozeile ausführen
Das Skript ruft den SQL Server direkt auf und erstellt eine vollständige Sicherungsdatei deiner JTL-Wawi-Datenbank. Du steuerst dabei Datenbankname, Zielpfad und Dateiname über Variablen, damit das Setup wartbar bleibt.
Optional lädst du die erzeugte Datei auf ein Offsite-Ziel (z. B. FTP/SFTP, NAS, anderer Server). So liegt das Backup nicht nur lokal vor, sondern bleibt auch bei Serverproblemen verfügbar.
Wichtig: Passe die rot markierten Variablen im Skript (Zugangsdaten, Pfade, Server) an deine Umgebung an. Vermeide nach Möglichkeit harte Passwörter im Klartext und nutze stattdessen geschützte Credentials. Für dauerhaft saubere Skripte und Datenflüsse lohnt sich außerdem ein klar strukturiertes Content- und Konfigurationsmanagement.
@echo off
setlocal
:: Alte Backups löschen (älter als 14 Tage)
forfiles /p "c:\backups" /s /m *.* /c "cmd /c Del @path" /d -14
:: Datum im Format YYYY-MM-DD setzen
set zeitstempel=%date:~-4%-%date:~3,2%-%date:~0,2%
:: Backup der Datenbank erstellen
sqlcmd -S (local)\JTLWAWI -U backup_user -P [PLATZHALTER: passwort] -Q "BACKUP DATABASE eazybusiness TO DISK = 'c:\backups\bak_%zeitstempel%.bak' WITH COMPRESSION"
:: Sicherstellen, dass das Backup erstellt wurde, bevor es hochgeladen wird
if exist "c:\backups\bak_%zeitstempel%.bak" (
echo Upload starten ...
curl -u [PLATZHALTER: user]:[PLATZHALTER: pass] -T "c:\backups\bak_%zeitstempel%.bak" ftp://[PLATZHALTER: host]/
echo Upload abgeschlossen.
) else (
echo FEHLER: Backup-Datei wurde nicht gefunden!
)
endlocal
Zeitplanung ohne SSMS: Windows Aufgabenplanung korrekt setzen
Nutze die Windows Aufgabenplanung so, dass der Task unabhängig von einer Anmeldung läuft, mit festen Zeiten, klaren Rechten und sauberem Logging.
Damit das Backup wirklich automatisch läuft, legst du in der Windows Aufgabenplanung einen Task an, der das Skript in einem festen Rhythmus ausführt. Bei SQL Server Express ist das der Standardweg, weil der SQL Agent fehlt.
Plane Sicherungen typischerweise außerhalb der Hauptarbeitszeiten. So vermeidest du Konflikte mit laufenden Prozessen in JTL-Wawi und reduzierst Lastspitzen auf Server und Datenbank.
Achte in der Aufgabenplanung besonders auf diese Punkte:
- Task läuft „unabhängig von der Benutzeranmeldung“
- Ausführung mit passenden Rechten (SQL + Zielpfad/Share)
- Start in einem festen Arbeitsverzeichnis, damit Pfade stabil sind
- Exit-Codes und Output werden geloggt (sonst übersiehst du stille Fehler)
Wenn du das einmal sauber einrichtest, läuft die Sicherung dauerhaft ohne zusätzliche Tools. Genau das ist das Ziel: reproduzierbar, planbar und ohne Handarbeit. Für die Überwachung solcher Jobs ist ein schlankes Reporting & Analyse im Alltag sehr nützlich.
Praxis-Tipps: Rotation, Logging und Restore-Tests
Ein Backup ist erst dann „gut“, wenn Rotation aktiv ist, Logs täglich geprüft werden und du mindestens gelegentlich einen Restore testest.
Automatisierung bringt nur dann Sicherheit, wenn du auch Kontrolle einbaust. Prüfe regelmäßig, ob neue Sicherungsdateien entstehen und ob Größe und Timestamp plausibel sind. Ein Backup, das still fehlschlägt, sieht im Ernstfall genauso aus wie „kein Backup“.
Setze ein klares Aufbewahrungsmodell um: zum Beispiel 14 Tage lokal + 30 Tage Offsite. Das senkt Risiko und verhindert, dass dir Speicherplatz ausgeht. Für viele Setups ist eine einfache Rotation per forfiles ein guter Start.
Die häufigsten Fehlerquellen in der Praxis:
- fehlende Schreib- oder SQL-Rechte
- zu wenig Speicherplatz im Zielpfad
- Task läuft nur „bei Anmeldung“ oder startet im falschen Verzeichnis
- Upload scheitert, weil Netzwerk/Firewall/Credentials nicht passen
Der wichtigste Punkt bleibt der Restore-Test: Plane gelegentlich einen Rücksicherungs-Test in eine Testumgebung ein. Alternativ kannst du wenigstens Integritätschecks nutzen, aber ein echter Restore ist die zuverlässigste Bestätigung. Damit solche Prozesse sauber zusammenspielen, sind stabile Warenwirtschafts- und Betriebsprozesse entscheidend.
Wenn du Rotation, Logging und Tests kombinierst, wird Datensicherung zu einem stabilen Prozess – und nicht zu einer Hoffnung, dass „schon alles passt“.
Häufige Fragen zur automatisierten JTL-Wawi Datensicherung
Über Frank Dahmen
Frank Dahmen beschäftigt sich seit den Anfängen des Internetzeitalters Mitte der 1990er Jahre intensiv mit Webentwicklung und Programmierung. Seine langjährige Erfahrung reicht von klassischen Webtechnologien bis hin zu modernen Software- und Systemarchitekturen. Besondere Interessen liegen in den Bereichen IT-Security und Künstliche Intelligenz, er greift aber auch gerne andere Themen rund um das IT-Geschehen auf.
Weiterführende Beiträge
Unsere Lösungen für dich – passend zum Thema
Wir zeigen dir, welche Lösung technisch sinnvoll ist und langfristig funktioniert.