Date: 15 juin 2026
Stratégie de backup pour e-commerce : sauvegarder PrestaShop, WooCommerce et Shopify sans perte de données

Un client a perdu 3 semaines de commandes quand son hébergeur a subi une panne disque. Sa sauvegarde WooCommerce était censée tourner toutes les nuits. Depuis 4 mois, elle échouait silencieusement à cause d'un problème de permissions. 23 000 € de commandes non restaurées. Voici comment construire une stratégie de backup qui fonctionne vraiment, pour PrestaShop, WooCommerce et Shopify.

La règle d'or des sauvegardes, c'est le 3-2-1 : 3 copies des données, sur 2 supports différents, dont 1 hors site. Pour un e-commerce, cette règle s'applique à trois types de données : les fichiers (thème, modules, images), la base de données (produits, commandes, clients), et la configuration (variables d'environnement, clés API). Chacun a ses spécificités de sauvegarde.

Ce qu'il faut sauvegarder (par ordre de priorité)

DonnéeFréquenceTaille typiquePriorité
Base de donnéesToutes les 6h100 Mo - 2 GoCritique
Fichiers (uploads, images)Quotidien500 Mo - 10 GoHaute
Thème et modulesHebdomadaire50 - 500 MoMoyenne
Configuration (.env, clés API)À chaque modificationQuelques KoHaute

La base de données est la donnée la plus critique : sans elle, vous perdez les commandes, les clients et les produits. Les fichiers (images uploadées) sont volumineux et prennent du temps à restaurer. La configuration est petite mais vitale : sans les clés API, votre site ne se connecte à rien.

Sauvegarde automatisée avec script bash

Un script bash simple, lancé par cron, peut sauvegarder votre boutique automatiquement. Voici le principe :

  • Base de données : mysqldump pour MariaDB/MySQL, ou pg_dump pour PostgreSQL. Compressez l'export en .sql.gz (divise la taille par 5 à 10).
  • Fichiers : rsync ou tar du dossier /var/www/html. Excluez les caches (var/cache, var/session) qui se régénèrent automatiquement.
  • Configuration : copie des fichiers .env et des clés API dans un dossier sécurisé.

Le script doit envoyer les sauvegardes vers un stockage externe : Backblaze B2 (6 $/To/mois), S3 (à partir de 0.023 $/Go/mois), ou un second VPS chez un autre hébergeur. N'utilisez jamais le même serveur pour les sauvegardes et le site : si le serveur brûle, vous perdez tout.

Spécificités par CMS

PrestaShop. La base de données contient les commandes, clients, produits, configurations, et les logs. mysqldump avec --single-transaction évite de bloquer les écritures pendant la sauvegarde. Les fichiers importants : /img (photos produits), /themes, /modules, /override. Les fichiers à exclure : /cache, /tools, /upload (sauf si vous stockez des fichiers téléchargés par les clients). Les accès à l'interface de sécurité PrestaShop doivent être vérifiés régulièrement.

WooCommerce. La base de données WordPress contient les posts (produits), les postmeta (attributs, prix), les options (configuration Woo), et les tables WooCommerce dédiées (actions, sessions). Utilisez wp-cli db export pour une sauvegarde fiable en ligne de commande. Les fichiers : /wp-content/uploads (images produits), /wp-content/themes, /wp-content/plugins. Complétez avec mon guide sur la sauvegarde et maintenance WooCommerce.

Shopify. La plateforme gère l'infrastructure, mais vous êtes responsable de vos données. Utilisez les exports CSV natifs (produits, clients, commandes) via l'admin Shopify. Pour une sauvegarde automatique, utilisez l'API REST Shopify (endpoints /admin/api/2024-07/products.json) couplée à un script Python ou n8n. Sauvegardez aussi les fichiers du thème (via Github integration ou API).

Tester la restauration (l'étape que tout le monde saute)

Avoir une sauvegarde qui ne se restaure pas, c'est comme avoir une assurance qui ne rembourse pas. Je recommande un test de restauration complet tous les 3 mois :

  1. Installez un serveur de test vierge (même version de PHP, MySQL, CMS).
  2. Restaurez la base de données (vérifiez les collations, les préfixes de tables).
  3. Restaurez les fichiers (attention aux permissions).
  4. Vérifiez que le site s'affiche, que les commandes sont visibles, que les connexions API fonctionnent.

Ce test prend 2 heures et révèle presque toujours un problème. Permissions incorrectes, version PHP incompatible, préfixe de table différent : mieux vaut le découvrir sur un test que le jour de la panne. La maintenance serveur que je propose inclut un test de restauration trimestriel.

Les 2 erreurs que je vois le plus souvent

1. Des sauvegardes qui échouent en silence. Un problème de permissions, un disque plein, une mise à jour qui change le chemin des fichiers : la sauvegarde échoue sans prévenir. Mettez en place une notification (email ou Slack) à chaque échec. Mon script envoie un résumé quotidien : "Sauvegarde OK : DB 340 Mo, Files 1.2 Go, uploadés vers B2 en 4 min."

2. Garder la sauvegarde sur le même serveur. Si le serveur est piraté ou subit une panne disque, la sauvegarde locale part avec le reste. La copie hors site (B2, S3, autre hébergeur) est non négociable. Pour quelques euros par mois, vous avez une copie indépendante et sécurisée.

FAQ : Sauvegarde e-commerce

Combien coûte une solution de backup complète ?

Pour un petit e-commerce (1 Go de données), comptez 1 à 3 €/mois de stockage externe (Backblaze B2). Pour un catalogue de 10 000 produits (10-20 Go de données), comptez 5 à 10 €/mois. Le script de sauvegarde est gratuit (vous pouvez utiliser le mien). La main-d'œuvre : si vous le configurez vous-même, 1 à 2 heures. Si vous le confiez, comptez 150 à 300 € pour la mise en place initiale.

Faut-il sauvegarder aussi les emails ?

Si vous utilisez des emails transactionnels (Shopify, WooCommerce) via un service externe (Sendinblue, Mailgun), vos emails sont sauvegardés par le service. Si vous utilisez un serveur SMTP interne, sauvegardez aussi les boîtes mail et les logs d'envoi. Les emails de confirmation de commande sont importants en cas de litige client.

Quelle est la différence entre sauvegarde et snapshot ?

Un snapshot est une image instantanée du disque du serveur. Rapide à créer, mais dépendant du même serveur physique. Une sauvegarde est une copie des données dans un format standard (SQL, fichiers) stockée ailleurs. En cas de défaillance du datacenter, le snapshot part avec le serveur, la sauvegarde reste accessible. Utilisez les deux : snapshot quotidien (rapide) + sauvegarde complète vers un stockage externe.

Puis-je restaurer sur un serveur différent en cas de panne ?

Oui, si les versions de PHP, MySQL et du CMS sont compatibles. C'est pourquoi j'utilise Docker pour mes clients : le conteneur garantit un environnement identique partout. Restaurer une sauvegarde Docker sur un nouveau serveur prend 30 minutes au lieu de 3 heures. Voir mon guide sur Docker pour les services e-commerce.


Vous voulez vérifier que vos sauvegardes fonctionnent vraiment ? Je vous propose un audit de backup gratuit : je teste la restauration de votre dernière sauvegarde et je vous dis si elle est fiable.

Pour aller plus loin, découvrez ma page dédiée au infogérance et sauvegarde.

Nicolas Pivaut, consultant SEO e-commerce
Écrit par Nicolas Pivaut

Consultant SEO e-commerce et expert Adobe Analytics, dans le web depuis 2007. J'aide les boutiques en ligne à gagner des clients grâce au référencement naturel.