DfBackup SW — Vollständige Anleitung

DfBackup SW ist ein produktionsreifes Backup-System für Shopware 6.5, 6.6 und 6.7 ohne externe Abhängigkeiten: kein mysqldump, kein shell_exec, kein Amazon-SDK. Es sichert Datenbank und Dateien in reinem PHP, verschlüsselt Archive mit authentifiziertem AES-256, lädt sie zu Local, S3, FTP oder Dropbox hoch und kann jedes Backup sogar zu einem zweiten Shopware-Staging replizieren. Die Wiederherstellung erfolgt mit einem Klick, mit automatischem Sicherheits-Snapshot. Diese Anleitung behandelt Installation, Hintergrundausführung, Verschlüsselung, Storage-Backends, Replikation, Wiederherstellung, Planung und Fehlerbehebung.

Installation

1. Laden Sie das Archiv DfBackup-SW-1.0.0.zip aus Ihrem DataFirefly-Konto herunter.
2. Kopieren Sie den entpackten Ordner DfBackup in custom/plugins/ Ihrer Shopware-Installation, oder installieren Sie das ZIP über Administration → Erweiterungen → Meine Erweiterungen → Erweiterung hochladen.
3. Installieren und aktivieren:

   bin/console plugin:refresh
   bin/console plugin:install --activate DfBackup
   bin/console cache:clear

4. Bei der Installation erstellt das Plugin seine vier Tabellen (df_backup, df_backup_log, df_backup_filemap, df_backup_audit) und registriert seine ScheduledTask.

Wo Sie das Plugin in der Administration finden

Nach der Aktivierung erscheint ein eigenes Administrationsmodul DfBackup im Menü. Es bündelt die Backup-Liste, den Button Jetzt sichern, den Echtzeit-Fortschritt und die Aktionen pro Backup (prüfen, herunterladen, schützen, wiederherstellen, löschen). Die Konfiguration (Planung, Verschlüsselung, Backends, Replikation, Benachrichtigungen) erfolgt in der Plugin-Konfiguration über Erweiterungen → Meine Erweiterungen → DfBackup → ⋯ → Konfigurieren.

Hintergrundausführung: Messenger, ScheduledTask und Web-Cron

Ein Backup blockiert nie die Oberfläche. Der Klick auf Jetzt sichern reserviert eine Zeile, dispatcht eine asynchrone Symfony-Messenger-Nachricht und gibt die ID sofort zurück. Die eigentliche Arbeit läuft im Worker, und die Administration zeigt den Fortschritt live über 15 Meilensteine (Start, Datenbankdump, Archivierung, Verschlüsselung, Prüfsumme, Upload pro Backend, Rotation).

Empfohlener Worker in der Produktion

Für Produktivshops lassen Sie einen dauerhaft überwachten Messenger-Consumer laufen:

bin/console messenger:consume async --time-limit=300 --memory-limit=512M

Stellen Sie ihn unter systemd oder supervisor, damit er automatisch neu startet. Das ist die Konfiguration, die Backups ohne jedes Web-Zeitlimit ausführen lässt.

ScheduledTask

Eine native ScheduledTask läuft alle 10 Minuten und dient als Planungstor: Sie prüft, ob ein geplantes Backup fällig ist, und dispatcht gegebenenfalls die Nachricht. Sie hängt vom Shopware-Scheduler ab, der wiederum vom Worker oder vom Shopware-Cron angetrieben wird.

Fallback-Web-Cron

Auf Hostings ohne CLI-Zugang oder dauerhaften Worker aktivieren Sie den Web-Cron: eine token-signierte URL (aus der Konfiguration neu generierbar), die ein externer Dienst wie cron-job.org alle 10 bis 15 Minuten aufruft. Das interne Planungstor (30-Minuten-Fenster, 60-Minuten-Deduplizierung) verhindert Doppelauslösungen.

Der Datenbankdump, gebaut für Shopware

Ein naiver SQL-Dump scheitert an Shopware. DfBackup SW behandelt die Besonderheiten des Schemas nativ:

