Tutoriel PrestaShop 1.7.8PrestaShop 8.xPrestaShop 9.x

Sauvegarder sa boutique PrestaShop avant une intervention

Fichiers, base de données et clés de chiffrement : ce qu'une sauvegarde PrestaShop doit contenir, comment la faire, et comment vérifier qu'elle se restaure.

Mise à jour de PrestaShop, installation d'un module, changement de thème, passage à une nouvelle version de PHP : avant chacune de ces opérations, une sauvegarde complète est votre seule assurance de pouvoir revenir en arrière. Encore faut-il qu'elle soit complète, et qu'elle se restaure. Ce guide détaille les deux volets d'une sauvegarde PrestaShop, les fichiers et la base de données, et le contrôle qui transforme une copie en véritable sauvegarde.

Ce qu'une sauvegarde doit contenir

Une boutique PrestaShop, ce sont deux ensembles indissociables :

  • les fichiers : le code de PrestaShop, vos modules, votre thème, vos images produits, les fichiers téléchargés par vos clients ;
  • la base de données : produits, clients, commandes, configuration.

Les deux doivent être sauvegardés au même moment. Une base de données de mardi avec les fichiers de lundi, c'est par exemple un module présent en base mais absent des fichiers, ou des images de produits manquantes.

Volet 1 : les fichiers

Le plus sûr est de sauvegarder tout le dossier de la boutique. Si vous devez faire des choix, voici les dossiers qui contiennent des données propres à votre boutique, présents dans les trois versions :

Dossier Contenu
app/config/ paramètres de connexion et clés de chiffrement (voir plus bas)
config/ réglages complémentaires, éventuels fichiers *_custom.inc.php
img/ images des produits, catégories, marques, logo
modules/ tous les modules installés, avec leurs réglages en fichiers
themes/ votre thème et ses éventuelles personnalisations
override/ les surcharges de classes du cœur
upload/ et download/ fichiers envoyés par les clients, produits téléchargeables
translations/ et mails/ traductions et modèles d'e-mails personnalisés
var/modules/ données de certains modules (versions 8 et 9 uniquement)

Le dossier var/cache/ peut être exclu : PrestaShop le reconstruit automatiquement. Exclure var/logs/ allège aussi l'archive, mais ces journaux peuvent servir si l'intervention tourne mal.

En SSH, une archive compressée se crée ainsi :

# Depuis le dossier parent de la boutique ; adaptez « boutique » et le chemin de destination
tar -czf ~/sauvegardes/boutique-fichiers-$(date +%F-%H%M).tar.gz \
    --exclude='boutique/var/cache' \
    boutique/

Sans accès SSH, téléchargez le dossier entier par FTP, ou utilisez l'outil de sauvegarde de votre panneau d'hébergement.

Le fichier à ne jamais perdre : app/config/parameters.php

Ce fichier est créé à l'installation de la boutique. Il contient les identifiants de connexion à la base de données, mais aussi des clés de chiffrement propres à votre boutique, notamment :

  • cookie_key : utilisée pour le hachage (transformation irréversible) des mots de passe des comptes clients anciens, et dans certains jetons de sécurité ;
  • new_cookie_key : utilisée pour chiffrer les cookies des visiteurs ;
  • cookie_iv et secret, et en versions 8 et 9 api_public_key et api_private_key.

Ces clés ne peuvent pas être recréées à l'identique. Si vous restaurez une base de données avec un parameters.php d'une autre installation, les clients dont le mot de passe utilise encore l'ancien format ne pourront plus se connecter. Pire, dans les trois versions, si une clé manque dans le fichier, PrestaShop en génère une aléatoire à chaque chargement, sans message d'erreur (config/bootstrap.php). La boutique semble fonctionner, mais les connexions échouent de façon inexplicable.

Conservez donc une copie de parameters.php à part, dans un endroit sûr : il contient le mot de passe de votre base de données.

Volet 2 : la base de données

Avec l'outil du back office

PrestaShop intègre un outil de sauvegarde dans Paramètres avancés > Base de données > Sauvegarde BDD, présent en 1.7.8, 8 et 9. Il a des caractéristiques à connaître :

  • il ne sauvegarde que les tables qui portent le préfixe de la boutique (ps_ par défaut). Une table créée par un module sans ce préfixe est ignorée ;
  • une option permet d'exclure les données des tables de statistiques de visite (connections, connections_page, connections_source, guest, statssearch), souvent les plus volumineuses ;
  • le fichier est compressé (format .bz2 ou .gz selon le serveur) et rangé dans le sous-dossier backups/ de votre dossier d'administration ;
  • il ne sait pas restaurer : aucune version ne propose de restauration depuis le back office. Il faudra importer le fichier avec phpMyAdmin ou en ligne de commande.

Pensez à télécharger le fichier puis à le supprimer du serveur : une sauvegarde laissée dans un dossier du site est une copie de toutes vos données clients.

Sur une base volumineuse, la génération par le back office peut aussi s'interrompre avant la fin, à cause des limites de temps d'exécution de PHP. Pour une boutique de taille importante, préférez la ligne de commande.

Avec mysqldump, en SSH

Relevez les valeurs database_host, database_name, database_user et database_password dans app/config/parameters.php, puis :

# Depuis n'importe quel dossier ; le mot de passe est demandé de façon interactive
mysqldump --single-transaction --default-character-set=utf8mb4 \
    -h database_host -u database_user -p database_name \
    | gzip > ~/sauvegardes/boutique-base-$(date +%F-%H%M).sql.gz

