Knowledge Base Guide

Sauvegarde & Reprise après sinistre PrestaShop : Guide complet

Stratégie de sauvegarde pour PrestaShop — mysqldump, sauvegardes fichiers, cron automatisé, stockage distant, tests de restauration et plan de reprise.

Pourquoi les sauvegardes comptent plus que vous ne le pensez

Chaque propriétaire de boutique PrestaShop se dit « cela ne m’arrivera pas » — jusqu’à ce que cela arrive. Les sauvegardes sont le filet de sécurité le plus important de votre activité en ligne. Voici des scénarios réels qui se produisent régulièrement dans la communauté PrestaShop :

  • La mise à jour échouée : Vous passez de PS 1.7 à 8.x. Le processus plante à mi-chemin des migrations de base de données. Votre catalogue est partiellement converti, les commandes ont des colonnes incohérentes et le back office ne se charge plus. Sans sauvegarde préalable, votre boutique est dans l’impasse
  • La boutique piratée : Un attaquant exploite un module obsolète, injecte des portes dérobées et modifie votre .htaccess. Vous le découvrez des jours plus tard. Comme les fichiers du cœur sont également modifiés, impossible de distinguer les fichiers sains. Seule une sauvegarde antérieure à l’intrusion permet de restaurer la confiance
  • La panne hébergement : La grappe RAID de votre hébergeur tombe en panne. Leur sauvegarde la plus récente date de 9 jours. Votre sauvegarde était sur le même serveur. Neuf jours de commandes, de clients et de modifications — perdus
  • La suppression accidentelle : Quelqu’un supprime /img/p/ en pensant que c’est un répertoire temporaire. Des milliers de photos de produits, effacées en quelques secondes
La question n’est pas de savoir si vous aurez besoin d’une sauvegarde — mais quand. Chaque semaine passée sans sauvegardes testées est un pari sur l’ensemble de votre activité.

Que faut-il sauvegarder

La base de données (le plus critique)

Votre base MySQL/MariaDB contient tout ce qui fait de votre boutique une entreprise : commandes, comptes clients, produits, configuration, règles panier, données SEO et comptes employés. Si vous perdez vos fichiers mais conservez la base de données, vous pouvez reconstruire. Si vous perdez la base de données, vous avez perdu les données de votre entreprise.

Fichiers essentiels

  • /modules/ — modules installés, leurs configurations, templates et ressources téléchargées
  • /themes/ — votre thème actif et les thèmes enfants avec toutes les personnalisations
  • /img/ — images de produits, images de catégories, images CMS (souvent le répertoire le plus volumineux — 10 Go+)
  • /upload/ — pièces jointes et fichiers de produits virtuels
  • /override/ — surcharges personnalisées des classes du cœur
  • /app/config/parameters.php (PS 1.7+) ou /config/settings.inc.php (PS 1.6) — identifiants de base de données et clés de chiffrement
  • /mails/ et /translations/ — si personnalisés
  • .htaccess, configurations de virtual host, surcharges php.ini, définitions cron
  • Certificats SSL — si gérés vous-même (pas via Cloudflare ou votre hébergeur)

Ce que vous n’avez PAS besoin de sauvegarder

  • /var/cache/ — régénéré automatiquement
  • /var/logs/ — utile pour le débogage, pas pour la restauration
  • /vendor/ — réinstallable via composer install
  • /node_modules/ — ne sauvegardez jamais ce répertoire
  • /var/sessions/ — données temporaires

Méthodes de sauvegarde de la base de données

mysqldump (recommandé)

La référence pour les sauvegardes MySQL/MariaDB :

mysqldump \
  --single-transaction \
  --quick \
  --lock-tables=false \
  --routines \
  --triggers \
  --events \
  -u YOUR_DB_USER \
  -p'YOUR_DB_PASSWORD' \
  YOUR_DB_NAME > prestashop_$(date +%Y%m%d_%H%M%S).sql

Pourquoi chaque option est importante :

  • --single-transaction — instantané InnoDB cohérent sans verrouiller les tables. Votre boutique reste opérationnelle sans aucun temps d’arrêt
  • --quick — récupère les lignes une par une au lieu de charger des tables entières en mémoire
  • --lock-tables=false — évite le verrouillage des tables MyISAM que certaines anciennes installations PS utilisent encore
  • --routines, --triggers, --events — inclut les procédures stockées, les triggers et les événements planifiés que les modules peuvent créer
Ne sautez jamais --single-transaction sur une boutique en production. Sans cette option, mysqldump verrouille les tables pendant la sauvegarde, pouvant bloquer votre tunnel de commande pendant des secondes, voire des minutes.

