Tout ce que vous voudriez savoir avant d'installer.
Un regard détaillé sur le fonctionnement de Module Sauvegarde PrestaShop 8 & 9 — dfbackup, BDD + Fichiers, Chiffrement AES-256, S3/FTP/Dropbox, Réplication Staging, pourquoi nous l'avons conçu ainsi, et la réflexion derrière les fonctionnalités ci-dessus.
Une vraie sauvegarde, pas un script bricolé
La plupart des modules de sauvegarde PrestaShop se contentent d'appeler mysqldump puis de tarer le dossier shop, ce qui pose trois problèmes en production : mysqldump n'est pas disponible sur la majorité des hébergements mutualisés français, shell_exec est désactivé pour des raisons de sécurité, et les archives non chiffrées qui traînent sur le disque sont une bombe à retardement en cas de compromission. dfbackup résout ces trois points : dump BDD en pur PHP, archivage via ZipArchive, et chiffrement AES-256 authentifié optionnel avec passphrase utilisateur. Le tout fonctionne sur les hébergements mutualisés OVH, o2switch, Infomaniak, Hostinger, Plesk, sans configuration particulière.
Chiffrement AES-256 avec HMAC : encrypt-then-MAC fait correctement
Le pattern encrypt-then-MAC est le standard recommandé par les cryptographes pour les schémas symétriques : on chiffre d'abord, puis on calcule un HMAC sur le ciphertext et l'IV. À 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 une clé de chiffrement et une clé HMAC séparées (32 octets chacune). Le format binaire IV-HMAC-ciphertext est documenté, auditables, et lu par n'importe quel outil OpenSSL compatible. La passphrase elle-même n'est jamais stockée en clair : seul son hash password_hash est conservé pour vérification.
S3 SigV4 natif : multipart, MinIO, R2, OVH, Scaleway, Wasabi, B2
Au lieu d'embarquer le SDK AWS officiel (qui pèse plusieurs Mo et impose Composer), dfbackup implémente directement AWS Signature V4 en cURL. Une centaine de lignes de code, zéro dépendance externe, signature canonique compatible avec tous les services qui parlent S3. Vous pouvez pointer dfbackup vers Amazon S3 en région eu-west-3, ou MinIO sur votre propre VPS, ou Cloudflare R2 (qui offre 10 Go gratuits et zéro coût de sortie), ou OVH Object Storage, ou Scaleway, ou Wasabi, ou Backblaze B2 — tous fonctionnent en changeant juste l'endpoint et la région dans les paramètres. Au-delà de 100 Mo, l'upload bascule automatiquement en multipart avec des parts de 10 Mo, ce qui permet de transférer une archive de plusieurs gigaoctets sans saturer la mémoire.
Réplication push : un staging nightly sans configuration sysadmin
C'est la feature qui distingue dfbackup : la possibilité de pousser chaque sauvegarde vers une seconde installation PrestaShop. Vous installez dfbackup sur votre prod et sur votre staging, vous partagez un secret commun, vous cochez Réplication comme destination de stockage. À chaque sauvegarde — manuelle ou planifiée — l'archive est uploadée par chunks de 8 Mo signés HMAC-SHA-256 vers un front controller dédié sur la cible. Si l'option auto-restore est activée côté cible, la sauvegarde est automatiquement appliquée — votre staging est à jour le lendemain matin avec les données de la veille. Plus besoin de rsync, de scripts cron sysadmin, de transferts FTP manuels, ni de licences ManageWP.
Restauration 1-clic avec filet de sécurité
Une restauration de sauvegarde est l'opération la plus risquée d'un cycle de vie boutique : on écrase la BDD vivante avec une version antérieure, on remplace tous les fichiers, et si quelque chose dérape, le retour arrière est complexe. dfbackup ajoute un filet de sécurité automatique : avant chaque restauration, un snapshot BDD seule est créé silencieusement. Si la restauration échoue à mi-chemin (corruption d'archive, erreur SQL, espace disque insuffisant), vous restaurez ce snapshot et vous revenez à l'état initial en quelques minutes. La table dfbackup elle-même n'est jamais écrasée pendant une restauration — votre historique de sauvegardes est préservé même quand vous restaurez une version d'il y a six mois.
Backups en arrière-plan : un clic, des logs en direct
L'expérience classique d'un bouton Run backup en PHP : on clique, le navigateur freeze pendant 5 à 15 minutes, l'utilisateur croit que ça plante, il reclique, deux backups partent en parallèle et le verrou tombe en erreur. dfbackup résout ce pattern dégueulasse en deux temps : le clic pré-alloue une ligne en base, déclenche un cURL self-call vers un front controller dédié, et retourne l'ID immédiatement (moins de 500 ms). Le navigateur affiche aussitôt une barre de progression et poll les logs en temps réel — vous voyez les 15 étapes défiler (démarrage, dump BDD, archivage fichiers, chiffrement, calcul de checksum, upload vers chaque backend, rotation). Le backup tourne dans son propre process PHP, complètement décorrelé de la requête utilisateur. Fonctionne sur tous les modes PHP : FPM, mod_php, FastCGI.
Planification : cron natif PS plus web-cron de secours
Sur les hébergements mutualisés qui ne donnent pas accès au cron système, le hook actionCronJob de PrestaShop tourne uniquement quand quelqu'un visite la boutique — pas idéal pour planifier une sauvegarde nocturne. dfbackup fournit un web-cron de secours : une URL signée par token (régénérable depuis le BO) qu'un service externe comme cron-job.org ou EasyCron appelle au minimum chaque heure. Le module vérifie en interne l'heure cible configurée (par exemple 03:00 daily) et lance la sauvegarde seulement dans la fenêtre prévue. La déduplication sur 60 minutes évite les doubles déclenchements. Le front controller webcron passe par le dispatcher PrestaShop, donc fonctionne même quand l'hébergement bloque l'accès direct aux PHP sous modules.
Audit log, alertes BO, snapshot pré-upgrade : la défense en profondeur
Trois mécanismes complémentaires pour éviter qu'un backup ne soit perdu sans qu'on s'en rende compte. Le journal d'audit trace chaque action sensible (lancement, restauration, suppression, vérification, téléchargement) avec employé, IP et timestamp — utile en cas d'incident à reconstituer. L'alerte back-office affiche un bandeau jaune ou rouge en tête de toutes les pages admin si la dernière sauvegarde a échoué ou si elle date de plus de 7 jours — impossible d'oublier. Le snapshot pré-upgrade se déclenche automatiquement avant chaque mise à jour de module installé : si la mise à jour casse quelque chose, vous restaurez en un clic. Ces trois mécanismes sont activables et désactivables indépendamment dans Settings.
Il n’y a pas encore d’avis.