Sauvegarde et plan de reprise d'activité pour votre boutique PrestaShop
Une sauvegarde qui n'a jamais été testée n'est pas une sauvegarde, c'est un espoir. Voici comment construire une stratégie réaliste, avec des objectifs de perte de données et de délai de remise en ligne adaptés à un site e-commerce — pas à un site vitrine.
RTO, RPO : deux notions à définir avant tout
Sans ces deux repères, impossible de savoir si votre stratégie de sauvegarde actuelle est suffisante ou dangereusement optimiste.
RPO (Recovery Point Objective)
La quantité de données que vous acceptez de perdre. Un RPO de 15 minutes veut dire qu'en cas d'incident, au maximum 15 minutes de commandes sont perdues.
RTO (Recovery Time Objective)
Le délai maximal acceptable pour remettre le site en ligne après un incident. Chaque heure d'indisponibilité a un coût direct en chiffre d'affaires perdu.
| Élément | RTO cible | RPO cible |
|---|---|---|
| Site web (front) | 1 à 2 heures | 15 à 30 minutes |
| Base de données (commandes, clients) | 30 minutes | 15 minutes |
| Messagerie transactionnelle | 4 heures | 1 à 4 heures |
| ERP / gestion connectée | 2 à 4 heures | 30 minutes |
La règle 3-2-1
Le principe de base d'une sauvegarde qui résiste à peu près à tout, y compris à une compromission du serveur principal.
copies des données
L'originale sur le serveur de production, plus deux copies de sauvegarde indépendantes.
supports différents
Pas deux copies sur le même type de stockage, pour éviter une panne matérielle qui toucherait les deux à la fois.
copie hors site
Externalisée, idéalement chez un prestataire distinct, pour survivre à un piratage ou un sinistre touchant le serveur principal.
Fréquence de sauvegarde par type de donnée
| Donnée | Fréquence recommandée |
|---|---|
| Base de données (commandes, clients, catalogue) | Toutes les 15 minutes à 1 heure, selon le RPO visé |
| Fichiers (thème, modules, images, code) | Quotidienne, au minimum |
| Copie immuable (anti-ransomware) | Au moins une copie non modifiable pendant la durée de rétention |
Le runbook à suivre en cas d'incident
Passer le site en mode maintenance
Éviter que de nouvelles commandes ne se perdent pendant l'intervention.
Identifier le dernier point de restauration sain
Une sauvegarde compromise elle aussi (cas d'un piratage) doit être écartée, pas restaurée par réflexe.
Restaurer base de données puis fichiers
Dans cet ordre, en vérifiant la cohérence entre les deux avant de rouvrir l'accès public.
Vider les caches et vérifier les configurations
Cache Smarty, cache de page, configuration des modules de paiement en priorité.
Passer une commande test de bout en bout
Avant de rouvrir officiellement le site, valider que le tunnel de commande fonctionne réellement.
Si l'incident est un piratage plutôt qu'une panne, la procédure se combine avec les 72 premières heures détaillées dans notre guide boutique piratée : que faire.