Sauvegarde PrestaShop : le dump BDD ne suffit pas

Un dimanche soir, une boutique PrestaShop ne répond plus. La page produit est blanche et curl renvoie un 500 muet. Le dernier dump date de trois jours. On le restaure depuis l’admin MySQL, le site redémarre. Quatre jours plus tard, la Search Console montre 800 URLs en « Page avec redirection » parce que les clés d’URL rewriting stockées en base étaient décalées. Le LCP mobile est passé à 6,8 secondes. La sauvegarde n’était pas le problème. C’est ce qu’il s’est passé entre le dump et la remise en ligne qui a tout détruit.

Le vrai risque avec une base PrestaShop n’est pas la perte des données. C’est la réintégration silencieuse d’une structure fragile que Googlebot va consommer avant même que tu aies ouvert les DevTools. Voici comment sauvegarder et restaurer sans casser l’indexation ni plomber tes scores sur les Core Web Vitals.

Dumper la base n’est pas une sauvegarde

Un fichier .sql brut ne contient pas la configuration des caches, les index, ni les fichiers générés qui dépendent de la base. PrestaShop stocke en base ses règles d’URL simplifiées, les métas SEO, les opérations de l’AdminController. Si tu ne récupères que les tables, tu obtiens un squelette qui, une fois restauré, va forcer le CMS à tout regénérer. Et générer en masse pendant que Googlebot passe, c’est la recette d’un TTFB dégradé et d’une indexation partielle.

Une sauvegarde complète embarque le dossier /var/cache, le contenu de /themes, et surtout une copie binaire des index InnoDB (via mysqldump --routines --triggers --events --single-transaction). Oublie phpMyAdmin pour les boutiques qui dépassent quelques centaines de commandes. L’IHM segmente l’export si le fichier dépasse la max_execution_time, et tu finis avec des inserts coupés en plein milieu d’une table ps_product_shop. Le site te paraît stable, mais Googlebot rencontre une erreur fatale au milieu du crawl. Et il ne revient pas de sitôt.

Exécuter un dump cohérent avec un minimum de verrous

mysqldump -u [user] -p \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --default-character-set=utf8mb4 \
  [database] > backup_$(date +%Y%m%d).sql

Le flag --single-transaction verrouille les tables en lecture cohérente sans bloquer les écritures si le moteur est InnoDB. C’est ce qui permet de continuer à prendre des commandes pendant le dump. Sans ça, un FLUSH TABLES WITH READ LOCK bloque les inserts le temps de l’export. Sur une boutique avec 10 commandes par minute, le verrou casse les transactions en cours et déclenche des erreurs 503 que Googlebot enregistre comme une instabilité.

Tu remarqueras --default-character-set=utf8mb4. Quand tu lis un dump restauré sur un serveur qui tire l’encodage par défaut en latin1, les caractères multibytes (les émojis, certains accents) deviennent des points d’interrogation. Des URL produit comme /pâtisserie/éclair-chocolat deviennent /p?tisserie/?clair-chocolat. La Search Console ne voit pas les balises canoniques qui pointaient vers l’URL propre. Résultat : des doublons d’indexation et un signal de contenu dupliqué.

⚠️ Attention : Si ta boutique utilise encore des tables MyISAM, le --single-transaction ne suffit pas. MyISAM va poser un verrou de lecture entier, blocage garanti. Migre ces tables vers InnoDB avant toute opération de dump.

Restaurer sans casser l’indexation

La restauration n’est pas la commande inverse. Un import avec mysql < dump.sql réinjecte les données mais ne recrée pas les index internes de PrestaShop. Le cache des URLs et les schémas de recherche sont réinitialisés différemment selon le SGBD. Résultat : tant que le back-office n’a pas recalculé les règles de réécriture, les URLs simplifiées ne sont pas servies en 301 canonique mais renvoyées sous forme d’URL dynamiques. Googlebot découvre deux versions par page et stabilise l’index sur la mauvaise.

On voit souvent ce cas quand la table ps_configuration est importée avec des valeurs périmées de PS_SHOP_DOMAIN ou PS_SSL_ENABLED. Une fois la restauration terminée, passe par ces étapes, dans cet ordre :

• Vide manuellement le dossier var/cache/prod/ et var/cache/dev/
• Lance depuis l’admin ou en CLI la régénération du .htaccess (ce qui réactive les règles de redirection des URLs simplifiées)
• Mets à jour les champs physical_uri dans la base si le chemin du dossier a changé
• Forcer la régénération des miniatures pour éviter que la page de listing produit sollicite 250 fichiers absents et fasse monter le LCP.

Une fois ces actions faites, fais un crawl rapide local avec un outil qui émule Googlebot et vérifie le code retour de chaque URL catalogue. Si tu constates des redirections en chaîne, il y a un delta entre la base restaurée et la configuration du serveur. Le souci vient rarement du dump, mais de ce que le .htaccess contient après régénération.