Export phpMyAdmin

Pour les hébergements mutualisés sans accès SSH : sélectionnez votre base de données, cliquez sur Exporter, choisissez la méthode Personnalisée, activez la compression gzip, cochez « Ajouter DROP TABLE » et exportez. Limitation : cela peut expirer pour les bases de données de plus de 100 Mo.

Sauvegarde intégrée de PrestaShop

Disponible dans Paramètres avancés → Sauvegarde BDD. Pratique pour un instantané rapide avant une modification, mais avec des limitations sérieuses : elle ignore les triggers/procédures stockées, peut expirer sur les grandes bases, stocke la sauvegarde sur le même serveur, et certaines versions de PS produisent des dumps incomplets. À utiliser uniquement en complément.

Compression et automatisation

Les dumps SQL se compressent de 80 à 90 %. Passez toujours par gzip :

# Backup + compress in one step
mysqldump --single-transaction --quick --lock-tables=false \
  -u USER -p'PASS' prestashop | gzip > backup_$(date +%Y%m%d).sql.gz

# Restore from compressed backup
gunzip < backup_20260228.sql.gz | mysql -u USER -p'PASS' prestashop

Sauvegarde quotidienne automatisée avec rotation

Ce script conserve 7 sauvegardes quotidiennes, 4 hebdomadaires et 12 mensuelles :

#!/bin/bash
# /home/user/scripts/backup-db.sh

DB_USER="your_db_user"
DB_PASS="your_db_password"
DB_NAME="prestashop"
BACKUP_DIR="/home/user/backups/database"
DATE=$(date +%Y%m%d_%H%M%S)
DAY_OF_WEEK=$(date +%u)
DAY_OF_MONTH=$(date +%d)

mkdir -p "$BACKUP_DIR"/{daily,weekly,monthly}

# Take the backup
mysqldump --single-transaction --quick --lock-tables=false \
  --routines --triggers \
  -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" \
  | gzip > "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz"

if [ $? -ne 0 ]; then
    echo "BACKUP FAILED at $(date)" | mail -s "BACKUP FAILED" your@email.com
    exit 1
fi

# Weekly snapshot (Sunday)
[ "$DAY_OF_WEEK" -eq 7 ] && cp "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz" \
  "$BACKUP_DIR/weekly/prestashop_weekly_${DATE}.sql.gz"

# Monthly snapshot (1st of month)
[ "$DAY_OF_MONTH" -eq "01" ] && cp "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz" \
  "$BACKUP_DIR/monthly/prestashop_monthly_${DATE}.sql.gz"

# Rotation
find "$BACKUP_DIR/daily/"   -name "*.sql.gz" -mtime +7   -delete
find "$BACKUP_DIR/weekly/"  -name "*.sql.gz" -mtime +28  -delete
find "$BACKUP_DIR/monthly/" -name "*.sql.gz" -mtime +365 -delete
# Add to crontab — runs daily at 3:00 AM
0 3 * * * /home/user/scripts/backup-db.sh >> /home/user/logs/backup.log 2>&1

Méthodes de sauvegarde des fichiers

Sauvegarde complète avec tar

# Full backup excluding unnecessary directories
tar -czf prestashop_files_$(date +%Y%m%d).tar.gz \
  --exclude='var/cache/*' --exclude='var/logs/*' \
  --exclude='var/sessions/*' --exclude='node_modules' \
  /var/www/html/

# Critical files only (faster, smaller)
tar -czf prestashop_critical_$(date +%Y%m%d).tar.gz \
  /var/www/html/{modules,themes,img,upload,override,mails,.htaccess} \
  /var/www/html/app/config/parameters.php

Sauvegarde incrémentielle avec rsync

Pour les grandes boutiques, rsync ne copie que les fichiers modifiés — idéal pour le volumineux répertoire /img/ :

# Local incremental sync
rsync -avz --delete \
  --exclude='var/cache/' --exclude='var/logs/' --exclude='var/sessions/' \
  /var/www/html/ /home/user/backups/files/current/

# Remote sync (off-site — much safer)
rsync -avz --delete \
  --exclude='var/cache/' --exclude='var/logs/' \
  -e "ssh -p 22" \
  /var/www/html/ backupuser@remote-server:/backups/prestashop/

Les images de produits dans /img/p/ changent rarement une fois téléchargées, ce qui rend rsync extrêmement efficace — après la copie initiale complète, les synchronisations quotidiennes ne transfèrent que les images nouvellement ajoutées.

Où stocker les sauvegardes