• Generierte Spalten (STORED oder VIRTUAL) werden aus den INSERTs ausgeschlossen, weil MySQL Schreibzugriffe darauf verweigert.
• Binärspalten — einschließlich der in Shopware allgegenwärtigen BINARY-16-UUID-Primärschlüssel — werden als hexadezimale 0x…-Literale ausgegeben, für einen perfekt originalgetreuen Reimport.
• Die Keyset-Pagination auf dem Integer-Primärschlüssel erlaubt es, sehr große Tabellen (order, log_entry) ohne Speichererschöpfung zu dumpen.
• Views werden zuletzt erstellt, nach allen Tabellen.

Der Dump erfolgt in Blöcken (500 Zeilen pro Batch) und die erzeugte Datei reimportiert sauber, Anweisung für Anweisung, mit deaktiviertem FOREIGN_KEY_CHECKS während des Imports.

Das Datei-Backup

Dateien werden via ZipArchive mit konfigurierbaren Glob-Ausschlüssen archiviert (standardmäßig var/cache, var/log, node_modules, Thumbnails…). Der optionale Inkrementalmodus stützt sich auf einen sha1 aus path + size + mtime, der in der Datenbank verfolgt wird: Nur seit dem letzten Vollbackup geänderte Dateien werden neu archiviert.

AES-256-Verschlüsselung

Die Verschlüsselung ist optional, aber für ausgelagerte Archive dringend empfohlen. DfBackup SW wendet ein AES-256-CBC-plus-HMAC-SHA-256-Schema nach dem Encrypt-then-MAC-Muster an:

• Die Passphrase durchläuft PBKDF2-SHA256 mit 120.000 Iterationen, um getrennte Verschlüsselungs- und HMAC-Schlüssel abzuleiten.
• Die Verschlüsselung erfolgt im Streaming in 1-MiB-Blöcken: Ein Multi-GB-Archiv verschlüsselt sich mit konstantem Speicherbedarf.
• Beim Lesen wird der HMAC vor jeder Entschlüsselung geprüft (Schutz vor Padding-Oracle- und Bit-Flip-Angriffen).
• Eine unabhängige SHA-256-Prüfsumme garantiert die Integrität der Rohdatei (Status verified oder corrupted in der Datenbank).

Storage-Backends

Jedes Backup kann gleichzeitig an ein oder mehrere Backends gesendet werden, um die 3-2-1-Regel anzuwenden:

• Local: unter var/df-backup, mit Anti-Listing-Schutz.
• Amazon S3 und Kompatible: native AWS-V4-Signatur (ohne SDK), automatischer Multipart-Upload ab 100 MB (10-MB-Parts). Kompatibel mit MinIO, Wasabi, Cloudflare R2, OVH, Scaleway, Backblaze B2 via Endpoint- und Region-Override.
• FTP und FTPS: Passivmodus, automatische Anlage des Remote-Verzeichnisses.
• Dropbox v2: REST mit Chunked upload_session für Archive über 150 MB.

Replikation zu einem Shopware-Staging

Das ist das Feature, das DfBackup SW auszeichnet: jedes Backup zu einer zweiten Shopware-Installation mit demselben Plugin schieben.

1. Installieren Sie DfBackup SW auf der Produktion und auf dem Staging.
2. Generieren Sie ein gemeinsames Secret (langer Zufallsstring) und tragen Sie es auf beiden Seiten ein.
3. Aktivieren Sie auf der Produktion Replikation als Ziel und geben Sie die Staging-URL an.

Bei jedem Backup wird das Archiv in 8-MB-Chunks mit HMAC-SHA-256-Signatur zu dedizierten Endpoints auf dem Ziel hochgeladen (chunk, commit, delete, ping), mit Zeitstempel-Anti-Replay bei 5 Minuten Toleranz. Ist Auto-Restore auf dem Staging aktiviert, wird das Archiv automatisch angewendet — Ihr Staging spiegelt die Produktion des Vortags am nächsten Morgen.

1-Klick-Wiederherstellung

