Un site Web fonctionne chaque jour, jusqu'à ce qu'il ne le fasse soudainement plus. Une mise à jour défectueuse, une base de données corrompue, un plugin WordPress compromis, une erreur humaine ou une panne technique peuvent suffire à paralyser partiellement ou totalement un site Web.
En ce moment, ce n'est plus la présence d'une sauvegarde quelque part qui décide. Ce qui est décisif, si le site Web peut effectivement en être restauré dans un délai raisonnable.
C'est précisément là que réside la différence entre une simple sauvegarde de données et une stratégie de sauvegarde et de reprise après sinistre bien pensée.
Que signifie la reprise après sinistre pour un site web ?
Le terme reprise après sinistre désigne l'ensemble des mesures permettant de rétablir le bon fonctionnement des systèmes et des données à la suite d'une panne majeure.
Sur un site Web, un tel incident peut par exemple résulter de :
- Pannes matérielles ou de stockage
- mises à jour WordPress ou de plugins défectueuses
- bases de données endommagées
- Logiciels malveillants ou sites Web compromis
- fichiers supprimés par erreur
- Erreurs de configuration
- Problèmes chez l'hébergeur
Une sauvegarde constitue à cet effet un élément important, mais ne représente pas encore une stratégie complète de reprise après sinistre.
La sauvegarde et la reprise après sinistre ne sont pas la même chose
Une sauvegarde répond d'abord uniquement à la question : Existe-t-il une copie de mes données ?
La reprise après sinistre va encore plus loin : Comment puis-je redonner à cette copie un système fonctionnel ?
Pour un site web WordPress, il ne suffit pas, par exemple, de sauvegarder uniquement les images téléchargées. Pour une restauration complète, les fichiers WordPress et la base de données sont notamment nécessaires.
À cela s'ajoutent, selon l'environnement, des configurations, des paramètres DNS, des certificats SSL ou d'autres composants.
C'est pourquoi la question la plus importante n'est pas : „ Avons-nous des sauvegardes ? “
Mais plutôt : „Pouvons-nous restaurer notre site Web de manière fiable à partir de ces sauvegardes ?“
Pourquoi une sauvegarde sur le même système peut être problématique
Un dispositif de sécurité n'offre une protection que s'il est suffisamment indépendant du système d'origine.
Si la seule sauvegarde se trouve par exemple sur le même serveur que le site web de production, une panne grave peut affecter les deux en même temps.
Il en va de même pour les systèmes compromis : si un attaquant obtient un accès étendu, les sauvegardes stockées localement peuvent également être touchées dans des circonstances défavorables.
Une stratégie de sauvegarde bien pensée tient donc compte de la séparation entre le système de production et la sauvegarde.
La règle 3-2-1 comme orientation
Une règle de base bien connue pour les sauvegardes est la dite Règle de sauvegarde 3-2-1.
En termes simples, elle signifie :
- 3 copies des données importantes
- sur 2 supports de stockage ou systèmes différents
- dont au moins 1 copie séparée du site principal
Toutes les petites entreprises n'ont pas nécessairement besoin d'une infrastructure de sauvegarde d'entreprise complexe.
Cependant, le principe fondamental reste judicieux : La sauvegarde ne doit pas pouvoir être touchée par la même erreur que l'original.
À quelle fréquence un site Web devrait-il être sauvegardé ?
La bonne fréquence de sauvegarde dépend de la fréquence à laquelle les données d'un site Web changent.
Pour un site associatif ou d'information largement statique, une stratégie différente peut s'avérer judicieuse par rapport à une boutique WooCommerce à forte fréquentation.
Par exemple, une boutique en ligne modifie continuellement :
- Commandes
- Comptes clients
- Niveaux des stocks
- Informations de paiement et données de statut
Plus il y a de données créées entre deux sauvegardes, plus la perte potentielle lors d'une restauration peut être importante.
RPO et RTO : Deux notions qui décrivent le risque réel
Les concepts de sauvegarde professionnels utilisent souvent deux indicateurs clés : RPO et RTO.
RPO – Objectif de point de récupération
En termes simples, le RPO décrit la quantité de pertes de données qui serait acceptable dans le pire des cas.
Si les sauvegardes sont effectuées par exemple une fois par jour, les modifications apportées depuis la dernière sauvegarde peuvent théoriquement être perdues.
Pour un site web simple, cela peut être acceptable. Pour une boutique en ligne active, peut-être pas.
RTO – Objectif de temps de récupération
Le RTO décrit la durée maximale pendant laquelle un système peut être en panne avant d'être rétabli.
Ici aussi, les exigences diffèrent considérablement.
Un site web privé peut éventuellement être hors ligne pendant quelques heures ou plus. Pour une boutique en ligne critique pour l'activité, même une courte période d'indisponibilité peut coûter du chiffre d'affaires.
Pourquoi plusieurs versions de sauvegarde sont importantes
Une seule sauvegarde récente ne suffit pas toujours.
Le problème : Une erreur ou une compromission peut déjà passer inaperçue depuis plusieurs jours.
Si une seule et unique sauvegarde est écrasée chaque jour, la sauvegarde peut elle aussi finir par contenir l'état erroné ou compromis.
Les sauvegardes versionnées permettent en revanche de revenir à un état antérieur.
C'est pourquoi plusieurs points de restauration constituent un élément important d'une bonne stratégie de sauvegarde.
Une sauvegarde n'est bonne que si la restauration fonctionne
L'une des erreurs les plus fréquentes consiste à automatiser la création de sauvegardes sans jamais vérifier si elles peuvent réellement être utilisées.
Un message de sauvegarde réussi ne signifie pas automatiquement qu'il permettra de restaurer l'intégralité d'un site web sans erreur.
C'est pourquoi les systèmes de sauvegarde et les processus de restauration doivent être vérifiés régulièrement.
Vous trouverez d'autres bases à ce sujet dans notre guide : Stratégies de sauvegarde : ce qui importe vraiment .
WordPress a des exigences particulières en matière de sauvegardes
WordPress ne se compose pas seulement de fichiers. Une grande partie du site web se trouve dans la base de données.
On y trouve par exemple :
- Articles et pages
- Comptes d'utilisateurs
- Paramètres WordPress
- Configurations de plugins
- Données WooCommerce
Une sauvegarde WordPress complète doit par conséquent inclure les fichiers et la base de données.
Un point de restauration récent est particulièrement important, surtout avant des mises à jour majeures ou des modifications.
Que se passe-t-il lorsqu'un site WordPress est piraté ?
Lors d'un incident de sécurité, la récupération est plus complexe qu'après la suppression accidentelle d'un fichier.
Le simple fait de restaurer la dernière sauvegarde peut s'avérer problématique si celle-ci contient déjà du code malveillant ou si la vulnérabilité d'origine persiste.
Il faut donc d'abord clarifier :
- Comment le site Web a-t-il été compromis ?
- Depuis quand l'attaque a-t-elle lieu ?
- Quel point de restauration est encore propre ?
- La vulnérabilité initiale a-t-elle été corrigée ?
Nous expliquons cela plus en détail dans l'article : WordPress piraté – que faire ? .
Sauvegarde d'hébergement et sauvegarde de site web supplémentaire
Une sauvegarde d'hébergement et une sauvegarde de site web supplémentaire et distincte ne remplissent pas nécessairement la même fonction.
La sauvegarde d'hébergement sert typiquement à la restauration au sein de l'environnement d'hébergement existant.
Une solution de sauvegarde supplémentaire peut, en revanche, créer un niveau de sauvegarde indépendant supplémentaire.
Qu'une telle protection supplémentaire soit nécessaire dépend de la valeur et de la criticité du site Web.
CodeGuard comme niveau de sauvegarde supplémentaire
Pour les sites Web pour lesquels une sauvegarde supplémentaire et distincte de l'hébergement web proprement dit est souhaitée, une solution de sauvegarde externe peut s'avérer judicieuse.
CURIAWEB propose entre autres pour cela CodeGuard un.
CodeGuard peut sauvegarder régulièrement des sites Web indépendamment de l'hébergement proprement dit et surveiller les modifications. Cela crée un niveau de sauvegarde supplémentaire qui ne dépend pas exclusivement de l'infrastructure de sauvegarde de l'hébergement web.
C'est par exemple intéressant si un site web est hébergé chez un autre fournisseur ou si une sauvegarde supplémentaire est souhaitée pour un site web particulièrement important.
Plus d'informations : Sauvegarde de site Web CodeGuard .
Quel est le rapport entre la protection des données et les sauvegardes ?
Les sauvegardes peuvent contenir des données à caractère personnel. C'est pourquoi elles doivent être prises en compte dans un concept de protection des données au même titre que les systèmes de production.
Sont pertinents, entre autres :
- Protection contre l'accès non autorisé
- Durée de conservation
- Emplacement
- Protection contre les accès non autorisés
- Processus de suppression et de restauration
Une sauvegarde n'est donc pas automatiquement une mesure de protection des données complète. Elle fait partie d'un concept de sécurité technique et organisationnel plus global.
Que se passe-t-il si l'ensemble du fournisseur d'hébergement tombe en panne ?
Cette question fait également partie d'une analyse réaliste des risques.
Quiconque dépend entièrement d'un seul fournisseur, d'un seul accès et d'une seule infrastructure de sauvegarde devrait au moins savoir comment accéder à ses propres données en cas d'urgence.
Pour les sites web critiques pour l'activité, une sauvegarde supplémentaire indépendante de l'hébergement peut donc s'avérer judicieuse.
Dans des cas extrêmes, cela permet également de restaurer un site web dans un autre environnement d'hébergement.
Un changement d'hébergement peut faire partie de la stratégie d'urgence
Si des problèmes permanents de performance, de stabilité, de sécurité ou de support se manifestent, il ne faut pas attendre une panne totale.
Un changement d'hébergement planifié est nettement plus simple qu'une migration sous pression temporelle en cas d'urgence.
CURIAWEB prend en charge gratuitement la migration des sites web existants pour les nouveaux clients lors d'un changement.
En savoir plus : Changement d'hébergement avec service de migration gratuit .
Quelle stratégie de sauvegarde est la bonne ?
Il n'y a pas de stratégie de sauvegarde qui doive être identique pour chaque site web.
Une solution judicieuse s'oriente vers le risque réel.
Les questions suivantes devraient notamment y être abordées :
- Quelle est l'importance du site Web pour moi ou mon organisation ?
- À quelle fréquence les données changent-elles ?
- Quelle quantité de perte de données serait acceptable ?
- Combien de temps le site web est-il autorisé à être en panne ?
- De combien de points de restauration plus anciens ai-je besoin ?
- Où se trouvent les sauvegardes ?
- Le site web peut-il également être restauré sur une autre infrastructure ?
- La restauration a-t-elle déjà été testée ?
Une petite page Web personnelle, un site de club, un site d'entreprise et une boutique WooCommerce peuvent ainsi avoir des exigences totalement différentes.
Conclusion : ce n'est pas la sauvegarde qui compte, mais la restaurabilité
Les sauvegardes font partie des fondements les plus importants pour un fonctionnement fiable d'un site web.
La question décisive n'est cependant pas de savoir si une sauvegarde existe quelque part.
Ce qui est décisif, c'est, si les bonnes données sont sauvegardées, si les sauvegardes sont récentes et s'il est possible de restaurer un site web fonctionnel à partir de celles-ci en cas d'urgence.
Une bonne stratégie de reprise après sinistre ne prend donc pas seulement en compte les sauvegardes, mais aussi les temps de restauration, le versionnage, l'indépendance par rapport au système de production et des tests réguliers.
Plus un site web est important, moins sa restauration devrait être laissée au hasard.