Le lien silencieux entre la restauration BDD et les Core Web Vitals

Un développeur regarde la console MySQL. Un SEO regarde la Search Console. Mais après une restauration, c’est le même tableau de bord qui hurle. Le LCP bondit parce que PrestaShop, privé de son cache noyau, recompose chaque page produit avec des requêtes SQL non optimisées. Un LEFT JOIN sur ps_product_attribute qui prenait 0,3 ms peut monter à 80 ms s’il manque un index ou si le cache de requêtes est vide. Les 20 requêtes par page s’accumulent, et le TTFB passe de 200 ms à plus de 1 200 ms. Si le site est derrière un proxy ou un CDN, ce n’est pas toujours visible dans Chrome, mais le rapport « Core Web Vitals » de la Search Console ne ment pas : 45 % de l’audience mobile passe au-dessus du seuil « Poor » en moins de 24 heures.

Pour rattraper ça après une restauration, active le profilage SQL pendant le premier crawl. Identifie les requêtes qui scannent des tables entières et ajoute les index manquants. Dans PrestaShop, c’est souvent id_product mal indexé dans les tables de déclinaisons ou l’absence d’index sur active dans ps_product_shop. Une fois les index créés, un nouvel appel à ANALYZE TABLE force le moteur à reconstruire les statistiques. Ensuite, vérifie l’impact dans un test de performance avant que Googlebot ne repasse. Tu peux croiser ces signaux avec les données de la page /optimisation-core-web-vitals/ pour comprendre comment isoler la cause entre le backend et le frontend.

Script d’automatisation : ne te fie pas à l’admin hébergeur

Beaucoup d’hébergeurs mutualisés proposent un backup journalier. Mais les restaurations « en un clic » ne réappliquent pas les droits, ne recréent pas les index, et ignorent la table ps_connections corrompue parce que le dump a été fait en mode rapide. Ce qui te donne une boutique en ligne mais non crawlable jusqu’au prochain passage de Googlebot.

Automatise plutôt un export quotidien via une tâche cron. Voici un squelette bash léger qui tourne en dehors du docroot :

#!/bin/bash
TIMESTAMP=$(date +%Y%m%d-%H%M)
mysqldump --defaults-extra-file=/home/user/.my.cnf \
  --single-transaction --routines --triggers --events \
  --default-character-set=utf8mb4 prestashop > /backup/db_$TIMESTAMP.sql
tar -czf /backup/files_$TIMESTAMP.tar.gz /var/www/html

Le fichier .my.cnf évite d’exposer le mot de passe dans les logs et empêche un prompt silencieux qui bloque le dump. Une fois le dump terminé, un petit script de test restaure le fichier dans une base temporaire et lance un SELECT COUNT(*) FROM ps_product pour s’assurer que les lignes sont complètes. Si la restauration échoue, le cron envoie une alerte. Sinon, il supprime les backups de plus de 7 jours. Cette vérification prend moins de trente secondes et t’évite le cauchemar du backup qui pèse 1,2 Go et qui s’avère vide de la moitié des tables.

Le test qui manque à tous les tutos

Dumper, restaurer, c’est la partie facile. La seule validation qui compte, c’est un crawl intégral sur une URL de staging. Passe un Screaming Frog, un Sitebulb ou un utilitaire headless sur la boutique restaurée. Vérifie trois choses :

1. Aucun code HTTP 5xx sur les 50 premières pages du catalogue
2. Les balises canoniques pointent sur les URLs propres, pas sur des paramètres ?id_product=
3. Le fichier sitemap.xml généré après restauration contient le même nombre d’URLs que la veille.

Un décalage de 30 % sur le sitemap signifie que des produits ne sont plus associés à une URL simplifiée ou que la table ps_hook_module ne référence plus la bonne version du module de sitemap. Tant que ce test n’est pas vert, ne bascule pas le DNS. Une heure de staging crawlée vaut trois semaines de perte d’indexation.

Questions fréquentes

Faut-il arrêter la boutique pendant la sauvegarde ? Avec InnoDB et --single-transaction, non. Le dump photographie l’état de la base au moment de la commande sans interrompre les nouvelles commandes. Les tables MyISAM posent en revanche un verrou global. Il suffit de les convertir pour éviter l’interruption.

La sauvegarde de l’admin PrestaShop est-elle suffisante ? Le module de sauvegarde intégré ne couvre que les tables de la base. Il ignore les fichiers de thème, les overrides, les modules non natifs et surtout les configurations de cache. Une boutique complète exige une duplication des fichiers et un dump complet en dehors du CMS.

À quelle fréquence réaliser une sauvegarde complète ? Pour une boutique qui reçoit plus de 50 commandes par jour, un dump quotidien et une copie incrémentielle des médias toutes les 6 heures évitent de perdre les avis clients et les logs de stock. Le coût de stockage est négligeable comparé à la perte d’une journée de transactions.