Une sauvegarde donne l’impression d’être protégé. Pourtant, un fichier incomplet, un mot de passe oublié ou une archive stockée au même endroit que le site peut rendre la récupération impossible. La vraie question n’est donc pas seulement « avons-nous une sauvegarde ? », mais « pouvons-nous restaurer le service dans un délai acceptable ? ».
Lister ce qu’il faut réellement sauvegarder
Pour WordPress comme pour PrestaShop, les fichiers applicatifs et la base de données constituent un ensemble. Ajoutez les médias, fichiers déposés par les clients, paramètres spécifiques, secrets gérés dans des emplacements appropriés et éventuels stockage externes. Une base restaurée avec des fichiers d’une autre date peut provoquer des incohérences, particulièrement pour les commandes et les comptes clients.
Définir fréquence et perte maximale acceptable
Une boutique recevant des commandes toute la journée n’a pas les mêmes besoins qu’un site institutionnel modifié une fois par mois. Définissez la quantité de données qu’il serait acceptable de perdre et le temps maximal de remise en service. Ces deux exigences guident la fréquence des sauvegardes et les moyens à prévoir. Une sauvegarde quotidienne n’est pas automatiquement suffisante pour une activité transactionnelle intense.
Conserver des copies indépendantes
Prévoyez des copies sur un support ou un service distinct de l’hébergement de production, avec des droits d’accès limités. Une compromission du serveur peut affecter les sauvegardes locales accessibles au même compte. Selon les risques, un stockage immuable ou déconnecté peut être pertinent. Chiffrez les données sensibles et conservez les moyens de déchiffrement dans un emplacement sûr.
Effectuer des restaurations de test
Restaurez régulièrement sur un environnement privé et isolé. Vérifiez l’ouverture du site, les connexions, la cohérence des médias et les processus métiers. Sur une boutique, contrôlez produits, déclinaisons, commandes et états de paiement. Si un fichier critique manque, mettez à jour la procédure au lieu de considérer le test comme un simple échec ponctuel.
Documenter la procédure de crise
Une restauration dépend souvent de l’accès à l’hébergeur, à la base, aux archives et au DNS. Écrivez les étapes, responsables et coordonnées nécessaires. Prévoyez le cas où la personne habituelle est indisponible. Dans une situation d’incident de sécurité, validez que la sauvegarde choisie n’est pas déjà contaminée avant de rouvrir le site.
Simuler une panne sans toucher à la production
Créez une copie de test, déclarez-la indisponible puis restaurez depuis la dernière archive vérifiée. Mesurez le délai et notez les opérations manuelles. Les difficultés découvertes en exercice coûtent généralement moins cher que celles rencontrées durant une vraie coupure. La sauvegarde devient un dispositif de continuité, et non une simple case cochée.
Questions fréquentes
Une sauvegarde sur le même serveur suffit-elle ?
Non pour couvrir les incidents affectant tout le compte ou le serveur. Une copie indépendante, sécurisée et récupérable est importante.
À quelle fréquence tester la restauration ?
Selon la criticité et les changements du site. Un test régulier est indispensable, notamment après une évolution de l’hébergement ou de la structure des données.
Ressources pour continuer
- Site WordPress piraté : les premières actions pour limiter les dégâts
- Mettre à jour WordPress sans interrompre son site : une procédure fiable
- Sécuriser WordPress : les contrôles prioritaires
Pour un besoin spécifique, une vérification de compatibilité ou une évolution sur mesure, découvrez les prestations Concepty ou contactez Concepty.