Tout ce que vous voudriez savoir avant d'installer.
Un regard détaillé sur le fonctionnement de Plugin Sauvegarde Shopware 6 — DfBackup SW : BDD + Fichiers, Chiffrement AES-256, S3/FTP/Dropbox, Restauration 1-Clic, pourquoi nous l'avons conçu ainsi, et la réflexion derrière les fonctionnalités ci-dessus.
Une vraie sauvegarde Shopware, pas un script bricolé
La plupart des solutions de sauvegarde Shopware se contentent d'appeler mysqldump puis de tarer le dossier, ce qui pose trois problèmes en production : mysqldump n'est pas disponible sur beaucoup d'hébergements mutualisés, shell_exec est souvent désactivé, et les archives non chiffrées qui traînent sur le disque sont une bombe à retardement en cas de compromission. DfBackup SW résout ces trois points : dump BDD en pur PHP via DBAL, archivage via ZipArchive, et chiffrement AES-256 authentifié optionnel avec passphrase utilisateur. Le tout fonctionne sans configuration sysadmin particulière, sur mutualisé comme sur VPS.
Un dump qui comprend le schéma Shopware
Un dump SQL naïf casse sur Shopware : les clés primaires sont des UUID en BINARY 16 qui doivent être émis en littéraux hexadécimaux, certaines colonnes sont générées (STORED ou VIRTUAL) et ne doivent jamais apparaître dans les INSERT, et les vues doivent être recréées après les tables. DfBackup SW gère tout cela nativement : inspection SHOW FULL COLUMNS par table, exclusion des colonnes générées, encodage hex des colonnes binaires, pagination keyset sur les clés primaires entières pour les grosses tables (order, log_entry), et dump des vues en dernier. Le fichier produit se réimporte proprement, instruction par instruction, avec FOREIGN_KEY_CHECKS désactivé pendant l'import.
Chiffrement AES-256 avec HMAC : encrypt-then-MAC fait correctement
Le pattern encrypt-then-MAC est le standard recommandé pour les schémas symétriques : on chiffre d'abord, puis on calcule un HMAC sur le ciphertext. À la lecture, on vérifie le HMAC avant de déchiffrer — protection contre les bit-flip attacks et les padding oracle attacks. La passphrase utilisateur passe par PBKDF2-SHA256 avec 120000 itérations pour dériver des clés de chiffrement et HMAC séparées. Le chiffrement est réalisé en streaming par blocs de 1 Mio avec chaînage CBC manuel : une archive de 5 Go se chiffre avec la même empreinte mémoire qu'une archive de 50 Mo. Le format binaire (en-tête magic, sel, IV, HMAC, ciphertext) est documenté et auditable.
S3 SigV4 natif : multipart, MinIO, R2, OVH, Scaleway, Wasabi, B2
Au lieu d'embarquer le SDK AWS officiel, DfBackup SW implémente directement AWS Signature V4 en cURL. Zéro dépendance Composer supplémentaire, signature canonique compatible avec tous les services qui parlent S3. Vous pouvez pointer le plugin vers Amazon S3, MinIO sur votre propre VPS, Cloudflare R2 (10 Go gratuits, zéro coût de sortie — idéal pour les sauvegardes), OVH Object Storage, Scaleway, Wasabi ou Backblaze B2 — en changeant juste l'endpoint et la région. Au-delà de 100 Mo, l'upload bascule automatiquement en multipart avec des parts de 10 Mo, ce qui permet de transférer plusieurs gigaoctets sans saturer la mémoire.
Réplication push : un staging nightly sans configuration sysadmin
C'est la feature qui distingue DfBackup SW : pousser chaque sauvegarde vers une seconde installation Shopware. Vous installez le plugin sur votre prod et sur votre staging, vous partagez un secret commun, vous activez Réplication comme destination. À chaque sauvegarde — manuelle ou planifiée — l'archive est uploadée par chunks de 8 Mo signés HMAC-SHA-256 vers des endpoints dédiés sur la cible, avec horodatage anti-rejeu à tolérance de 5 minutes. Si l'option auto-restore est activée côté cible, la sauvegarde est appliquée automatiquement — votre staging reflète la prod de la veille dès le lendemain matin. Combiné à la migration de domaine, le clone est immédiatement navigable sur son propre domaine. Plus besoin de rsync ni de scripts cron sysadmin.
Restauration 1-clic avec filet de sécurité
Une restauration est l'opération la plus risquée du cycle de vie d'une boutique : on écrase la BDD vivante, on remplace les fichiers, et si quelque chose dérape, le retour arrière est complexe. DfBackup SW ajoute un filet de sécurité automatique : avant chaque restauration, un snapshot BDD protégé est créé silencieusement. Si la restauration échoue à mi-chemin, vous restaurez ce snapshot et revenez à l'état initial en quelques minutes. Les tables du plugin ne sont jamais écrasées pendant une restauration — votre historique de sauvegardes est préservé même quand vous restaurez une version d'il y a six mois. La confirmation explicite (taper RESTORE) évite les fausses manipulations.
Messenger, ScheduledTask et web-cron : l'arrière-plan à la Shopware
DfBackup SW s'appuie sur l'infrastructure native de Shopware : les sauvegardes sont dispatchées comme messages asynchrones Symfony Messenger et exécutées par le worker, sans bloquer ni l'admin ni le storefront. Une ScheduledTask native vérifie toutes les 10 minutes si une sauvegarde planifiée doit partir (daily, weekly ou monthly, heure cible, fenêtre de 30 minutes, déduplication 60 minutes). Pour les hébergements sans cron système ni worker permanent, un web-cron par URL signée token prend le relais : appelez l'URL toutes les 10 à 15 minutes depuis cron-job.org ou votre monitoring, la porte de planification interne fait le reste. Le module d'administration affiche la progression en direct avec 15 jalons pollés.
Audit log, alertes et notifications : la défense en profondeur
Trois mécanismes complémentaires pour qu'aucun backup ne se perde sans qu'on s'en rende compte. Le journal d'audit trace chaque action sensible (lancement, restauration, suppression, vérification, téléchargement) avec utilisateur admin, IP et horodatage. L'alerte dans le module signale si la dernière sauvegarde réussie date de plus de N jours. Les notifications partent par email (Symfony Mailer, succès ou échec au choix) et par webhook avec auto-détection du format : Slack, Discord, Microsoft Teams ou JSON générique pour vos intégrations sur mesure.
Il n’y a pas encore d’avis.