PrestaShop : stratégie de sauvegardes + restauration sans stress (PRA)

PrestaShop : stratégie de sauvegardes + restauration sans stress (PRA)

Une boutique PrestaShop, c’est des commandes, des clients, du panier, des paiements… bref : des données critiques. Et quand un incident tombe (panne, erreur humaine, mise à jour ratée, piratage), la question n’est pas “est-ce qu’on a une sauvegarde ?” — c’est “est-ce qu’on sait restaurer, vite, proprement, et avec un minimum de perte ?”

Dans ce guide, je te propose une méthode pragmatique pour construire un vrai plan de reprise : objectifs (RPO/RTO), sauvegardes (BDD + fichiers), stockage, rétention, et surtout tests de restauration.

Si tu veux une base d’hébergement orientée production (déploiement, backups automatiques, scaling CPU/RAM), voir : Hébergement PrestaShop sur adgents.cloud.

1) Commencer par fixer RPO et RTO

Avant de parler “fréquence”, on clarifie deux objectifs :

• RPO : la perte de données maximale acceptable (ex : 15 minutes de commandes).
• RTO : le temps maximal pour remettre la boutique en ligne (ex : 1 heure).

En e-commerce, viser “24h de perte” est rarement raisonnable : ça veut dire reconstituer manuellement commandes, paiements, stocks, emails… et gérer l’impact client.

2) Ce qu’il faut sauvegarder (et ce qu’on oublie trop souvent)

Une restauration complète PrestaShop implique au minimum :

• Base de données : produits, commandes, clients, paniers, configurations, etc.
• Fichiers : thème, modules, images produits, overrides, traductions, configs spécifiques.

Côté PrestaShop, l’outil de sauvegarde BDD existe (et la doc détaille aussi les étapes de restauration via import SQL) : Sauvegarde BDD (doc PrestaShop).

Si ton infra est déjà containerisée, tu peux t’appuyer sur un déploiement propre pour rendre les sauvegardes et la restauration plus simples : Installer PrestaShop avec Docker Compose : prod + perf + backups.

3) Stratégie 3-2-1 : simple, robuste, standard

L’objectif est d’éviter le piège classique : “backup sur le même serveur”.

Concrètement :

• 3 copies (prod + 2 copies)
• sur 2 supports différents
• avec 1 copie hors site (idéalement immuable)

Sur un plan e-commerce, on met souvent la BDD plus fréquente que les fichiers (les images changent moins souvent que les commandes).

4) Fréquence et rétention : un exemple “qui marche”

Un schéma simple pour beaucoup de boutiques :

• BDD : toutes les 15 min à 1 h (selon ton RPO).
• Fichiers : quotidien (ou plusieurs fois par jour si ton catalogue bouge beaucoup).
• Rétention courte : 7 à 30 jours (restauration rapide).
• Rétention longue : 3 à 12 mois (utile contre corruption lente ou intrusion découverte tard).

Si tu veux aller plus loin côté cyber (et réduire le risque de tout perdre en cas d’attaque), complète avec les bases de durcissement : Sécuriser PrestaShop : bonnes pratiques (modules, WAF, sauvegardes).

5) Stockage : hors site + immutabilité (anti-ransomware)

Deux règles à viser :

1. Hors site : une copie sur une autre machine / autre zone / autre fournisseur.
2. Immuable : une copie non modifiable pendant la période de rétention (WORM/immutabilité, ou à défaut : versioning + comptes séparés + droits minimaux).

C’est ce qui évite le scénario “le serveur est compromis → les backups aussi”.

6) La restauration : le seul test qui compte

Une sauvegarde non testée, c’est une hypothèse. Pour sécuriser ton PRA :

• Monte une préproduction (staging) avec la même version (PHP, PrestaShop, modules).
• Planifie une restauration de test régulièrement (mensuel ou trimestriel).
• Mesure ton temps de restauration (RTO réel), pas le temps de “téléchargement du zip”.

Vidéo (FR) utile sur le principe de sauvegarde BDD : .

7) Runbook de reprise : 10 actions à garder sous la main

Quand ça arrive, tu veux un plan exécutable (pas un roman). Exemple de séquence :

1. Passer la boutique en maintenance (éviter commandes incohérentes).
2. Geler les accès (comptes admin, FTP/SSH, accès DB, clés API).
3. Identifier le point de restauration (le plus récent “sain”).
4. Restaurer la BDD sur une base vide (ou tables nettoyées).
5. Restaurer les fichiers (thème, modules, images).
6. Vérifier configuration (URL, clés, emails sortants, paiements).
7. Vider caches (PrestaShop, reverse proxy, CDN si présent).
8. Faire un parcours de commande en test.
9. Lever la maintenance.
10. Après retour : corriger la cause et renforcer (mises à jour, WAF, droits).

Si tu es dans une phase de migration (ex : 1.7 → 8), prépare ce runbook avant de toucher la prod : Migrer PrestaShop (1.7→8) : plan de migration + risques + tests.

8) Comment adgents.cloud aide (backups + rétention + scaling)

Sur adgents.cloud, l’idée est de te donner une base exploitable en production :

• Backups automatiques (24h par défaut, jusqu’à 1/h selon besoin)
• Rétention longue (jusqu’à 10 ans)
• Scaling CPU/RAM à la demande
• Stop/start pour maîtriser les coûts quand tu n’as pas besoin de compute

Tu peux ensuite compléter avec une copie hors site et/ou immuable selon ton niveau de risque.

Conclusion

Une stratégie efficace tient en 5 points :

• Fixer RPO/RTO
• Sauvegarder BDD + fichiers
• Appliquer 3-2-1 (dont hors site)
• Avoir une copie difficile à altérer
• Tester une restauration (et mesurer le RTO réel)

Pour mettre ça en place sur une base prête pour la production, commence par : Hébergement PrestaShop sur adgents.cloud.