# dfbackup — Sauvegarde PrestaShop 8 & 9 : guide complet

> 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…

- Page: <https://www.datafirefly.com/documentation/dfbackup/>
- Langue: fr
- Mis à jour le: 2026-07-02
- Autres langues: [en](https://www.datafirefly.com/en/documentation/dfbackup/index.md), [es](https://www.datafirefly.com/es/documentation/dfbackup/index.md), [de](https://www.datafirefly.com/de/documentation/dfbackup/index.md), [it](https://www.datafirefly.com/it/documentation/dfbackup/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfbackup/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfbackup/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfbackup/index.md)
- Index: <https://www.datafirefly.com/documentation/llms.txt>

## 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](https://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](https://www.dropbox.com/developers/apps) (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.