Alles, was Sie wissen sollten bevor Sie installieren.
Ein detaillierter Blick darauf, wie Shopware 6 Backup Plugin — DfBackup SW: Datenbank + Dateien, AES-256-Verschlüsselung, S3/FTP/Dropbox, 1-Klick-Wiederherstellung funktioniert, warum wir es so gebaut haben und der Gedanke hinter den Funktionen oben.
Ein echtes Shopware-Backup, kein zusammengeflicktes Skript
Die meisten Shopware-Backup-Lösungen rufen einfach mysqldump auf und packen den Ordner — was in der Produktion drei Probleme verursacht: mysqldump ist auf vielen Shared Hostings nicht verfügbar, shell_exec ist häufig deaktiviert, und unverschlüsselte Archive auf der Festplatte sind im Kompromittierungsfall eine Zeitbombe. DfBackup SW löst alle drei Punkte: Pure-PHP-Datenbankdump via DBAL, Archivierung via ZipArchive und optionale authentifizierte AES-256-Verschlüsselung mit Benutzer-Passphrase. Alles funktioniert ohne besondere Sysadmin-Konfiguration, auf Shared Hosting wie auf einem VPS.
Ein Dump, der das Shopware-Schema versteht
Ein naiver SQL-Dump scheitert an Shopware: Die Primärschlüssel sind BINARY-16-UUIDs, die als hexadezimale Literale ausgegeben werden müssen, manche Spalten sind generiert (STORED oder VIRTUAL) und dürfen nie in INSERTs erscheinen, und Views müssen nach den Tabellen neu erstellt werden. DfBackup SW behandelt all das nativ: SHOW-FULL-COLUMNS-Inspektion pro Tabelle, Ausschluss generierter Spalten, Hex-Kodierung von Binärspalten, Keyset-Pagination auf Integer-Primärschlüsseln für große Tabellen (order, log_entry) und Views zuletzt. Die erzeugte Datei lässt sich sauber reimportieren, Anweisung für Anweisung, mit deaktiviertem FOREIGN_KEY_CHECKS während des Imports.
AES-256 mit HMAC: Encrypt-then-MAC richtig gemacht
Das Encrypt-then-MAC-Muster ist der empfohlene Standard für symmetrische Verfahren: Zuerst wird verschlüsselt, dann ein HMAC über den Ciphertext berechnet. Beim Lesen wird der HMAC vor dem Entschlüsseln geprüft — Schutz vor Bit-Flip- und Padding-Oracle-Angriffen. Die Benutzer-Passphrase durchläuft PBKDF2-SHA256 mit 120000 Iterationen, um getrennte Verschlüsselungs- und HMAC-Schlüssel abzuleiten. Die Verschlüsselung erfolgt im Streaming in 1-MiB-Blöcken mit manueller CBC-Verkettung: Ein 5-GB-Archiv verschlüsselt sich mit demselben Speicherbedarf wie ein 50-MB-Archiv. Das Binärformat (Magic-Header, Salt, IV, HMAC, Ciphertext) ist dokumentiert und auditierbar.
Natives S3 SigV4: Multipart, MinIO, R2, OVH, Scaleway, Wasabi, B2
Statt das offizielle AWS-SDK mitzuliefern, implementiert DfBackup SW AWS Signature V4 direkt in cURL. Null zusätzliche Composer-Abhängigkeiten, eine kanonische Signatur, kompatibel mit jedem S3-sprechenden Dienst. Sie können das Plugin auf Amazon S3 richten, auf MinIO auf Ihrem eigenen VPS, auf Cloudflare R2 (10 GB gratis, null Egress-Kosten — ideal für Backups), OVH Object Storage, Scaleway, Wasabi oder Backblaze B2 — nur Endpoint und Region ändern. Ab 100 MB schaltet der Upload automatisch auf Multipart mit 10-MB-Parts um, sodass mehrere Gigabyte ohne Speichererschöpfung übertragen werden.
Push-Replikation: ein nächtliches Staging ohne Sysadmin-Arbeit
Das ist das Feature, das DfBackup SW auszeichnet: jedes Backup zu einer zweiten Shopware-Installation schieben. Plugin auf Produktion und Staging installieren, gemeinsames Secret teilen, Replikation als Ziel aktivieren. Bei jedem Backup — manuell oder geplant — wird das Archiv in 8-MB-Chunks mit HMAC-SHA-256-Signatur zu dedizierten Endpoints auf dem Ziel hochgeladen, mit Zeitstempel-Anti-Replay bei 5 Minuten Toleranz. Ist Auto-Restore auf dem Ziel aktiviert, wird das Backup automatisch angewendet — Ihr Staging spiegelt am nächsten Morgen die Produktion des Vortags. Kombiniert mit der Domain-Migration ist der Klon sofort unter seiner eigenen Domain erreichbar. Kein rsync, keine Sysadmin-Cron-Skripte mehr.
1-Klick-Wiederherstellung mit Sicherheitsnetz
Eine Wiederherstellung ist die riskanteste Operation im Lebenszyklus eines Shops: Die Live-Datenbank wird überschrieben, Dateien werden ersetzt, und wenn etwas schiefgeht, ist der Rollback komplex. DfBackup SW fügt ein automatisches Sicherheitsnetz hinzu: Vor jeder Wiederherstellung wird still ein geschützter Datenbank-Snapshot erstellt. Scheitert die Wiederherstellung auf halbem Weg, stellen Sie diesen Snapshot wieder her und sind in Minuten zurück im Ausgangszustand. Die Plugin-Tabellen werden bei einer Wiederherstellung nie überschrieben — Ihr Backup-Verlauf bleibt erhalten, selbst wenn Sie eine sechs Monate alte Version wiederherstellen. Die explizite Bestätigung (RESTORE eintippen) verhindert versehentliche Klicks.
Messenger, ScheduledTask und Web-Cron: Hintergrund auf die Shopware-Art
DfBackup SW baut auf der nativen Shopware-Infrastruktur auf: Backups werden als asynchrone Symfony-Messenger-Nachrichten dispatcht und vom Worker ausgeführt, ohne Admin oder Storefront zu blockieren. Eine native ScheduledTask prüft alle 10 Minuten, ob ein geplantes Backup fällig ist (daily, weekly oder monthly, Zielstunde, 30-Minuten-Fenster, 60-Minuten-Deduplizierung). Für Hostings ohne System-Cron oder dauerhaften Worker übernimmt eine token-signierte Web-Cron-URL: Rufen Sie die URL alle 10 bis 15 Minuten von cron-job.org oder Ihrem Monitoring auf, das interne Planungstor erledigt den Rest. Das Administrationsmodul zeigt den Fortschritt live mit 15 abgefragten Meilensteinen.
Audit-Log, Warnungen und Benachrichtigungen: Verteidigung in der Tiefe
Drei sich ergänzende Mechanismen, damit kein Backup unbemerkt verloren geht. Das Audit-Log protokolliert jede sensible Aktion (Start, Wiederherstellung, Löschung, Prüfung, Download) mit Admin-Benutzer, IP und Zeitstempel. Die modulinterne Warnung schlägt an, wenn das letzte erfolgreiche Backup älter als N Tage ist. Benachrichtigungen gehen per E-Mail (Symfony Mailer, Erfolg oder Fehler nach Wahl) und per Webhook mit Format-Autoerkennung raus: Slack, Discord, Microsoft Teams oder generisches JSON für Ihre eigenen Integrationen.
Es gibt noch keine Rezensionen.