dfbackup — PrestaShop 8 & 9 Backup: vollständige Anleitung
Installation, Planung, S3/FTP/Dropbox-Speicher, AES-256 Verschlüsselung, 1-Klick-Wiederherstellung und Staging-Replikation des dfbackup-Moduls.
Überblick
dfbackup ist ein vollständiges Backup-Modul für PrestaShop 8 und 9. Es sichert Ihre Datenbank und Dateien in reinem PHP (kein mysqldump, kein shell_exec), verschlüsselt Archive optional mit AES-256, lädt sie zu mehreren Zielen hoch (Local, S3, FTP, Dropbox, PrestaShop-Replikation) und bietet eine 1-Klick-Wiederherstellung mit automatischem Sicherheits-Snapshot.
Drei Tabs werden unter dem Menü Erweiterte Parameter Ihres Back-Office hinzugefügt: Dashboard (Übersicht und manuelle Starts), Verlauf (Backup-Liste, Wiederherstellung, Verifikation, Löschung) und Einstellungen (Planung, Speicher, Verschlüsselung, Benachrichtigungen).
Installation
- Gehen Sie in Ihrem Back-Office zu Module > Modul-Manager > Modul hochladen.
- Wählen Sie die nach dem Kauf heruntergeladene Datei
dfbackup-1.0.0.zip. - Klicken Sie auf Installieren. Das Modul erstellt vier Tabellen (
dfbackup,dfbackup_log,dfbackup_filemap,dfbackup_audit) und das durch eine .htaccess geschützte Speicherverzeichnisvar/dfbackup/. - Öffnen Sie Erweiterte Parameter > DF Backup, um das Dashboard aufzurufen.
Leeren Sie nach jedem Modul-Update den PHP-Cache (opcache) und den Smarty-Cache: Erweiterte Parameter > Leistung > Cache leeren. Auf manchen Hosts ist ein PHP-FPM-Neustart erforderlich, um den Bytecode neu zu laden.
Ein erstes Backup starten
Im Dashboard bieten drei Buttons manuelle Starts:
- Run backup now — vollständiges Backup (DB + Dateien);
- Database only — nur DB-Dump, schnell (unter einer Minute bei den meisten Shops);
- Files only — nur Dateiarchiv.
Das Backup läuft im Hintergrund in seinem eigenen PHP-Prozess: die Seite blockiert nicht, und eine Fortschrittskarte streamt die Logs in Echtzeit mit einem geschätzten Prozentsatz (DB-Dump, Dateiarchivierung, Verschlüsselung, Checksum, Upload, Rotation). Sie können die Seite verlassen — das Backup läuft serverseitig weiter.
Planung
Unter Einstellungen > Planung stehen drei Frequenzen zur Verfügung:
- Daily — jeden Tag zur Zielzeit (z.B. 03:00);
- Weekly — ein Wochentag + Uhrzeit;
- Monthly — ein Tag des Monats + Uhrzeit.
Ein 30-Minuten-Toleranzfenster und eine 60-Minuten-Deduplizierung vermeiden Doppelauslösungen. Zwei Ausführungsmechanismen koexistieren:
Nativer PrestaShop-Cron
Der actionCronJob-Hook feuert bei Shop-Besuchen. Ausreichend für Shops mit regelmäßigem Traffic, aber nachts nicht garantiert.
Web-cron (empfohlen)
Eine Token-signierte URL wird in den Einstellungen angezeigt, im Format:
https://ihr-shop.com/index.php?fc=module&module=dfbackup&controller=webcron&token=IHR_TOKEN
Konfigurieren Sie einen kostenlosen externen Dienst wie cron-job.org oder EasyCron, um diese URL stündlich (oder alle 15 Minuten) aufzurufen. Das Modul prüft intern, ob die Zielzeit erreicht wurde, und antwortet sofort mit QUEUED | id=N, wenn ein Backup ausgelöst wird, oder Not scheduled now. andernfalls. Die Antwort ist sofortig — kein Timeout-Risiko auf Seiten des Cron-Dienstes.
Der Button Token regenerieren macht die alte URL sofort ungültig. Denken Sie daran, Ihren externen Cron-Dienst nach der Regeneration zu aktualisieren.
Speicherziele
Jedes Backup kann zu mehreren Zielen gleichzeitig hochgeladen werden — die 3-2-1-Regel (drei Kopien, zwei Medien, eine außer Haus). Wählen Sie die gewünschten Ziele unter Einstellungen > Speicher:
Local
Archive verbleiben in var/dfbackup/ unter der PrestaShop-Wurzel, geschützt durch eine .htaccess Deny. Immer aktiv als Arbeitskopie.
Amazon S3 und kompatible
Tragen Sie Access Key, Secret Key, Bucket, Region ein. Das Feld Endpoint ermöglicht die Nutzung jedes S3-kompatiblen Dienstes:
- Amazon S3: Endpoint leer lassen, Region angeben (z.B.
eu-west-3); - Cloudflare R2:
https://ACCOUNT_ID.r2.cloudflarestorage.com, Regionauto— 10 GB kostenlos, null Egress-Kosten; - Selbst gehostetes MinIO:
https://minio.ihre-domain.com; - OVH Object Storage, Scaleway, Wasabi, Backblaze B2: Endpoint von Ihrem Anbieter.
Der Multipart-Upload wird automatisch über 100 MB ausgelöst (10-MB-Parts) — Multi-GB-Archive werden übertragen, ohne den PHP-Speicher zu überlasten.
FTP / FTPS
Host, Port, Zugangsdaten, Remote-Verzeichnis (automatisch erstellt, falls fehlend), FTPS und passiver Modus aktivierbar.
Dropbox
Fügen Sie einen Access Token ein, der über die Dropbox-Entwicklerkonsole generiert wurde (Berechtigung files.content.write). Archive über 150 MB wechseln automatisch zu einer gechunkten upload_session.
Jedes Ziel verfügt über einen Test-Button, der Verbindung und Schreibrechte vor dem ersten echten Backup verifiziert.
Replikation zu einem Staging-PrestaShop
Die Replikation schiebt jedes Backup zu einer zweiten PrestaShop-Installation mit dfbackup — ideal, um eine Pre-Prod-Umgebung jede Nacht synchron zu halten.
Konfiguration
- Auf dem Ziel-Shop (Staging): installieren Sie dfbackup, dann speichern Sie ein gemeinsames Geheimnis (32+ zufällige Zeichen) unter dem Konfigurationsschlüssel
DFBACKUP_REPLICATION_SECRET(über Einstellungen oder Erweiterte Parameter > Konfiguration). - Auf dem Quell-Shop (Prod): unter Einstellungen > Speicher > PrestaShop-Replikation geben Sie die Staging-URL (z.B.
https://staging.example.com) und dasselbe Geheimnis ein. Aktivieren Sie Replikation unter den Zielen. - Klicken Sie auf Test replication target: das Ziel muss OK antworten.
Automatische Wiederherstellung (optional)
Damit das Staging jedes empfangene Archiv automatisch anwendet, aktivieren Sie auf dem Ziel den Schlüssel DFBACKUP_REPLICATION_AUTO_RESTORE = 1 und aktivieren die entsprechende Option auf der Quellseite. Am nächsten Morgen spiegelt Ihr Staging die Produktion vom Vortag wider.
Auto-Restore überschreibt DB und Dateien des Stagings bei jedem Empfang. Aktivieren Sie es niemals auf einem Produktionsshop. Das zielseitige Flag ist bewusst ein vom gemeinsamen Geheimnis getrennter Schutz.
Transportsicherheit
Archive werden in 8-MB-Chunks übertragen, jeder HMAC-SHA-256-signiert (die Signatur umfasst die Parameter und den Body-Hash). Eine Anti-Replay-Prüfung lehnt jede Anfrage ab, deren Timestamp mehr als 5 Minuten abweicht.
AES-256 Verschlüsselung
Unter Einstellungen > Verschlüsselung aktivieren Sie die Checkbox und legen eine Passphrase fest. Archive werden dann mit AES-256-CBC plus HMAC-SHA-256 verschlüsselt (encrypt-then-MAC-Pattern, PBKDF2-Ableitung mit 120.000 Iterationen).
- Die Passphrase wird niemals im Klartext gespeichert — nur ihr Hash dient der Verifikation bei der Wiederherstellung.
- Ein verschlüsseltes Archiv, dessen Passphrase verloren geht, ist endgültig unwiederherstellbar. Speichern Sie die Passphrase in einem Passwort-Manager (Bitwarden, 1Password), bevor Sie die Option aktivieren.
- Die SHA-256-Prüfsumme wird auf dem Archiv vor der Verschlüsselung berechnet und bei der Wiederherstellung verifiziert.
Wiederherstellung
Im Verlauf bietet jedes Backup drei Aktionen: Verifizieren (berechnet den SHA-256 neu), Wiederherstellen und Löschen.
Ablauf einer Wiederherstellung
- Ein Sicherheits-DB-Snapshot wird automatisch vor allem anderen erstellt.
- Sie wählen den Umfang: alles, nur DB oder nur Dateien.
- Wenn das Archiv verschlüsselt ist, wird die Passphrase abgefragt.
- Die DB wird Anweisung für Anweisung wiederhergestellt; die Dateien werden stapelweise extrahiert.
- Die
dfbackup*-Tabellen werden immer erhalten: Ihre Backup-Historie überlebt die Wiederherstellung.
Migrationsmodus (Domänenwechsel)
Aktivieren Sie Migrationsmodus und geben Sie die neue Domäne ein: das Modul aktualisiert PS_SHOP_DOMAIN, PS_SHOP_DOMAIN_SSL, die shop_url-Tabelle und schreibt hartkodierte URLs in CMS-, Produkt- und Meta-Inhalten neu. Praktisch, um einen Shop in eine Pre-Prod zu klonen oder die Domäne zu wechseln.
Leeren Sie nach einer Wiederherstellung immer den Cache (Leistung > Cache leeren) und prüfen Sie die Startseite im privaten Modus.
Rotation und Aufbewahrung
Zwei kumulative Regeln unter Einstellungen > Aufbewahrung:
- N Backups behalten — darüber hinaus werden die ältesten gelöscht;
- Nach X Tagen löschen — unabhängig von der Anzahl.
Nur Backups mit Status completed oder verified werden gezählt und bereinigt; Pre-Restore- und Pre-Upgrade-Snapshots folgen denselben Regeln.
Benachrichtigungen und Warnungen
- E-Mail — Versand über
Mail::Send(Ihre PrestaShop-SMTP-Einstellungen werden respektiert) bei Erfolg und/oder Fehlschlag, FR/EN/ES/DE-Templates. - Webhook — fügen Sie eine Slack-, Discord- oder Microsoft-Teams-URL ein: das Format wird auto-erkannt. Jede andere URL erhält generisches JSON.
- Back-Office-Warnung — ein Banner erscheint am Anfang aller Admin-Seiten, wenn das letzte Backup fehlgeschlagen ist (rot) oder älter als 7 Tage ist (gelb).
- Pre-Upgrade-Snapshot — ein DB-Backup läuft automatisch vor jedem Modul-Update (
actionAdminModulesUpgradeBefore-Hook), in den Einstellungen deaktivierbar.
Dateiausschlüsse
Das Modul schließt immer var/dfbackup, var/cache, .git, node_modules und den autoupgrade-Ordner aus. Sie können eigene Pfade und Glob-Muster (z.B. img/tmp/*, *.log) unter Einstellungen > Ausschlüsse hinzufügen. Der inkrementelle Modus (nur geänderte Dateien, erkannt über Pfad + Größe + Datum-Fingerabdruck) reduziert die Größe der Zwischen-Backups drastisch.
Fehlerbehebung
Ein Backup bleibt in „running“ hängen
Wenn der Prozess beendet wurde (Server-Neustart), wird die Zeile beim nächsten Start dank des flock-Locks als fehlgeschlagen markiert. Sie können sie auch aus dem Verlauf löschen.
„Another backup is already running“
Ein Datei-Lock verhindert zwei gleichzeitige Backups. Warten Sie, bis das laufende Backup beendet ist (im Dashboard sichtbar), oder prüfen Sie, ob nicht ein externer Cron zur gleichen Zeit wie ein manueller Start feuert.
Das Backup schlägt bei einem großen Shop fehl
Erhöhen Sie Max execution time und Memory limit in den Einstellungen (das Modul wendet sie auf seinen eigenen Prozess an). Aktivieren Sie den inkrementellen Modus für Dateien und schließen Sie unnötige große Verzeichnisse aus (Exports, Logs).
Modul-Änderungen scheinen nicht zu greifen
Es ist fast immer der PHP-Opcache, der alten Bytecode ausliefert. Leeren Sie den PrestaShop-Cache und starten Sie PHP-FPM neu (oder warten Sie auf das Ablaufen des Opcache).
Die Web-cron-URL gibt einen 404 zurück
Verwenden Sie die in den Einstellungen angezeigte URL im Dispatcher-Format (index.php?fc=module&module=dfbackup&controller=webcron) — manche Hosts blockieren den direkten Zugriff auf PHP-Dateien unter /modules/.
Deinstallation
Die Deinstallation löscht die vier Tabellen und alle Konfigurationen. Archive in var/dfbackup/ werden nicht automatisch entfernt — laden Sie Ihre letzten Backups vor der Deinstallation herunter, wenn Sie später neu installieren möchten.