PS PrestaShop PrestaShop Débutant

dfbackup — Sauvegarde PrestaShop 8 & 9 : guide complet

Installation, planification, stockages S3/FTP/Dropbox, chiffrement AES-256, restauration 1-clic et réplication staging du module dfbackup.

Mis à jour Version du module 1.0.0

Présentation

dfbackup est un module de sauvegarde complet pour PrestaShop 8 et 9. Il sauvegarde votre base de données et vos fichiers en pur PHP (sans mysqldump ni shell_exec), chiffre optionnellement les archives en AES-256, les envoie vers plusieurs destinations (Local, S3, FTP, Dropbox, réplication PrestaShop) et permet une restauration en un clic avec snapshot de sécurité automatique.

Trois onglets sont ajoutés dans le menu Paramètres avancés de votre back-office : Dashboard (vue d’ensemble et lancement manuel), Historique (liste des sauvegardes, restauration, vérification, suppression) et Réglages (planification, stockage, chiffrement, notifications).

Installation

  1. Dans votre back-office, allez dans Modules > Gestionnaire de modules > Installer un module.
  2. Sélectionnez le fichier dfbackup-1.0.0.zip téléchargé après votre achat.
  3. Cliquez sur Installer. Le module crée quatre tables (dfbackup, dfbackup_log, dfbackup_filemap, dfbackup_audit) et le répertoire de stockage var/dfbackup/ protégé par un .htaccess.
  4. Ouvrez Paramètres avancés > DF Backup pour accéder au dashboard.

Après chaque mise à jour du module, videz le cache PHP (opcache) et le cache Smarty : Paramètres avancés > Performances > Vider le cache. Sur certains hébergements, un redémarrage de PHP-FPM est nécessaire pour recharger le bytecode.

Lancer une première sauvegarde

Depuis le Dashboard, trois boutons permettent un lancement manuel :

  • Run backup now — sauvegarde complète (BDD + fichiers) ;
  • Database only — dump BDD seul, rapide (moins d’une minute sur la plupart des boutiques) ;
  • Files only — archive des fichiers seule.

La sauvegarde s’exécute en arrière-plan dans son propre process PHP : la page ne bloque pas, et une carte de progression affiche les logs en temps réel avec un pourcentage estimé (dump BDD, archivage fichiers, chiffrement, checksum, upload, rotation). Vous pouvez quitter la page : la sauvegarde continue côté serveur.

Planification

Dans Réglages > Planification, trois fréquences sont proposées :

  • Daily — chaque jour à l’heure cible (ex. 03:00) ;
  • Weekly — un jour de la semaine + heure ;
  • Monthly — un jour du mois + heure.

Une fenêtre de tolérance de 30 minutes et une déduplication de 60 minutes évitent les doubles déclenchements. Deux mécanismes d’exécution coexistent :

Cron natif PrestaShop

Le hook actionCronJob s’exécute lors des visites de la boutique. Suffisant pour les boutiques à trafic régulier, mais non garanti la nuit.

Web-cron (recommandé)

Une URL signée par token est affichée dans les Réglages, au format :

https://votre-boutique.com/index.php?fc=module&module=dfbackup&controller=webcron&token=VOTRE_TOKEN

Configurez un service externe gratuit comme cron-job.org ou EasyCron pour appeler cette URL toutes les heures (ou toutes les 15 minutes). Le module vérifie en interne si l’heure cible est atteinte et répond immédiatement QUEUED | id=N quand une sauvegarde est déclenchée, ou Not scheduled now. sinon. La réponse est instantanée — aucun risque de timeout côté service de cron.

Le bouton Régénérer le token invalide immédiatement l’ancienne URL. Pensez à mettre à jour votre service de cron externe après régénération.

Destinations de stockage

Chaque sauvegarde peut être envoyée vers plusieurs destinations simultanément — c’est la règle 3-2-1 (trois copies, deux supports, une hors site). Cochez les destinations voulues dans Réglages > Stockage :

