Sonntag-Nacht-Update.
Mit Rollback. Niemand merkt was.
Shopware-Updates sind die häufigste Ursache für „mein Shop ist kaputt”-Anrufe am Montagmorgen. Mein System nimmt Ihnen das ab: Update läuft Sonntag 03:00, bei Fehler kommt der vorherige Stand automatisch zurück, ich kriege Telegram-Alert. Sie merken nichts.
Im Cockpit siehst du jederzeit, ob Updates offen sind und ob SSL & Co. in Ordnung sind. Die nächtlichen Update-Runs mit Snapshot, Smoke-Test und Auto-Rollback — dazu der Montags-Watchdog — laufen bei mir im Hintergrund; jeder Run wird HMAC-signiert vom Shop-Server gemeldet und bleibt dauerhaft nachvollziehbar.
Wie der Sonntag-Update abläuft.
Snapshot vorher
DB-Dump + Files-Tarball auf separatem Backup-Server. Wenn das Update schiefgeht, ist der Stand von 02:55 Uhr in 60 Sekunden wieder da.
Composer + Migrationen
Shopware-Core, Plugin-Updates, Datenbank-Migrationen. Alles als www-data, mit Logs in /var/log/shopware-update/.
Smoke-Test
Storefront muss 200 liefern. Admin-Login muss erreichbar sein. Alle 5 lechweb-Bundles müssen ihre Health-Endpoints grün melden.
Bei Fehler: Auto-Rollback
DB + Files aus Snapshot zurück, Cache-Clear, php-fpm-Restart. Ich bekomme Telegram-Alert, der Shop ist trotzdem schon wieder live.
Bericht ans Cockpit
Update-Run wird HMAC-signiert ans Cockpit gemeldet — ok / rolled_back / failed. Sichtbar in der Update-History, dauerhaft nachvollziehbar.
Was wenn das Update gar nicht stattfindet?
Der Update-Watchdog ist ein zweites Sicherheitsnetz. Er prüft jeden Montag ob jeder gewartete Shop am Sonntag tatsächlich gelaufen ist. So habe ich den Überblick: kein Shop bleibt unbemerkt, falls etwas schief lief.
Wenn ein Update gar nicht stattfindet
Server hat aus war? Skript hat einen Bug? Der Update-Watchdog läuft Montag morgens und prüft ob jeder Shop wirklich gelaufen ist. Falls bei Ihrem Shop was fehlt — ich kümmere mich darum, bevor Sie es überhaupt merken.
Wenn ein Update fehlschlägt
Sofort beim Lauf — nicht erst beim nächsten Tag. Failed = composer-Crash, rolled_back = Smoke-Test fail nach Update. In beiden Fällen ist der Shop sicher (Snapshot wieder live), ich sehe den Error-Log direkt in der Update-History und kontaktiere Sie wenn was zu klären ist.
Wenn alles ok ist
Im Cockpit sehe ich Montag früh auf einer Seite, wo alles grün steht und wo ich noch hinschauen muss. Ihr Shop ist da garantiert dabei — keine Nadel im Heuhaufen, kein vergessener Kunde.
Oft gefragt.
Warum nachts? Ich will doch keine Downtime.
Das Update läuft im Hintergrund während der Composer-Installation. Storefront bleibt erreichbar. Falls etwas brennt: Auto-Rollback ist in 60 Sekunden durch. Reale Downtime: 0 Sekunden im Normalfall, max. 60 Sekunden im Worst Case.
Was passiert wenn ich gerade Bestellungen habe?
Sonntag 03:00 Nacht ist der traffic-ärmste Zeitpunkt der Woche (Branchen-Standard für Maintenance-Windows). Composer arbeitet on-disk in vendor/ ohne die laufende DB zu blockieren. Bestellungen während des Updates bleiben in der DB — sie werden nach dem Update normal verarbeitet.
Was ist wenn das Rollback selber nicht klappt?
Theoretisch möglich, praktisch nie passiert weil DB-Restore via mysqldump und Files via tar -xzf — beides battle-tested. Falls doch: ich bekomme Telegram-Alert, schalte mich in 5–60 Min ein (je nach Tageszeit) und repariere manuell. In der Zwischenzeit ist auch dann der Shop nicht „kaputt”, nur das Update ist halt nicht durch.
Wie lange werden die Snapshots aufbewahrt?
Die letzten 4 Snapshots bleiben auf dem Shop-Server (typisch 4 Wochen Rückgriff). Zusätzlich liegt das tägliche Backup vom γ.1-Backup-System auf separatem IONOS-Hub für 7 Tage / 4 Wochen / 6 Monate.
Sicherheits-Modul ist in Standard + Komfort drin.
Standard 49 €/Monat · Komfort 79 €/Monat. Beide monatlich kündbar.