PAS sur le même serveur

C’est l’erreur de sauvegarde numéro un. Si vos sauvegardes sont sur le même serveur, une défaillance de disque, un ransomware ou une faillite de l’hébergeur anéantit tout simultanément. Les sauvegardes doivent exister dans au moins un emplacement physique séparé.

Options de stockage distant

# Amazon S3
aws s3 sync /home/user/backups/ s3://your-bucket/prestashop/ --storage-class STANDARD_IA

# Backblaze B2 (cheaper than S3, excellent for backups)
b2 sync /home/user/backups/ b2://your-bucket/prestashop/

# Google Cloud Storage
gsutil cp backup.sql.gz gs://your-bucket/prestashop/database/

# SCP/rsync to another server
rsync -avz -e ssh /home/user/backups/ backupuser@backup-server:/backups/prestashop/

La règle 3-2-1

Conservez 3 copies de vos données sur 2 types de stockage différents avec 1 copie hors site. Pour PrestaShop : votre boutique en ligne + une sauvegarde locale sur un disque séparé + une sauvegarde cloud dans une région différente.

Chiffrement des sauvegardes (RGPD)

Les sauvegardes de base de données contiennent des données personnelles de clients. En vertu du RGPD, vous devez également protéger ces données dans les sauvegardes :

# Encrypt with GPG
mysqldump --single-transaction --quick --lock-tables=false \
  -u USER -p'PASS' prestashop | gzip \
  | gpg --symmetric --cipher-algo AES256 --batch --passphrase "STRONG_PASSPHRASE" \
  > backup_$(date +%Y%m%d).sql.gz.gpg

# Decrypt and restore
gpg --decrypt --batch --passphrase "STRONG_PASSPHRASE" backup.sql.gz.gpg \
  | gunzip | mysql -u USER -p'PASS' prestashop
Conservez votre phrase de passe de chiffrement dans un gestionnaire de mots de passe — séparément des sauvegardes. Si vous perdez la phrase de passe, les sauvegardes chiffrées sont définitivement irrécupérables.

Tester vos sauvegardes

Une sauvegarde que vous n’avez pas testée n’est pas une sauvegarde. Problèmes courants qui n’apparaissent qu’au moment d’une vraie restauration : dumps SQL tronqués (limite d’espace disque), fichiers de 0 octet (mot de passe BDD expiré), incompatibilités de version MySQL, permissions de fichiers manquantes, répertoires critiques exclus, ou clés de chiffrement modifiées.

Comment tester

# Create a test database and restore
mysql -u root -p -e "CREATE DATABASE prestashop_test;"
gunzip < backup.sql.gz | mysql -u root -p prestashop_test

# Verify data completeness
mysql -u root -p prestashop_test -e "
  SELECT COUNT(*) AS products FROM ps_product;
  SELECT COUNT(*) AS orders FROM ps_orders;
  SELECT COUNT(*) AS customers FROM ps_customer;
  SELECT MAX(date_add) AS latest_order FROM ps_orders;
"

Pour un test complet : extrayez la sauvegarde des fichiers, mettez à jour parameters.php, chargez le site, vérifiez que la page d’accueil s’affiche avec les images, que la connexion au Back Office fonctionne, que les produits s’affichent correctement et que le tunnel de commande est opérationnel. Planifiez ce test chaque trimestre.

Plan de reprise après sinistre

Écrivez ces procédures et conservez-les dans un endroit accessible même lorsque votre serveur est injoignable.

Scénario 1 : Boutique complètement hors service (panne serveur)

  1. Déterminez l’étendue du problème — votre serveur, le réseau de l’hébergeur, ou le DNS ?
  2. Contactez votre hébergeur ; obtenez un délai estimé et confirmez l’état des données
  3. Si irrécupérable : provisionnez un nouveau serveur avec les mêmes versions d’OS/PHP/MySQL
  4. Restaurez les fichiers à partir de votre sauvegarde distante (pas celle sur le serveur défaillant)
  5. Restaurez la base de données à partir de votre sauvegarde hors site la plus récente
  6. Mettez à jour le DNS si l’adresse IP a changé
  7. Vérifiez le front office, le back office, le tunnel de commande et les e-mails

Scénario 2 : Base de données corrompue

  1. Arrêtez le serveur web : systemctl stop apache2
  2. Essayez d’abord la réparation : mysqlcheck -u root -p --auto-repair prestashop
  3. Si la réparation échoue, restaurez à partir de la sauvegarde : 
    mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