Local

Les archives restent dans var/dfbackup/ sous la racine PrestaShop, protégées par un .htaccess Deny. Toujours actif comme copie de travail.

Amazon S3 et compatibles

Renseignez Access Key, Secret Key, bucket, région. Le champ Endpoint permet d’utiliser n’importe quel service compatible S3 :

  • Amazon S3 : laisser l’endpoint vide, indiquer la région (ex. eu-west-3) ;
  • Cloudflare R2 : https://ACCOUNT_ID.r2.cloudflarestorage.com, région auto — 10 Go gratuits, zéro coût de sortie ;
  • MinIO auto-hébergé : https://minio.votre-domaine.com ;
  • OVH Object Storage, Scaleway, Wasabi, Backblaze B2 : endpoint fourni par votre hébergeur.

Le multipart upload se déclenche automatiquement au-delà de 100 Mo (parts de 10 Mo) — les archives de plusieurs Go passent sans saturer la mémoire PHP.

FTP / FTPS

Hôte, port, identifiants, répertoire distant (créé automatiquement s’il n’existe pas), FTPS et mode passif activables.

Dropbox

Collez un access token généré depuis la console développeur Dropbox (permission files.content.write). Les archives au-dessus de 150 Mo passent automatiquement en upload_session chunké.

Chaque destination dispose d’un bouton Test qui vérifie la connexion et les droits d’écriture avant la première sauvegarde réelle.

Réplication vers un PrestaShop staging

La réplication pousse chaque sauvegarde vers une seconde installation PrestaShop équipée de dfbackup — idéal pour maintenir un environnement de pré-production synchronisé chaque nuit.

