Les incidents qui se sont produits en 2017 chez OVH ont été une bonne occasion de rappeler que vous ne devez pas compter aveuglement sur votre hébergeur pour assurer la sécurité de votre site Web.
Je vous propose de découvrir quelques solutions simples pour assurer vous même la sécurité et la disponibilité de votre site Web en vous décrivant les mécanismes actuellement en place sur SysKB.
Que s’est-il passé chez OVH?
OVH vient de connaître sa plus grosse panne informatique depuis plus de 10 ans sur son Datacenter Parisien. Conséquence plus de 50 000 sites Web de type mutualisés on été indisponibles pendant près de 29 heures.
L’incident s’est produit Jeudi 29 Juin à 18h30, et OVH n’a pu rétablir la situation qu’hier soir peu avant minuit. Et encore OVH a du restaurer des sauvegardes du jour précédent, ce qui fait que les victimes concernés ont certainement perdu des données.
Octova Kabla en personne s’est exprimé sur le sujet. Il explique qu’un incident s’est produit sur une baie de stockage EMC VNX 5400. Cette baie fait partie d’un ensemble composé de 96 disques SSD configuré en active / active. Le CEO n’est pas plus précis sur la technologie EMC employée pour faire fonctionner cet “ensemble” mais il précise que EMC n’est pas directement en cause.
Ce qui laisse présager donc que OVH n’a certainement pas respecter tous les prérequis techniques nécessaires lorsqu’on déploie ce type de “cluster”.
La prise de conscience …
Je publie des articles sur SysKB depuis 2008.
Au début je ne prenais aucune précaution et me contentais de l’excellente offre mutualisée de 1&1, le plus gros concurent OVH en Europe. A part quelques ralentissements passagés je n’ai jamais vraiment eu à me plaindre du service 1&1 qui a d’ailleurs le mérite d’être joignable au téléphone. (Tu lis bien ça Octave ?).
Mais j’ai rapidement compris qu’en cas de problème chez mon hébergeur je risquais non seulement une interruption de service rendant mon site indisponible, mais pire encore la perte pure et simple de toutes mes données.
L’interruption de service momentanée est regrettable mais au pire ce n’est qu’un manque à gagner passager.
En revanche perdre toutes vos données peut dans certains cas se traduire par “mettre la clé sous la porte“.
Comment SysKB est-il protégé ?
SysKB est hébergé sur un VPS de l’offre 1&1 Serveur Virtuel Cloud. Il s’agit d’une machine virtuelle Linux que 1&1 me met à disposition avec des ressources qui me sont dédiées. Mon VPS est une machine virtuelle Debian de 2 coeurs / 4 Go / 120 GB de SSD. La machine est costaud mais vous êtes plus de 10 000 à me rendre visite quotidiennement. Je vous dois au moins ça, et si le site est rapide ce n’est pas pour rien 😉
Je loue également un autre VPS chez OVH avec 1 cœur / 6 Go RAM / 25 GB d’espace disque. Je m’en sers comme VPS de secours. J’ai déployé les mêmes composants que sur mon VPS de production, à savoir la pile LAMP – Linux / Apache / MySql / PHP.
Sur le VPS de production chez 1&1 j’ai paramétré une tâche planifiée crontab qui se charge d’exécuter automatiquement et quotidiennement les tâches suivantes :
- une commande mysqldump sauvegarde la base de données MySQL.
- une commande tar créée une archive compressée du répertoire WordPress.
- une commande rsync réplique les sauvegardes du VPS de production vers le VPS de secours.
- une commande rsync réplique le répertoire WordPress de production vers le répertoire Apache du VPS de secours.
Toutes ces opérations durent moins de 5 minutes alors qu’il y a quand même 2 GB à répliquer entre 1&1 et OVH.
Si mon VPS de production tombait en panne, à cause d’une corruption système ou d’une défaillance de mon hébergeur, il me faudrait moins d’une heure pour remettre mon site en ligne sur le VPS de secours
Je test régulièrement le fonctionnement de mon VPS de secours en restaurant la dernière base de données afin de vérifier si tout est opérationnel.
L’avantage d’un VPS, par rapport à un hébergement mutualisé, c’est que vous avez le contrôle total sur la couche système, ça permet notamment de mettre en place les processus automatisés que j’ai décris précédemment.
A lire également : Comment choisir le meilleur hébergeur WordPress pour son blog ou site web
Si vous avez un hébergement mutualisé ?
Si vous avez un hébergement mutualisé et bien mon premier conseil c’est peut être d’arrêter et de prendre un VPS … Je dis cela en plaisantant mais très objectivement si vous êtes débrouillard en informatique c’est largement à votre portée.
Je recommande sans hésiter les VPS proposés de l’offre 1&1 Serveur Virtuel Cloud. Je n’ai rien contre OVH, mais l’interface de gestion est incomparable chez 1&1, quand au support client vous avez quelqu’un au téléphone, chez OVH …
Mais si vous tenez à votre hébergement mutualisé sauvegardez votre base de données quotidiennement avec un plugin WordPress comme WP-DBManager. Envoyez-vous une copie automatiquement par mail plutôt que de la laisser sur l’hébergement mutualisé.
Pour le répertoire WordPress utilisez un outil comme WinSCP ou FileZilla pour transférer une copie de votre site sur votre PC.
Si vous étiez hébergé chez OVH et que vous étiez concerné par l’incident majeur vous auriez ainsi pu remettre en service vous même votre site Web de la manière suivante :
- souscrire une nouvelle offre mutualisée chez un autre hébergeur
- transférer votre répertoire WordPress de votre PC vers le nouvel hébergeur
- restaurer votre base de données avec PhPMyAdmin, l’interface de gestion proposé par les hébergeurs mutualisés
- modifier l’adresse de redirection de votre nom de domaine vers votre nouveau site.
Conclusion
On est jamais aussi bien servi que par soit même.
Même si votre hébergeur fait valoir son haut niveau de sécurité et ses certifications en tout genre, il n’en reste pas moins qu’il n’est pas infaillible.
Garantissez vous même la sécurité et la pérennité de votre site Web.
Informez-vous, documentez-vous, et ne soyez pas démuni le jour ou un sinistre se produit.
“La pire des ignorances est d’ignorer ses compétences.” – Lucien Arréat