Deux options méritent une explication :

  • --default-character-set=utf8mb4 : c'est le jeu de caractères qu'utilise PrestaShop pour toutes ses tables, en 1.7.8 comme en 8 et 9. Un autre réglage peut abîmer les accents et les emojis à la restauration ;
  • --single-transaction : la copie est cohérente sans bloquer la boutique pendant l'export, à condition que les tables soient au format InnoDB. C'est le format proposé par défaut à l'installation, mais PrestaShop accepte aussi MyISAM.

Pour vérifier qu'aucune table n'est restée en MyISAM :

-- Dans phpMyAdmin ou le client mysql ; remplacez nom_de_la_base
SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'nom_de_la_base' AND ENGINE <> 'InnoDB';

Si la requête renvoie des tables, la sauvegarde reste possible, mais faites-la boutique en maintenance pour éviter qu'une commande s'enregistre pendant l'export.

Différences selon la version

Point 1.7.8 8 9
Outil de sauvegarde BDD du back office oui oui oui
Restauration depuis le back office non non non
Clés api_public_key / api_private_key dans parameters.php non oui oui
Dossier var/modules/ non oui oui
Clé manquante remplacée silencieusement par une clé aléatoire oui oui oui

Le module de mise à jour en un clic (autoupgrade) propose sa propre sauvegarde avant une mise à niveau. Il ne fait pas partie du code de PrestaShop : il s'installe à part. Une sauvegarde indépendante, faite par vous juste avant, reste recommandée.

Quand sauvegarder, et combien de copies garder

La sauvegarde « avant intervention » se fait juste avant l'opération, pas la veille : une nuit de commandes suffit à rendre une restauration douloureuse, puisqu'il faudrait ressaisir les commandes passées entre-temps. Pour la même raison, notez l'heure exacte de la sauvegarde : en cas de retour en arrière, vous saurez quelles commandes reprendre à la main depuis les e-mails de confirmation ou votre prestataire de paiement.

En dehors des interventions, une sauvegarde régulière automatique protège contre ce qu'on ne prévoit pas : piratage, erreur de manipulation, panne de disque. Le rythme que nous appliquons chez nos clients : une sauvegarde quotidienne de la base de données et des fichiers, réalisée par des procédures de sauvegarde automatiques, avec plusieurs générations conservées. Un piratage est souvent découvert des jours après l'intrusion : une seule copie, écrasée chaque nuit, serait déjà infectée.

Si votre hébergement permet les tâches planifiées, une ligne de ce type lance la sauvegarde de la base chaque nuit à 2 h 30 :

# crontab -e — le mot de passe est lu dans ~/.my.cnf (section [mysqldump]) plutôt qu'écrit dans la commande
30 2 * * * mysqldump --single-transaction --default-character-set=utf8mb4 -h database_host -u database_user database_name | gzip > ~/sauvegardes/base-$(date +\%F).sql.gz

Le % doit être précédé d'une barre oblique inverse dans une crontab, sinon la commande est coupée à cet endroit. Prévoyez aussi le ménage des anciennes copies, pour ne pas saturer l'espace disque.

Vérifier qu'une sauvegarde se restaure

Une sauvegarde jamais restaurée n'est qu'une hypothèse. Au moins une fois, et après chaque changement d'hébergement, testez la restauration sur une copie : un sous-domaine de test, ou une installation locale.

  1. Décompressez l'archive des fichiers dans le dossier de test.
  2. Créez une base vide et importez-y la sauvegarde : 
    # Depuis le dossier qui contient la sauvegarde
gunzip -c boutique-base-AAAA-MM-JJ-HHMM.sql.gz | mysql -h hote -u utilisateur -p base_de_test
  3. Dans app/config/parameters.php de la copie, adaptez uniquement les valeurs database_*. Ne touchez pas aux clés.
  4. Dans la base de test, remplacez le nom de domaine dans la table ps_shop_url (colonnes domain et domain_ssl) et dans les réglages PS_SHOP_DOMAIN et PS_SHOP_DOMAIN_SSL de la table ps_configuration.
  5. Videz le contenu de var/cache/, ouvrez la copie, connectez-vous au back office et avec un compte client.

Si tout fonctionne, vous avez une sauvegarde. Pensez à bloquer l'accès de la copie (mot de passe sur le dossier ou mode maintenance) et à désactiver ses e-mails, pour ne pas écrire à vos clients depuis la boutique de test.

Pièges connus

  • Sauvegarde stockée uniquement sur le serveur de la boutique : si le serveur tombe, elle tombe avec. Gardez une copie ailleurs.
  • Tables sans préfixe ignorées par l'outil du back office : mysqldump sauvegarde toute la base.
  • Instantanés de l'hébergeur : utiles, mais vérifiez ce qu'ils incluent (la base est parfois sur un autre serveur) et combien de temps ils sont conservés.
  • Ce qui vit hors du dossier de la boutique : configuration du serveur web, réglages PHP personnalisés, tâches planifiées, certificats. Ces éléments ne sont ni dans l'archive ni dans la base. Notez-les au moins une fois par écrit : sans eux, une boutique restaurée sur un nouveau serveur ne se comportera pas comme avant.
  • parameters.php d'une autre installation : clients bloqués à la connexion, sans message d'erreur explicite.

sauvegardemysqldumpparameters.phpcookie_keyrestauration

← Tous les articles