Aus der Backup-Liste öffnet der Button Wiederherstellen ein Modal:

1. Wählen Sie den Umfang: alles, nur Datenbank oder nur Dateien.
2. Zur Bestätigung tippen Sie das Wort RESTORE — ein Schutz vor versehentlichen Klicks.
3. Optional aktivieren Sie den Domain-Migrationsmodus und geben die neue Domain an.

Vor jeder Wiederherstellung wird automatisch ein geschützter Datenbank-Snapshot erstellt: Scheitert die Wiederherstellung auf halbem Weg, sind Sie in Minuten zurück im Ausgangszustand. Die Plugin-Tabellen (df_backup*) werden nie überschrieben — Ihr Backup-Verlauf bleibt erhalten, selbst beim Wiederherstellen einer sechs Monate alten Version.

Domain-Migration

Im Migrationsmodus schreibt das Plugin die sales_channel_domain-Einträge um und führt ein Best-Effort-Replacement auf den Textspalten der Translation-Tabellen (CMS, Produkte, Kategorien) sowie auf seo_url durch, damit der Klon sofort unter seiner eigenen Domain erreichbar ist.

Planung, Rotation und Wartungsmodus

• Frequenzen: daily (Zielstunde), weekly (Tag + Stunde), monthly (Monatstag + Stunde). 30-Minuten-Toleranzfenster und 60-Minuten-Deduplizierung.
• Rotation: nach Anzahl der zu behaltenden Backups und nach Alter in Tagen. Als geschützt markierte Backups (insbesondere Pre-Restore-Snapshots) werden nie rotiert.
• Optionaler Wartungsmodus: schaltet die Sales Channels während des Datenbankdumps in den Wartungsmodus für perfekte transaktionale Konsistenz, nützlich bei Shops mit sehr hohem Bestellvolumen.

Benachrichtigungen und Audit

• E-Mail via Symfony Mailer (Erfolg, Fehler oder beides nach Wahl).
• Webhook mit Format-Autoerkennung: Slack, Discord, Microsoft Teams oder generisches JSON.
• Warnung im Modul, wenn seit N Tagen kein erfolgreiches Backup vorliegt.
• Audit-Log: Jede sensible Aktion (Start, Wiederherstellung, Löschung, Prüfung, Download) wird mit Admin-Benutzer, IP und Zeitstempel protokolliert.

FAQ und Fehlerbehebung

Funktioniert das Plugin ohne shell_exec? Ja. Keine Aufrufe von shell_exec, exec, passthru oder mysqldump. Alles ist reines PHP (DBAL, ZipArchive, cURL, native ftp-Funktionen).

Meine Backups laufen nicht automatisch. Prüfen Sie, dass ein Messenger-Worker läuft (oder der Web-Cron regelmäßig aufgerufen wird) und dass die DfBackup-ScheduledTask in Shopware aktiv ist. Ohne Worker oder Web-Cron kann die Planung nicht laufen.

Der Dump scheitert an einer großen Tabelle. Die Keyset-Pagination bewältigt große Tabellen normalerweise; stellen Sie sicher, dass der Integer-Primärschlüssel vorhanden ist, und erhöhen Sie bei Bedarf den Worker-Speicher (--memory-limit).

Ein Archiv kommt als corrupted heraus. Die SHA-256-Prüfsumme stimmt nicht: Der Upload oder Schreibvorgang wurde abgeschnitten. Starten Sie das Backup erneut und prüfen Sie Speicherplatz und Kontingente des Remote-Backends.

Wie prüfe ich ein Backup, ohne es wiederherzustellen? Der Button Prüfen berechnet die SHA-256-Prüfsumme neu und kontrolliert bei verschlüsselten Archiven den HMAC — ohne etwas wiederherzustellen.

Was passiert bei der Deinstallation? Mit der Datenlöschoption werden die vier df_backup*-Tabellen entfernt und die Konfiguration gelöscht. Dateien unter var/df-backup werden nicht automatisch gelöscht: Laden Sie Ihre neuesten Backups vor der Deinstallation herunter.