gunzip < latest_backup.sql.gz | mysql -u root -p prestashop
  4. Redémarrez le serveur web, videz le cache PrestaShop
  5. Évaluez la perte de données — vérifiez les identifiants de commande et les horodatages pour identifier l’écart

Scénario 3 : Piratage — fichiers modifiés

  1. Mettez le site hors ligne immédiatement
  2. Conservez les preuves : tar -czf hacked_site.tar.gz /var/www/html/
  3. Identifiez le vecteur d’attaque : 
    find /var/www/html/ -name "*.php" -mtime -7 -ls
grep -rl "eval(base64_decode" /var/www/html/
grep -rl "shell_exec" /var/www/html/modules/
  4. Restaurez les fichiers à partir d’une sauvegarde datée d’avant l’intrusion
  5. Vérifiez la base de données pour détecter des comptes administrateur frauduleux et des modifications de configuration suspectes
  6. Changez TOUS les identifiants : mot de passe BDD, mots de passe admin, FTP, clés SSH, clés API
  7. Mettez à jour le cœur de PrestaShop et tous les modules
  8. Surveillez attentivement pendant 2 à 4 semaines — les attaquants laissent souvent plusieurs portes dérobées

Scénario 4 : Suppression accidentelle d’un module ou d’un thème

  1. Extrayez uniquement le répertoire supprimé de votre sauvegarde de fichiers : 
    tar -xzf prestashop_files_backup.tar.gz \
  --directory /var/www/html/ var/www/html/modules/your_module_name/
  2. Si le module a été désinstallé via le Back Office (tables BDD supprimées), restaurez également la base de données ou réinstallez à partir du ZIP original
  3. Videz le cache PrestaShop

RTO et RPO

  • RTO (Recovery Time Objective) — durée maximale d’indisponibilité acceptable. Un RTO de 4 heures signifie que votre processus de restauration doit être terminé en moins de 4 heures. Un RTO de 15 minutes nécessite une infrastructure de basculement automatique
  • RPO (Recovery Point Objective) — perte de données maximale acceptable. Des sauvegardes quotidiennes = un RPO de 24 heures. Les boutiques à fort volume (des centaines de commandes par jour) devraient viser un RPO de 1 à 4 heures

Calculez votre coût : 100 commandes par jour à 50 EUR en moyenne = environ 200 EUR/heure de chiffre d’affaires perdu pendant l’indisponibilité, plus les dommages en termes de confiance et de SEO.

Restauration à un instant précis

Les sauvegardes quotidiennes laissent un décalage : si le problème est survenu il y a 2 heures et que votre dernière sauvegarde date de 20 heures, vous perdez 20 heures de données. Les journaux binaires de MySQL résolvent ce problème.

Activer la journalisation binaire

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
log_bin = /var/log/mysql/mysql-bin
binlog_expire_logs_seconds = 604800
max_binlog_size = 100M
binlog_format = ROW
systemctl restart mysql
mysql -u root -p -e "SHOW VARIABLES LIKE 'log_bin';"  # Should show ON

Restaurer à un moment précis

# 1. Restore the most recent full backup (from 3:00 AM)
gunzip < daily_backup.sql.gz | mysql -u root -p prestashop

# 2. Replay binlogs up to the moment BEFORE the problem (e.g., 14:29)
mysqlbinlog \
  --start-datetime="2026-02-28 03:00:00" \
  --stop-datetime="2026-02-28 14:29:00" \
  /var/log/mysql/mysql-bin.000042 /var/log/mysql/mysql-bin.000043 \
  | mysql -u root -p prestashop

Cela vous donne l’état exact de la base de données une minute avant l’incident. Cas d’utilisation : suppressions en masse accidentelles, imports ratés, ou récupération des commandes passées entre la dernière sauvegarde et une défaillance de module.

Les journaux binaires consomment de l’espace disque — une boutique active génère des centaines de Mo par jour. Ajustez binlog_expire_logs_seconds pour trouver le bon équilibre entre capacité de restauration et espace disque. Sept jours est une bonne valeur par défaut.

Sauvegardes de l’hébergeur : faites confiance, mais vérifiez

La plupart des hébergeurs annoncent des « sauvegardes quotidiennes » mais la réalité est souvent différente :

  • « Sauvegardes régulières » peut signifier hebdomadaires, pas quotidiennes
  • La restauration peut coûter 50 à 200 EUR par demande et prendre 24 à 48 heures
  • Vous ne pouvez généralement pas restaurer des fichiers ou des tables individuels — c’est tout ou rien
  • La rétention est souvent limitée à 2-3 copies
  • De nombreuses CGV incluent des clauses « non responsable de la perte de données »

