Sauvegardes PrestaShop : ce que la plupart des hébergeurs oublient

"Mon hébergeur fait des sauvegardes." On entend cette phrase trois fois par mois. La plupart du temps, c'est faux ou très partiellement vrai. Voici ce qu'on met en place chez nos clients en infogérance — et pourquoi ça vaut le coup.

Le test qui révèle tout

Demandez à votre hébergeur de vous restaurer la boutique d'avant-hier matin 9h30 sur un staging. S'il met plus de 4h à répondre ou s'il facture cette demande "à l'étude", c'est que sa stratégie de backup a un trou.

Une sauvegarde non-testée n'est pas une sauvegarde. C'est une croyance.

La règle 3-2-1, vraiment

Trois copies, sur deux supports différents, dont une hors-site. Concrètement chez nos clients :

• Copie 1 : snapshot LVM ou ZFS local sur le serveur, toutes les 6h, rétention 7 jours
• Copie 2 : backup chiffré sur Storage Box Hetzner ou Backblaze B2, quotidien, rétention 30 jours
• Copie 3 : pour les boutiques critiques, second backup chez un autre fournisseur (OVH ou AWS S3 Glacier), hebdo, rétention 1 an

Le coût : ~10-30€/mois selon la taille. C'est négligeable comparé à 24h de boutique offline.

Le piège du mysqldump sans --single-transaction

On voit encore des scripts qui dumpent la DB pendant la journée sans cette option. Sur une boutique active, ça peut produire un dump incohérent : le SQL passe en READ LOCK sur la table, mais les transactions inter-tables peuvent diverger. À la restauration, vous découvrez que des commandes existent sans leurs order_detail.

La commande qu'on utilise toujours pour MariaDB :

mariadb-dump \
    --single-transaction \
    --quick \
    --triggers \
    --routines \
    --events \
    --default-character-set=utf8mb4 \
    --hex-blob \
    -u backup_user -p"$BACKUP_PASS" \
    appnova_db | gzip > backup.sql.gz

Le --single-transaction garantit la cohérence, le --quick évite de tout charger en mémoire, et --hex-blob sauve les BLOB binaires (utile pour PrestaShop qui stocke parfois des serializations).

Point-in-time recovery (PITR)

Pour les boutiques qui font 100+ commandes/jour, le backup quotidien ne suffit pas. Si une corruption survient à 16h et que le dernier backup date de 3h, vous perdez 13h de commandes.

La solution : activer les binary logs MariaDB (log-bin=mysql-bin) avec rétention 7 jours, et les pousser hors-site toutes les 15 minutes. En cas de pépin, on peut rejouer les logs depuis le dernier backup full jusqu'à la seconde qui précède l'incident.

C'est le même mécanisme que les serveurs MySQL bancaires, version "auto-hébergée".

Tester la restauration : tous les mois

Sans test régulier, on ne sait pas si :

• Le backup est bien chiffré (et la clé toujours valide)
• La taille du backup est cohérente (pas un fichier vide)
• La structure de la DB n'a pas dérivé (nouvelles tables d'un module)
• Les permissions des fichiers sont préservées

Notre pratique : un cron mensuel qui prend un backup aléatoire des 30 derniers jours, le restaure dans un Docker éphémère, et fait passer les tests fumigatoires (homepage, ajout panier, BO accessible). Si quelque chose échoue, on est alerté.

Ce qu'on ne sauvegarde pas (à tort)

Beaucoup de scripts oublient :

• Les fichiers uploadés dans /img/p/ (images produits) — peuvent peser plus que la DB
• Les configurations Apache/OLS/Nginx — refaire les vhosts à la main = 4h perdues
• Les fichiers .htaccess customisés avec règles de redirection SEO
• Les certificats SSL Let's Encrypt
• Les tokens d'API Stripe / Mollie / autres stockés en .env

Notre script de backup full chez les clients couvre tout ça. L'infogérance AppNova inclut systématiquement cette couche.

RTO et RPO : les deux chiffres à connaître

• RPO (Recovery Point Objective) : combien de données vous acceptez de perdre. Sans PITR : 24h. Avec PITR : 15 min.
• RTO (Recovery Time Objective) : combien de temps vous tolérez d'être offline. Sans plan : variable. Avec plan testé : 1-2h.

Si vous ne pouvez pas répondre à ces deux questions sur votre boutique aujourd'hui, c'est que votre stratégie n'en est pas une. Parlons-en.