Sauvegarde et restauration WordPress : guide complet destiné aux agences chargées de la gestion des sites de leurs clients
Si un site WordPress est actuellement hors service, la priorité n'est pas de « faire une sauvegarde ». Il s'agit plutôt de trouver la sauvegarde la plus récente, intacte, complète et restaurable, puis de restaurer le site de la manière la plus sûre possible. Une sauvegarde WordPress exploitable nécessite généralement à la fois la base de données et les fichiers du site. Si l'un de ces éléments manque, la restauration risque d'échouer ou d'être incomplète.
La plupart des guides consacrés à la sauvegarde et à la restauration de WordPress se concentrent sur l'étape de la sauvegarde. La restauration est souvent considérée comme une simple étape à effectuer plus tard. C'est généralement là que les problèmes commencent.
Une sauvegarde peut exister tout en s'avérant inefficace. Il peut manquer la base de données ou les fichiers téléchargés. Elle peut être trop ancienne ou ne pas correspondre du tout à ce que vous recherchez. Dans le cas d'un site piraté, elle peut contenir les données compromises que vous essayez justement d'éliminer. Les recommandations de Google conseillent aux propriétaires de sites de procéder à une restauration à partir d'une sauvegarde « propre » après une intrusion.
C'est pourquoi la sauvegarde et la restauration de WordPress ne se résument pas à une simple configuration. Dès lors que vous gérez les sites de vos clients, cela devient un processus à part entière. Vous devez savoir quels éléments sont sauvegardés, à quelle fréquence la sauvegarde s'effectue, où sont stockées les copies, qui est autorisé à restaurer l'environnement de production, et comment vous vérifiez que le site fonctionne correctement après la restauration.
Ce guide aborde les aspects pratiques de la sauvegarde et de la restauration sous WordPress. Il examine ce que comprend une sauvegarde complète, comment restaurer un site WordPress à partir d'une sauvegarde sans aggraver la situation, les limites des méthodes de sauvegarde courantes, et ce que les agences devraient standardiser pour l'ensemble de leur portefeuille de clients.
Ce que comprennent la sauvegarde et la restauration WordPress
Une sauvegarde complète de WordPress comprend deux éléments : la base de données et les fichiers. Ces deux éléments sont indispensables pour restaurer intégralement un site WordPress standard.
Ce que contient une sauvegarde de la base de données WordPress
La base de données contient tous les éléments dynamiques du site : articles, pages, commentaires, utilisateurs, paramètres et de nombreuses données de plugins. Si la base de données est endommagée ou manquante, le site peut se charger partiellement, afficher d'anciens contenus ou ne pas s'afficher du tout. WordPress précise que la base de données contient tous les articles, commentaires et liens, et recommande de la sauvegarder régulièrement, et toujours avant une mise à jour.
À lire également : Comment sauvegarder la base de données WordPress
Ce que contient une sauvegarde de fichiers WordPress
La partie « fichiers » comprend les fichiers du cœur de WordPress, les thèmes, les plugins, les fichiers téléchargés, le fichier wp-config.php et d'autres fichiers côté serveur liés au fonctionnement du site. WordPress distingue ces éléments de la base de données, car la sauvegarde de l'un n'entraîne pas automatiquement la sauvegarde de l'autre.
Cette distinction est essentielle, car la « sauvegarde et la restauration d'un site WordPress » sont souvent considérées comme une seule et même opération. Ce n'est pas le cas. Il s'agit en réalité de deux étapes distinctes qui doivent s'enchaîner correctement.
Comment restaurer un site WordPress à partir d'une sauvegarde
Lorsqu'une restauration est urgente, on a tendance à se précipiter sur la première sauvegarde venue. C'est compréhensible. C'est aussi ainsi que les situations difficiles s'aggravent.
Pour garantir un processus de restauration plus sûr, il faut commencer par se poser une question : de quoi essayez-vous de vous remettre ?
Si le site ne fonctionne plus après une mise à jour, une restauration complète n'est peut-être pas nécessaire. De plus, si le problème se limite à un plugin ou à un thème, une restauration à une version antérieure ou une restauration ciblée de fichiers peut suffire.
Choisissez le bon point de restauration
La dernière sauvegarde semble intéressante car elle semble correspondre le mieux à l'état actuel. Ce raisonnement ne tient pas si le problème est apparu sur le site avant la création de la sauvegarde. Les logiciels malveillants, les injections de spam, les données corrompues et les modifications de code erronées ne se manifestent pas toujours immédiatement.
Une meilleure approche consiste à remonter dans le temps à partir du dernier état connu où tout fonctionnait correctement. À quel moment le site fonctionnait-il encore sans aucun doute ? Qu'est-ce qui a changé par la suite ? Le problème a-t-il été causé par le contenu, le code, l'infrastructure ou une attaque ? Sans ces réponses, la restauration n'est qu'une question de conjecture.
Vérifiez si vous avez besoin de fichiers, d'une base de données ou des deux
Certaines restaurations sont plus lourdes qu'elles ne devraient l'être. Si la mise à jour d'un plugin a endommagé l'interface utilisateur mais que la base de données est intacte, une restauration complète peut entraîner une perte de données qui aurait pu être évitée. Si la base de données est corrompue, le simple fait de restaurer les fichiers ne résoudra pas le problème. C'est précisément pour cette raison que la documentation WordPress traite la base de données et les fichiers comme des éléments de sauvegarde distincts.
Vérifiez correctement le bon fonctionnement du site restauré
Le simple chargement de la page d'accueil ne suffit pas. Après une restauration, les vérifications approfondies portent généralement sur les formulaires, le processus de paiement, la connexion, les rôles des utilisateurs, les tâches planifiées, les images, le contenu récent et les fonctionnalités spécifiques aux extensions. Les boutiques en ligne et les sites d'adhésion nécessitent une attention encore plus particulière, car une restauration techniquement « réussie » peut tout de même laisser des lacunes au niveau des commandes, des abonnements ou de l'activité des clients.
Méthodes de sauvegarde WordPress : plugin, hébergeur et manuellement
La plupart des configurations de sauvegarde et de restauration sous WordPress se répartissent en trois catégories. Toutes peuvent fonctionner, mais aucune n'est infaillible.
Plugins de sauvegarde WordPress
Les plugins de sauvegarde et de restauration WordPress constituent le choix par défaut pour de nombreux propriétaires de sites, car ils sont faciles à configurer et permettent d'automatiser la tâche. Cette facilité d'utilisation est essentielle, car si un système de sauvegarde est trop compliqué à gérer, on a tendance à l'oublier.
Cela dit, les sauvegardes effectuées à l'aide de plugins ne sont pas forcément fiables. Elles s'exécutent au sein d'un environnement plus large qui peut déjà être soumis à des contraintes. Sur les sites plus personnalisés, les plugins de sauvegarde peuvent également avoir du mal à tout sauvegarder correctement. Pour un site unique, un plugin peut suffire. Pour une agence, la véritable question n'est pas de savoir si un plugin permet de créer des sauvegardes, mais si le processus de restauration est cohérent à l'échelle de l'ensemble du portefeuille.
Comment WP Umbrella le processus de sauvegarde et de restauration
Pour une agence, la question est généralement de savoir si l'équipe est capable d'effectuer des sauvegardes, des restaurations, des vérifications et de communiquer avec les clients de la même manière sur des dizaines de sites. C'est là que WP Umbrella plus adapté qu'un plugin classique.
WP Umbrella une plateforme centralisée destinée aux agences qui gèrent plusieurs sites WordPress. Ses fonctionnalités de sauvegarde et de restauration comprennent des sauvegardes automatisées, un stockage crypté, une restauration en un clic, un téléchargement en un clic, des fréquences de sauvegarde configurables, des sauvegardes toutes les heures (en option) et une durée de conservation de 50 jours sur l'infrastructure européenne WP Umbrella.
Cela modifie la donne en matière de sauvegarde à deux égards.
Tout d'abord, cela réduit la fragmentation. Les agences n'ont plus besoin de recourir à une solution de sauvegarde différente pour chaque serveur ou chaque site. Ensuite, cela intègre la sauvegarde et la restauration dans un système opérationnel plus global. Cette même plateforme offre également un accès centralisé au tableau de bord, la surveillance de la disponibilité et des performances, l'analyse de la sécurité et des vulnérabilités, la gestion des autorisations pour les équipes, les journaux d'activité, les alertes et les rapports de maintenance destinés aux clients.
L'intérêt ne réside pas simplement dans le fait qu'une sauvegarde existe. L'intérêt réside dans le fait que l'agence dispose d'une méthode plus cohérente pour protéger les sites, les restaurer et en apporter la preuve aux clients.
Sauvegardes WordPress au niveau de l'hébergement
De nombreux hébergeurs proposent des sauvegardes automatiques et des points de restauration. C'est très utile et, dans bien des cas, c'est le moyen le plus rapide de rétablir un site en cas de panne. WordPress indique d'ailleurs que la plupart des hébergeurs sauvegardent l'intégralité du serveur ; toutefois, demander une copie à partir des sauvegardes de l'hébergeur peut prendre du temps, et les agences doivent tout de même savoir comment sauvegarder et restaurer leurs propres sites.
Les sauvegardes au niveau de l'hébergeur varient également considérablement. Certaines sont flexibles, d'autres non. Le problème ne réside pas tant dans la qualité que dans la fragmentation. Les agences hébergent rarement tous leurs clients chez le même fournisseur. Un processus de restauration au niveau de l'hébergeur peut fonctionner parfaitement pour un compte, mais être complètement différent pour un autre. Cela entraîne des divergences opérationnelles.
La contrainte cachée : la fiabilité des sauvegardes sur les hébergements à bas prix
L'un des problèmes liés aux sauvegardes WordPress basées sur des plugins est qu'elles s'exécutent souvent au sein du même environnement limité qu'elles sont censées protéger. Sur les hébergements mutualisés à bas prix, les tâches de sauvegarde peuvent se heurter à des limites strictes en matière de CPU, de mémoire, d'E/S disque et de processus actifs. GoDaddy, Bluehost et SiteGround mentionnent tous des limites de ressources de ce type, et WordPress souligne que les erreurs de délai d'attente sont particulièrement fréquentes sur les hébergements mutualisés lorsque le serveur ne parvient pas à gérer la charge de travail.
Cela ne signifie pas pour autant que les plugins de sauvegarde sont inutiles. Cela signifie simplement que les agences doivent être réalistes quant aux points sur lesquels elles risquent le plus d'échouer. Le stockage hors site permet d'éviter de saturer l'espace disque local, mais il ne supprime pas pour autant le coût en ressources lié à la création de la sauvegarde elle-même. Sur un hébergement aux ressources limitées, une configuration plus fiable peut consister à combiner des sauvegardes au niveau de l'hébergeur, des sauvegardes de bases de données plus légères et des archives complètes moins fréquentes. Sur des plateformes gérées plus robustes, l'infrastructure de sauvegarde est souvent gérée au niveau de l'hébergement. Kinsta, par exemple, inclut des sauvegardes quotidiennes automatiques et propose des options supplémentaires de sauvegarde toutes les heures.
Sauvegarde et restauration manuelles de WordPress
La sauvegarde et la restauration manuelles d'un site WordPress impliquent souvent de copier les fichiers du site via SFTP ou un gestionnaire de fichiers, et d'exporter la base de données via phpMyAdmin ou un outil équivalent. Cette méthode reste d'actualité, car elle offre une solution de secours lorsque les plugins ou les outils du tableau de bord ne sont pas disponibles.
Les méthodes manuelles offrent certes un certain contrôle, mais elles sont aussi plus susceptibles d'entraîner des erreurs. Par exemple, les fichiers et les bases de données peuvent finir par ne plus être synchronisés, ou bien une personne peut disposer des sauvegardes mais pas des identifiants. Ce processus est tout simplement fastidieux, ce qui revient à dire qu'il cède sous la pression.
À lire également : Comment sauvegarder un site WordPress sans plugin
À quelle fréquence faut-il sauvegarder un site WordPress ?
Il n'y a pas de réponse universelle à cette question. WordPress indique que la fréquence des sauvegardes dépend de la fréquence des modifications apportées au site et de l'impact que la perte de ces données récentes aurait pour vous. En règle générale, il recommande des sauvegardes hebdomadaires pour les petits sites et des sauvegardes quotidiennes pour les sites très actifs. Il s'agit là d'un bon point de départ, mais pas d'une règle absolue.
Un site de présentation mis à jour deux fois par mois n'a pas besoin d'une fréquence de sauvegarde identique à celle d'une boutique WooCommerce, d'un site d'abonnement, d'une plateforme d'apprentissage ou d'un site de réservation. La meilleure façon de déterminer la fréquence des sauvegardes consiste à se poser une seule question : quelle quantité de données récentes ce client peut-il se permettre de perdre ?
Cette réponse est généralement plus claire que n'importe quelle « bonne pratique » générique.
Bonnes pratiques en matière de sauvegarde WordPress pour les agences
Harmoniser la responsabilité des sauvegardes
Il faut que quelqu'un soit responsable de répondre aux questions fondamentales. Le système de sauvegarde principal repose-t-il sur des plugins, sur l'hébergeur ou est-il centralisé ailleurs ? Existe-t-il une copie secondaire ? Qui est habilité à restaurer l'environnement de production ? Qui donne son accord pour une restauration si le site contient des commandes ou des données d'utilisateurs ? Si ces réponses dépendent du membre de l'équipe qui se trouve justement en ligne, le processus est fragile.
Adapter la fréquence des sauvegardes au type de site
Cela doit être mis en relation avec les risques opérationnels. Les boutiques en ligne, les éditeurs, les forums et les sites de réservation ont généralement besoin de points de restauration plus fréquents que les sites marketing où les modifications sont peu nombreuses. Les traiter de la même manière est rarement le bon choix sur le plan opérationnel.
Conservez des copies à plusieurs endroits
WordPress recommande de conserver au moins trois à cinq sauvegardes récentes à différents emplacements afin qu'une copie perdue ou endommagée ne vous laisse pas dans l'impasse. Ce conseil reste d'actualité. Une seule copie sur l'environnement de production ne constitue pas vraiment un filet de sécurité. Un point de restauration au niveau de l'hébergeur, c'est mieux que rien, mais cela reste une solution peu fiable.
Testez les restaurations, pas seulement les sauvegardes
C'est sans doute la principale lacune dans les processus opérationnels réels des agences. La réussite de la sauvegarde est considérée comme la preuve que la restauration a bien fonctionné. Or, ce n'est pas le cas. Il n'est pas nécessaire de procéder à un test de restauration chaque semaine sur tous les sites, mais si aucune restauration n'est jamais testée, la politique de sauvegarde repose sur la confiance plutôt que sur des preuves.
Noter le chemin de restauration
C'est un travail fastidieux, mais c'est justement pour cela qu'il est important. Où sont stockées les copies de sauvegarde ? Quels identifiants sont nécessaires ? Quel est l'ordre de restauration ? Que faut-il vérifier après la restauration ? Que faut-il communiquer au client ? Répondez à ces questions pour établir une procédure opérationnelle standard (SOP) complète qui permettra de limiter l'improvisation en cas de panne de votre site.
Conclusion
La plupart des articles sur la sauvegarde de WordPress s'arrêtent trop tôt. Ils vous expliquent comment créer une sauvegarde et partent du principe que le plus dur est fait. Or, ce n'est généralement pas le cas.
Le plus difficile, c'est la « préparation à la restauration ». C'est là que de nombreuses configurations de sauvegarde échouent. C'est également là que WP Umbrella nettement d'un plugin générique. Ce produit ne se contente pas de générer des sauvegardes. Il offre aux agences un moyen plus cohérent et plus fiable de protéger, restaurer et gérer les sites de leurs clients à grande échelle.
Découvrez ensuite les différents types de sauvegardes.
Foire aux questions sur la sauvegarde et la restauration de WordPress
Une sauvegarde complète de WordPress comprend à la fois la base de données et les fichiers du site. Ces deux éléments distincts du site sont indispensables pour effectuer une restauration complète classique.
Une procédure de restauration WordPress efficace commence par le choix du bon point de restauration, en déterminant si vous avez besoin des fichiers, de la base de données ou des deux, en effectuant la restauration dans le bon ordre, puis en vérifiant le bon fonctionnement du site au-delà de la page d'accueil. La documentation WordPress recommande de restaurer d'abord les fichiers, puis d'importer la base de données.
Pas automatiquement. Assurez-vous que la sauvegarde est intacte et ne contient pas de contenu piraté avant de la restaurer.
Ils peuvent s'avérer utiles, mais ils entraînent souvent une fragmentation des processus, car chaque hébergeur gère différemment l'accès aux sauvegardes, les restaurations et la conservation des données. La rapidité de la restauration des sites dépend toujours de votre maîtrise de vos propres processus de sauvegarde et de restauration.
Les fonctionnalités de sauvegarde et de restauration WP Umbrellasont conçues pour les agences qui gèrent plusieurs sites. Elles comprennent des sauvegardes automatisées, un stockage chiffré, une restauration en un clic, un téléchargement en un clic, des fréquences de sauvegarde configurables, des sauvegardes horaires en option, une durée de conservation de 50 jours et une infrastructure basée dans l'Union européenne, le tout intégré dans un flux de travail centralisé plus large comprenant des autorisations, des journaux, des alertes et des rapports.