Configuration

  1. Sur la boutique cible (staging) : installez dfbackup, puis enregistrez un secret partagé (32+ caractères aléatoires) sous la clé de configuration DFBACKUP_REPLICATION_SECRET (via Réglages ou Paramètres avancés > Configuration).
  2. Sur la boutique source (prod) : dans Réglages > Stockage > Réplication PrestaShop, renseignez l’URL du staging (ex. https://staging.example.com) et le même secret. Cochez Réplication parmi les destinations.
  3. Cliquez sur Test replication target : la cible doit répondre OK.

Restauration automatique (optionnelle)

Pour que le staging applique automatiquement chaque archive reçue, activez sur la cible la clé DFBACKUP_REPLICATION_AUTO_RESTORE = 1 et cochez l’option correspondante côté source. Le lendemain matin, votre staging reflète la prod de la veille.

L’auto-restore écrase la BDD et les fichiers du staging à chaque réception. Ne l’activez jamais sur une boutique de production. Le flag côté cible est une protection volontairement séparée du secret partagé.

Sécurité du transport

Les archives sont transférées par chunks de 8 Mo, chacun signé HMAC-SHA-256 (la signature couvre les paramètres et le hash du corps). Un contrôle anti-rejeu rejette toute requête dont le timestamp dévie de plus de 5 minutes.

Chiffrement AES-256

Dans Réglages > Chiffrement, activez la case et définissez une passphrase. Les archives sont alors chiffrées en AES-256-CBC avec HMAC-SHA-256 (pattern encrypt-then-MAC, dérivation PBKDF2 à 120 000 itérations).

  • La passphrase n’est jamais stockée en clair — seul son hash sert à la vérification lors de la restauration.
  • Une archive chiffrée dont la passphrase est perdue est définitivement irrécupérable. Stockez la passphrase dans un gestionnaire de mots de passe (Bitwarden, 1Password) avant d’activer l’option.
  • Le checksum SHA-256 est calculé sur l’archive avant chiffrement et vérifié à la restauration.

Restauration

Depuis Historique, chaque sauvegarde propose trois actions : Vérifier (recalcule le SHA-256), Restaurer et Supprimer.

Déroulement d’une restauration

  1. Un snapshot BDD de sécurité est créé automatiquement avant toute opération.
  2. Vous choisissez le périmètre : tout, BDD seule, ou fichiers seuls.
  3. Si l’archive est chiffrée, la passphrase est demandée.
  4. La BDD est restaurée instruction par instruction ; les fichiers sont extraits par lots.
  5. Les tables dfbackup* sont toujours préservées : votre historique de sauvegardes survit à la restauration.

Mode migration (changement de domaine)

Cochez Mode migration et indiquez le nouveau domaine : le module met à jour PS_SHOP_DOMAIN, PS_SHOP_DOMAIN_SSL, la table shop_url et réécrit les URLs hardcodées dans les contenus CMS, produits et meta. Pratique pour cloner une boutique en pré-prod ou déménager de domaine.

Après une restauration, videz systématiquement le cache (Performances > Vider le cache) et vérifiez la page d’accueil en navigation privée.

Rotation et rétention

Deux règles cumulatives dans Réglages > Rétention :

  • Garder N sauvegardes — au-delà, les plus anciennes sont supprimées ;
  • Supprimer après X jours — indépendamment du nombre.

Seules les sauvegardes en statut completed ou verified sont comptées et purgées ; les snapshots pré-restauration et pré-upgrade suivent les mêmes règles.

Notifications et alertes

  • Email — envoi via Mail::Send (vos réglages SMTP PrestaShop sont respectés) en cas de succès et/ou d’échec, templates FR/EN/ES/DE.
  • Webhook — collez une URL Slack, Discord ou Microsoft Teams : le format est auto-détecté. Toute autre URL reçoit un JSON générique.
  • Alerte back-office — un bandeau apparaît en tête de toutes les pages admin si la dernière sauvegarde a échoué (rouge) ou date de plus de 7 jours (jaune).
  • Snapshot pré-upgrade — une sauvegarde BDD est lancée automatiquement avant chaque mise à jour de module (hook actionAdminModulesUpgradeBefore), désactivable dans les Réglages.

Exclusions de fichiers

Le module exclut d’office var/dfbackup, var/cache, .git, node_modules et le dossier autoupgrade. Vous pouvez ajouter vos propres chemins et patterns glob (ex. img/tmp/*, *.log) dans Réglages > Exclusions. Le mode incrémental (fichiers modifiés uniquement, détection par empreinte chemin + taille + date) réduit fortement la taille des sauvegardes intermédiaires.

Dépannage

Une sauvegarde reste bloquée en « running »

Si le process a été tué (redémarrage serveur), la ligne sera marquée en échec au prochain lancement grâce au verrou flock. Vous pouvez aussi la supprimer depuis l’Historique.

« Another backup is already running »

Un verrou fichier empêche deux sauvegardes simultanées. Attendez la fin de la sauvegarde en cours (visible dans le Dashboard) ou vérifiez qu’un cron externe ne tourne pas au même moment qu’un lancement manuel.

La sauvegarde échoue sur une grosse boutique

Augmentez Max execution time et Memory limit dans les Réglages (le module les applique à son propre process). Activez le mode incrémental pour les fichiers et excluez les répertoires volumineux inutiles (exports, logs).

Les modifications du module ne semblent pas prises en compte

C’est presque toujours l’opcache PHP qui sert l’ancien bytecode. Videz le cache PrestaShop et redémarrez PHP-FPM (ou attendez l’expiration de l’opcache).

L’URL de web-cron renvoie une 404

Utilisez l’URL au format dispatcher (index.php?fc=module&module=dfbackup&controller=webcron) affichée dans les Réglages — certains hébergements bloquent l’accès direct aux fichiers PHP sous /modules/.

Désinstallation

La désinstallation supprime les quatre tables et toutes les configurations. Les archives présentes dans var/dfbackup/ ne sont pas supprimées automatiquement — téléchargez vos sauvegardes récentes avant de désinstaller si vous comptez réinstaller plus tard.

Cette page vous a-t-elle été utile ?

Toujours bloqué ? Contactez le support