La plupart des e-commerçants pensent être sauvegardés. La majorité ne l’est pas vraiment. Sur les audits que nous menons, 6 boutiques sur 10 n’ont pas de sauvegarde restaurable en moins de 4 heures, 3 sur 10 ont des sauvegardes corrompues ou incomplètes, et environ 1 sur 10 n’a aucune sauvegarde exploitable depuis plus d’un mois — souvent sans le savoir.
Le coût d’un incident sans sauvegarde fonctionnelle, c’est entre 24 h et plusieurs semaines d’arrêt, des données clients perdues, et parfois la cessation d’activité. Cet article décrit la stratégie de sauvegarde qu’on devrait avoir en 2026 sur une boutique PrestaShop : la règle 3-2-1, le chiffrement, la rotation, et surtout — la restauration testée.
Pourquoi les sauvegardes par défaut ne suffisent pas
« Mon hébergeur fait des sauvegardes » est la phrase qui revient le plus souvent. C’est vrai en général, et insuffisant en pratique :
- Les sauvegardes hébergeur sont sur le même datacenter. Un incendie majeur (OVH Strasbourg 2021), une attaque ransomware, ou un compromis du panneau d’admin de l’hébergeur, et les sauvegardes brûlent avec les données.
- La rétention est courte. 7 à 14 jours pour les offres standard. Si vous découvrez un défacement ou une corruption 3 semaines après, la sauvegarde infectée a déjà remplacé la sauvegarde saine.
- La sauvegarde inclut-elle vraiment tout ? Beaucoup d’hébergeurs sauvegardent la base mais pas les fichiers, ou inversement. Et les uploads (images produits, factures PDF, exports) sont parfois oubliés.
- La restauration n’est jamais testée. Le jour J, on découvre que la procédure de restauration ne fonctionne pas, ou prend 36 heures, ou demande l’accès à un panneau qu’on a perdu.
- Pas de chiffrement. Une sauvegarde non chiffrée hébergée chez un tiers, c’est l’ensemble de votre base clients exposé en cas de fuite chez le prestataire.
La règle 3-2-1 : référence industrielle depuis 30 ans
Formulée par le photographe Peter Krogh en 2005 pour les sauvegardes numériques, adoptée par l’ANSSI, le CISA américain et la quasi-totalité des frameworks de sécurité IT :
3 copies des données, sur 2 supports différents, dont 1 hors site.
Concrètement pour une boutique PrestaShop :
- Copie 1 : la production (votre serveur de prod).
- Copie 2 : sauvegarde locale ou sur le même hébergeur (rapide à restaurer pour les incidents mineurs).
- Copie 3 : sauvegarde hors site, chez un fournisseur de stockage tiers (S3, Backblaze B2, Wasabi, Dropbox).
La copie hors site est la dernière ligne de défense contre les sinistres majeurs (incendie, ransomware, faillite hébergeur).
Ce qu’il faut sauvegarder dans une boutique PrestaShop
1. La base de données complète
Toutes les tables, pas seulement les tables métier. Un dump mysqldump avec les options --single-transaction --quick --routines --triggers pour la cohérence et l’inclusion des procédures stockées et triggers.
2. Les fichiers uploadés
Le dossier /img/ (images produits, catégories, fabricants), /upload/ (fichiers attachés aux produits), /download/ (produits virtuels et leurs livrables), et tous les répertoires de modules tiers stockant des fichiers (factures PDF, exports comptables, logs).
3. Le code et les modules
Même si vous avez Git, sauvegarder le code en production permet de capturer les modifications hotfix non versionnées et l’état exact des modules installés. Inclut /modules/, /themes/, /override/, et la racine PrestaShop hors /var/cache/.
4. La configuration système
Fichiers app/config/parameters.php, .htaccess, configurations Nginx/Apache, certificats SSL, crontabs. Souvent oubliés, ils sont critiques pour rejouer une installation depuis zéro.
5. Les emails sortants et logs récents
Pour les obligations légales (RGPD, comptabilité), conserver une copie des logs récents et des emails transactionnels. Pas systématique, mais utile.
Le chiffrement n’est plus optionnel
Une sauvegarde non chiffrée stockée chez un fournisseur tiers est un risque RGPD majeur : si le prestataire est compromis, toute votre base clients fuit en clair. Article 32 du RGPD : obligation de mettre en œuvre des « mesures techniques appropriées », ce qui inclut le chiffrement au repos pour les sauvegardes contenant des données personnelles.
Le standard en 2026 : AES-256 avec une clé stockée séparément des sauvegardes. Ne jamais stocker la clé de chiffrement avec les sauvegardes — sinon le chiffrement ne sert à rien.
La rotation : combien de versions conserver
Plus on conserve, mieux c’est — mais ça coûte. Stratégie GFS (Grandfather-Father-Son) éprouvée :
- Sauvegardes quotidiennes conservées 7 jours.
- Sauvegardes hebdomadaires conservées 4 semaines.
- Sauvegardes mensuelles conservées 12 mois.
- Sauvegardes annuelles conservées 5 à 7 ans (selon les obligations comptables locales).
Avec cette stratégie, vous pouvez restaurer à n’importe quel jour des 7 derniers jours, n’importe quelle semaine du dernier mois, n’importe quel mois de la dernière année. Couvre 99 % des scénarios de récupération.
La restauration testée : la seule sauvegarde qui compte
Une sauvegarde non testée est une superstition, pas une sauvegarde. La règle absolue :
Testez la restauration sur un environnement de staging au moins une fois par trimestre.
Ce test doit vérifier :
- La sauvegarde est-elle complète (toutes les tables, tous les fichiers) ?
- Le dump est-il restaurable sans erreur ?
- Le site fonctionne-t-il après restauration (pages catégorie, panier, checkout, BO) ?
- Combien de temps prend la restauration complète (RTO : Recovery Time Objective) ?
- Quelle est la perte de données maximale (RPO : Recovery Point Objective) ?
Sur les boutiques qui font ce test trimestriel, le temps de restauration tombe de 6-8 heures à 1-2 heures en quelques itérations. Et les écarts (table manquante, permission erronée, fichier corrompu) sont détectés avant l’incident, pas pendant.
Notre module dfbackup : sauvegarde clé en main
Implémenter cette stratégie à la main demande la maintenance d’un script de dump, d’un système de chiffrement, d’une rotation et d’une montée vers du stockage S3. Notre module dfbackup pour PrestaShop 8 et 9 packagé toute la stack :
- Sauvegarde planifiée BDD + fichiers par cron, intervalle configurable (quotidien, hebdomadaire).
- Chiffrement AES-256 avec clé séparée, stockable hors du serveur.
- Destinations multiples : S3 (et compatibles : Wasabi, Backblaze B2, Scaleway), FTP/SFTP, Dropbox.
- Rotation GFS automatisée : conservation paramétrable par strate.
- Restauration 1-clic depuis le BO, avec staging optionnel.
- Notifications par email ou webhook en cas d’échec ou de succès.
- Logs détaillés de chaque sauvegarde (volume, durée, hash de vérification).
- Compatible multi-shop, multi-langue, et avec rétention différenciée selon le périmètre.
Pour 129 €, vous installez une stratégie de sauvegarde conforme RGPD et industrialisée, sans dépendre de votre hébergeur.
Combien coûte ne pas être sauvegardé
Sur une boutique générant 100 k€ de CA mensuel, un arrêt de 48 h coûte directement 6 700 € en CA non réalisé. Ajoutez les coûts indirects : reconquête clients perdus, retours négatifs sur le SAV, impact SEO si l’arrêt dure (Google peut désindexer si le site reste 404 plus de quelques jours), perte de confiance partenaires. Total réaliste : 15 à 30 k€ pour un arrêt de 48 h. Pour un mois d’arrêt, on parle de la viabilité de l’entreprise.
Le coût d’une stratégie de sauvegarde robuste : 130 € de module + 5 à 20 €/mois de stockage S3. Le ratio coût/risque est sans débat.
FAQ
Les sauvegardes incrémentielles sont-elles suffisantes ?
Pas seules. Une sauvegarde incrémentielle dépend de la sauvegarde complète précédente. Si la sauvegarde complète est corrompue, toute la chaîne incrémentielle est inutilisable. La règle : une sauvegarde complète hebdomadaire ou mensuelle, complétée par des incrémentielles quotidiennes. Pas l’inverse.
Combien de temps doit prendre une restauration ?
Le RTO acceptable dépend de la criticité. Pour une boutique e-commerce active : moins de 4 heures pour une restauration complète est l’objectif. En dessous de 2 heures avec une procédure rodée et un stockage à proximité. Au-delà de 8 heures, il y a un problème de stratégie ou d’outillage.
Faut-il sauvegarder les fichiers et la base ensemble ou séparément ?
Ensemble, idéalement dans une fenêtre temporelle resserrée (10-15 minutes). Une base et des fichiers désynchronisés (par exemple, base sauvegardée le matin, fichiers le soir) créent des incohérences à la restauration : produits dans la base qui n’ont pas d’image, factures référencées qui n’existent pas en fichier.
Le stockage cloud (S3) est-il conforme RGPD ?
Oui, si le fournisseur est dans l’UE ou propose les Clauses Contractuelles Types (CCT) pour les transferts hors UE. AWS, Scaleway, OVH Object Storage, Backblaze sont conformes avec config appropriée. Le chiffrement avant upload garantit que même un fournisseur compromis ne donne accès à rien d’utilisable.
Quelle différence avec une réplication temps réel ?
La réplication (master-slave MySQL, par exemple) protège contre une panne matérielle, pas contre les erreurs humaines ou les corruptions logiques. Si un script supprime 10 000 produits par erreur, la réplique applique la suppression instantanément. La sauvegarde versionnée garde une version saine antérieure. Les deux sont complémentaires, pas substituables.
Pour aller plus loin
La sauvegarde est un maillon d’une chaîne plus large : sécurité, monitoring, gestion des incidents. Un site bien sauvegardé mais mal monitoré perd quand même des données entre l’incident et sa détection. Voir aussi notre guide d’installation des modules PrestaShop pour comprendre où dfbackup s’insère dans la stack, et le dossier sur le nettoyage de la base PrestaShop : alléger la base avant sauvegarde divise par 5 le temps de sauvegarde et le coût de stockage.