DfBackup SW — Guide complet

DfBackup SW est un système de sauvegarde production-grade pour Shopware 6.5, 6.6 et 6.7, sans aucune dépendance externe : pas de mysqldump, pas de shell_exec, pas de SDK Amazon. Il sauvegarde la base de données et les fichiers en pur PHP, chiffre les archives en AES-256 authentifié, les pousse vers Local, S3, FTP ou Dropbox, et sait même répliquer chaque sauvegarde vers un second Shopware staging. La restauration se fait en un clic, avec un snapshot de sécurité automatique. Ce guide couvre l’installation, l’exécution en arrière-plan, le chiffrement, les backends de stockage, la réplication, la restauration, la planification et le dépannage.

Installation

1. Téléchargez l’archive DfBackup-SW-1.0.0.zip depuis votre compte DataFirefly.
2. Copiez le dossier décompressé DfBackup dans custom/plugins/ de votre Shopware, ou installez le ZIP via Administration → Extensions → Mes extensions → Charger l’extension.
3. Lancez l’installation et l’activation :

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

4. À l’installation, le plugin crée ses quatre tables (df_backup, df_backup_log, df_backup_filemap, df_backup_audit) et enregistre sa ScheduledTask.

Où trouver le plugin dans l’administration

Après activation, un module d’administration dédié DfBackup apparaît dans le menu. Il regroupe la liste des sauvegardes, le bouton Sauvegarder maintenant, la progression en temps réel, et l’accès aux actions par sauvegarde (vérifier, télécharger, protéger, restaurer, supprimer). La configuration (planification, chiffrement, backends, réplication, notifications) se fait dans la configuration du plugin via Extensions → Mes extensions → DfBackup → ⋯ → Configurer.

Exécution en arrière-plan : Messenger, ScheduledTask et web-cron

Une sauvegarde ne bloque jamais l’interface. Le clic sur Sauvegarder maintenant pré-alloue une ligne, dispatche un message asynchrone Symfony Messenger et retourne immédiatement l’identifiant. Le travail réel s’exécute dans le worker, et l’administration affiche la progression en direct via 15 jalons (démarrage, dump BDD, archivage, chiffrement, checksum, upload par backend, rotation).

Worker recommandé en production

Pour les boutiques de production, faites tourner un consumer Messenger supervisé en permanence :

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

Placez-le sous systemd ou supervisor pour qu’il redémarre automatiquement. C’est la configuration qui permet d’exécuter les sauvegardes sans aucune limite de temps web.

ScheduledTask

Une ScheduledTask native s’exécute toutes les 10 minutes et sert de porte d’entrée à la planification : elle vérifie si une sauvegarde planifiée doit partir et, le cas échéant, dispatche le message. Elle dépend du scheduler Shopware, lui-même actionné par le worker ou par le cron Shopware.

Web-cron de secours

Sur les hébergements sans accès CLI ni worker permanent, activez le web-cron : une URL signée par token (régénérable depuis la configuration) qu’un service externe comme cron-job.org appelle toutes les 10 à 15 minutes. La porte de planification interne (fenêtre de 30 minutes, déduplication de 60 minutes) évite les doubles déclenchements.

Le dump base de données, pensé pour Shopware

Un dump SQL naïf casse sur Shopware. DfBackup SW gère nativement les particularités du schéma :

• Les colonnes générées (STORED ou VIRTUAL) sont exclues des INSERT, car MySQL refuse qu’on les écrive.
• Les colonnes binaires — dont les clés primaires UUID en BINARY 16, omniprésentes dans Shopware — sont émises en littéraux hexadécimaux 0x… pour une réimportation parfaitement fidèle.
• La pagination keyset sur clé primaire entière permet de dumper les très grosses tables (order, log_entry) sans saturer la mémoire.
• Les vues sont recréées en dernier, après toutes les tables.

Le dump est chunké (500 lignes par lot) et le fichier produit se réimporte proprement, instruction par instruction, avec FOREIGN_KEY_CHECKS désactivé pendant l’import.

La sauvegarde des fichiers

Les fichiers sont archivés via ZipArchive avec des exclusions glob configurables (par défaut var/cache, var/log, node_modules, miniatures…). Le mode incrémental optionnel s’appuie sur un sha1 de path + size + mtime suivi en base : seules les fichiers modifiés depuis la dernière sauvegarde complète sont réarchivés.

Chiffrement AES-256

Le chiffrement est optionnel mais fortement recommandé pour les archives stockées hors site. DfBackup SW applique un schéma AES-256-CBC plus HMAC-SHA-256 selon le pattern encrypt-then-MAC :

• La passphrase passe par PBKDF2-SHA256 avec 120 000 itérations pour dériver des clés de chiffrement et de HMAC séparées.
• Le chiffrement est réalisé en streaming par blocs de 1 Mio : une archive de plusieurs Go se chiffre avec une empreinte mémoire constante.
• À la lecture, le HMAC est vérifié avant tout déchiffrement (protection contre les attaques padding oracle et bit-flip).
• Un SHA-256 indépendant garantit l’intégrité du fichier brut (statut verified ou corrupted en base).