Pour vérifier : Demandez à votre hébergeur ce qui est sauvegardé, à quelle fréquence, où les sauvegardes sont stockées et combien sont conservées. Puis demandez une restauration test dans un répertoire temporaire. Vérifiez les dates de sauvegarde dans votre panneau de contrôle — si la plus récente date de 3 semaines, vous avez un problème.

L’hébergement mutualisé comporte des limitations supplémentaires : les sauvegardes peuvent ignorer les comptes de plus de 10 Go, vous n’avez peut-être pas d’accès SSH pour mysqldump, et la restauration écrase toujours votre état actuel. Complétez avec des exports phpMyAdmin et des téléchargements FTP périodiques des répertoires critiques.

Considérez les sauvegardes de votre hébergeur comme un filet de sécurité supplémentaire, jamais comme votre stratégie principale. Vos données, votre responsabilité.

Liste de vérification complète des sauvegardes

Imprimez cette liste et passez-la en revue chaque trimestre.

Quotidien (automatisé)

  • ☐ La sauvegarde de la base de données s’exécute via cron et produit un fichier non vide
  • ☐ La sauvegarde est compressée et copiée vers un stockage distant/hors site
  • ☐ Les anciennes sauvegardes quotidiennes sont soumises à rotation (conservation 7 jours)

Hebdomadaire (automatisé)

  • ☐ La sauvegarde complète ou incrémentielle des fichiers s’exécute
  • ☐ L’instantané hebdomadaire de la base de données est conservé (4 semaines)
  • ☐ La copie vers le stockage distant est synchronisée

Mensuel (automatisé + vérification manuelle)

  • ☐ L’instantané mensuel de la base de données est conservé (12 mois)
  • ☐ Vérifiez que les tâches cron fonctionnent toujours (consultez les logs)
  • ☐ Vérifiez que le stockage distant contient des fichiers récents
  • ☐ Vérifiez l’espace disque sur le stockage de sauvegarde

Trimestriel (manuel)

  • ☐ Test de restauration complet sur un environnement de préproduction
  • ☐ Vérifiez que le nombre d’enregistrements correspond à la production (produits, commandes, clients)
  • ☐ Confirmez que la connexion au Back Office, l’affichage des produits et le tunnel de commande fonctionnent
  • ☐ Documentez la durée de restauration
  • ☐ Passez en revue et mettez à jour votre plan de reprise après sinistre

Avant toute modification majeure

  • ☐ Sauvegarde manuelle avant les mises à jour du cœur de PrestaShop
  • ☐ Sauvegarde manuelle avant l’installation ou la mise à jour de modules
  • ☐ Sauvegarde manuelle avant les migrations de base de données ou les imports en masse
  • ☐ Sauvegarde manuelle avant les modifications de configuration du serveur

Sécurité

  • ☐ Les sauvegardes contenant des données clients sont chiffrées
  • ☐ La phrase de passe de chiffrement est stockée dans un gestionnaire de mots de passe (pas sur le serveur)
  • ☐ Le stockage distant utilise une authentification forte (clés SSH ou jetons API)
  • ☐ Les scripts de sauvegarde utilisent ~/.my.cnf au lieu de mots de passe en clair
  • ☐ Les fichiers de sauvegarde sont en chmod 600 (lisibles uniquement par le propriétaire)

Astuce : Stockage sécurisé des identifiants

# Create ~/.my.cnf so backup scripts don't contain plaintext passwords
cat > ~/.my.cnf << 'EOF'
[mysqldump]
user=your_db_user
password=your_db_password
[mysql]
user=your_db_user
password=your_db_password
EOF
chmod 600 ~/.my.cnf

# Now mysqldump works without -u and -p flags
mysqldump --single-transaction --quick --lock-tables=false prestashop | gzip > backup.sql.gz

Conclusion

Au minimum, chaque boutique PrestaShop a besoin de : sauvegardes automatiques quotidiennes de la base de données avec une rétention de 7 jours, sauvegardes hebdomadaires des fichiers, au moins une copie hors site, des tests de restauration trimestriels et un plan de reprise après sinistre écrit. Tout ce qui va au-delà — restauration à un instant précis, sauvegardes chiffrées, stockage multirégion — s’adapte à la valeur de votre boutique.

Le moment de mettre en place vos sauvegardes, c’est aujourd’hui. Une heure de configuration maintenant peut sauver l’ensemble de votre activité plus tard.

More guides available

Browse our knowledge base for more practical PrestaShop tutorials, or reach out if you need help.

Browse Knowledge Base Contact Us
Back to top