Sauvegardes PrestaShop automatiques : la méthode fiable en 2026

Votre boutique PrestaShop tourne, les commandes rentrent — mais avez-vous vraiment testé votre dernière sauvegarde ? Pas configuré une alerte en cas d’échec ? Pas vérifié que le fichier exporté n’est pas corrompu ?

Si vous répondez non à l’une de ces questions, vous n’avez pas de sauvegarde fiable. Vous avez l’illusion d’une sauvegarde.

Pourquoi la sauvegarde native PrestaShop est insuffisante

PrestaShop intègre un outil de sauvegarde en back-office (Paramètres avancés > Sauvegarde BDD). À première vue pratique, il est en réalité dangereux à utiliser comme seule solution :

• Limite de taille : sur les boutiques de plus de 2–3 ans avec un historique de commandes conséquent, la base de données dépasse régulièrement la limite d’export PHP (souvent bloqué à 128 Mo ou moins selon la config hébergeur). Le dump s’interrompt sans avertissement.
• BDD uniquement : l’outil natif ne sauvegarde que la base de données. Vos images produits, vos fichiers de thème personnalisé, vos modules sur mesure et vos overrides restent hors scope.
• Stockage local : les fichiers générés sont déposés dans /backup/ sur votre propre serveur. Si le disque lâche ou si le serveur est compromis, la sauvegarde disparaît avec le reste.
• Aucune automatisation native : il faut se connecter manuellement, lancer l’export, télécharger le fichier. En pratique, cette opération est différée, puis oubliée.

Ce qu’il faut sauvegarder

Une sauvegarde complète d’une boutique PrestaShop couvre trois périmètres :

1. La base de données C’est le cœur vivant de votre boutique : catalogue, clients, commandes, configurations. Un dump MySQL complet suffit. Taille typique : de 50 Mo à plusieurs gigaoctets selon l’ancienneté de la boutique.

2. Les fichiers critiques

• img/ : photos produits, catégories, marques — souvent plusieurs gigaoctets
• themes/<votre-thème>/ : personnalisations CSS, templates Smarty modifiés
• modules/ : vos modules achetés ou développés sur mesure
• override/ : toutes vos surcharges de classes et controllers PrestaShop
• app/config/parameters.php (PS 8.x) ou config/settings.inc.php (PS 1.7 et antérieur) : contient les identifiants BDD et clés de chiffrement. Sans ce fichier, vous ne pouvez pas restaurer.

3. Les fichiers de configuration serveur .htaccess, robots.txt, éventuellement votre configuration Nginx ou Apache si vous gérez votre propre serveur.

3 méthodes pour automatiser vos sauvegardes

Méthode 1 : cron + mysqldump (la méthode pro)

C’est la méthode la plus fiable si vous avez accès SSH à votre serveur. Vous créez un script shell qui :

1. Exécute un mysqldump de votre base PrestaShop
2. Compresse l’archive avec gzip
3. Copie le tout vers un stockage externe (voir section suivante)
4. Supprime les archives locales de plus de 7 jours

#!/bin/bash
DATE=$(date +%Y%m%d_%H%M)
mysqldump -u USER -pPASSWORD NOM_BDD | gzip > /backup/ps_bdd_$DATE.sql.gz
tar -czf /backup/ps_files_$DATE.tar.gz /var/www/html/img/ /var/www/html/themes/ /var/www/html/modules/ /var/www/html/override/

Ce script est ensuite planifié via crontab -e pour s’exécuter chaque nuit à 3h. Résultat : une sauvegarde complète sans intervention manuelle.

Méthode 2 : module PrestaShop de backup

Des modules spécialisés (1-Click Backup Pro, Store Manager Backup…) permettent de planifier des sauvegardes directement depuis le back-office, sans accès SSH. Ils gèrent BDD + fichiers et proposent souvent l’envoi automatique vers un espace cloud.

C’est la solution idéale pour les marchands hébergés sur des mutualisés sans accès shell. Vérifiez que le module supporte bien PrestaShop 8.x si vous avez migré.

Méthode 3 : sauvegarde hébergeur — pratique mais insuffisante seule

La plupart des hébergeurs (OVH, PlanetHoster, o2switch…) proposent des snapshots automatiques quotidiens ou hebdomadaires. C’est une filet de sécurité utile, mais avec deux limites importantes :

• La rétention est souvent courte (7 à 14 jours)
• En cas d’incident majeur (incident datacenter, compromission hébergeur), la sauvegarde peut être affectée également

Utilisez la sauvegarde hébergeur comme couche supplémentaire, jamais comme seule solution.

Fréquence selon votre volume de commandes

Activité boutique	Fréquence recommandée
Boutique active (>10 commandes/jour)	Quotidienne
Boutique modérée (1–10 commandes/jour)	Tous les 2 jours
Boutique en veille ou catalogue pur	Hebdomadaire

Une règle simple : demandez-vous combien de commandes vous seriez prêt à perdre. Si la réponse est « zéro », la sauvegarde doit être quotidienne.

Stockage externe obligatoire

Quel que soit votre méthode, les fichiers de sauvegarde ne doivent jamais rester uniquement sur le serveur de production. Un disque défaillant, un ransomware, une erreur humaine — et vous perdez à la fois la boutique et ses sauvegardes.

Les solutions recommandées :

• Amazon S3 ou Backblaze B2 : très fiables, prix à la Go, scripts d’envoi via rclone ou aws-cli
• Google Drive ou Dropbox : plus accessible pour les non-techniciens, via rclone également
• Serveur distant dédié : si vous gérez plusieurs boutiques, un VPS dédié aux backups est une option sérieuse

Conservez au minimum 2 semaines de rétention pour pouvoir revenir à un état propre avant une infection ou une corruption non détectée immédiatement.

Tester la restauration : aussi important que la sauvegarde

Un backup non testé n’est pas un backup. C’est une promesse sans garantie.

Au moins une fois par trimestre, procédez à une restauration de test sur un environnement staging :

1. Montez une instance PrestaShop vierge (local ou sous-domaine de test)
2. Importez votre dump SQL via mysql -u USER -pPASSWORD NOM_BDD < dump.sql
3. Copiez vos fichiers img/, themes/, modules/, override/
4. Restaurez settings.inc.php ou parameters.php avec les identifiants du serveur de test
5. Vérifiez : le front-office s’affiche, les produits sont là, un compte client est accessible

Ce test vous confirmera que vos sauvegardes sont complètes, non corrompues, et que vous savez réellement comment les utiliser sous pression.

Procédure de restauration pas à pas

En cas de sinistre réel :

1. Sécurisez d’abord : mettez le site en maintenance (_PS_MODE_DEV_ à false, activez une page de maintenance temporaire)
2. Restaurez les fichiers : dézippez l’archive sur le serveur, vérifiez les droits (souvent www-data)
3. Restaurez la BDD : créez une base vide, importez le dump SQL
4. Mettez à jour settings.inc.php avec les nouveaux identifiants si vous changez de serveur
5. Videz le cache : supprimez var/cache/ (PS 8.x) ou cache/ (PS 1.7)
6. Testez avant de sortir du mode maintenance

La maintenance préventive PrestaShop, dont font partie les sauvegardes automatisées, est un investissement bien inférieur au coût d’une remise en ligne d’urgence. Si vous souhaitez externaliser cette gestion, découvrez notre maintenance PrestaShop — nous configurons et supervisons vos sauvegardes automatiques pour vous.