Backends de stockage

Chaque sauvegarde peut être envoyée vers un ou plusieurs backends simultanément, pour appliquer la règle 3-2-1 :

• Local : sous var/df-backup, avec protection anti-listing.
• Amazon S3 et compatibles : signature AWS V4 native (sans SDK), multipart upload automatique au-delà de 100 Mo (parts de 10 Mo). Compatible MinIO, Wasabi, Cloudflare R2, OVH, Scaleway, Backblaze B2 via la surcharge d’endpoint et de région.
• FTP et FTPS : mode passif, création automatique du répertoire distant.
• Dropbox v2 : REST avec upload_session chunké pour les archives au-dessus de 150 Mo.

Réplication vers un Shopware staging

C’est la fonction qui distingue DfBackup SW : pousser chaque sauvegarde vers une seconde installation Shopware équipée du même plugin.

1. Installez DfBackup SW sur la prod et sur le staging.
2. Générez un secret commun (longue chaîne aléatoire) et renseignez-le des deux côtés.
3. Côté prod, activez Réplication comme destination et indiquez l’URL du staging.

À chaque sauvegarde, l’archive est uploadée par chunks de 8 Mo signés HMAC-SHA-256 vers des endpoints dédiés sur la cible (chunk, commit, delete, ping), avec anti-rejeu par horodatage à tolérance de 5 minutes. Si l’option auto-restore est activée côté staging, l’archive est appliquée automatiquement — votre staging reflète la prod de la veille dès le lendemain matin.

Restauration 1-clic

Depuis la liste des sauvegardes, le bouton Restaurer ouvre une modale :

1. Choisissez le périmètre : tout, BDD seule ou fichiers seuls.
2. Pour confirmer, tapez le mot RESTORE — garde-fou contre les fausses manipulations.
3. Optionnellement, activez le mode migration de domaine et indiquez le nouveau domaine.

Avant toute restauration, un snapshot BDD protégé est créé automatiquement : si la restauration échoue à mi-chemin, vous revenez à l’état initial en quelques minutes. Les tables du plugin (df_backup*) ne sont jamais écrasées — votre historique de sauvegardes est préservé même en restaurant une version d’il y a six mois.

Migration de domaine

En mode migration, le plugin réécrit les sales_channel_domain et applique un remplacement best-effort sur les colonnes texte des tables de traduction (CMS, produits, catégories) ainsi que sur seo_url, pour que le clone soit immédiatement navigable sur son propre domaine.

Planification, rotation et mode maintenance

• Fréquences : daily (heure cible), weekly (jour + heure), monthly (jour du mois + heure). Fenêtre de tolérance de 30 minutes et déduplication de 60 minutes.
• Rotation : par nombre de sauvegardes à conserver et par âge en jours. Les sauvegardes marquées protégées (snapshots pré-restauration notamment) ne sont jamais rotatées.
• Mode maintenance optionnel : bascule les sales channels en maintenance pendant le dump BDD pour une cohérence transactionnelle parfaite, utile sur les boutiques à très fort volume de commandes.

Notifications et audit

• Email via Symfony Mailer (succès, échec, ou les deux au choix).
• Webhook avec auto-détection du format : Slack, Discord, Microsoft Teams ou JSON générique.
• Alerte dans le module si aucune sauvegarde réussie depuis N jours.
• Journal d’audit : chaque action sensible (lancement, restauration, suppression, vérification, téléchargement) est tracée avec utilisateur admin, IP et horodatage.

FAQ et dépannage

Le plugin fonctionne-t-il sans shell_exec ? Oui. Aucun appel à shell_exec, exec, passthru ni mysqldump. Tout est en pur PHP (DBAL, ZipArchive, cURL, fonctions ftp natives).

Mes sauvegardes ne partent pas automatiquement. Vérifiez qu’un worker Messenger tourne (ou que le web-cron est appelé régulièrement) et que la ScheduledTask DfBackup est active dans Shopware. Sans worker ni web-cron, la planification ne peut pas s’exécuter.

Le dump échoue sur une grosse table. La pagination keyset gère normalement les grosses tables ; assurez-vous que la clé primaire entière est présente et augmentez la mémoire du worker si nécessaire (--memory-limit).

Une archive ressort en statut corrupted. Le SHA-256 ne correspond pas : l’upload ou l’écriture a été tronqué. Relancez la sauvegarde et vérifiez l’espace disque et les quotas du backend distant.

Comment vérifier une sauvegarde sans la restaurer ? Le bouton Vérifier recalcule le SHA-256 et, pour les archives chiffrées, contrôle le HMAC — sans rien restaurer.

Que se passe-t-il à la désinstallation ? Avec l’option de suppression des données, les quatre tables df_backup* sont supprimées et la configuration effacée. Les fichiers sous var/df-backup ne sont pas supprimés automatiquement : téléchargez vos sauvegardes récentes avant de désinstaller.