Planifier une catastrophe
Je travaille pour une petite entreprise de marketing qui fait également de la conception et du développement Web. Nous hébergeons tous nos clients en conception et développement Web sur un serveur dédié chez Hostgator. Nous avons un serveur dédié avec des disques durs configurés en RAID 1. Nous effectuons également des sauvegardes hebdomadaires qui sont automatisées via cPanel et téléchargées localement par un logiciel FTP automatisé.
Aujourd'hui, nous discutions de ce que nous ferions si Hostgator avait un type de défaillance catastrophique. Il se peut que le serveur ait explosé, que Hostgator ait eu de graves problèmes de réseau, que le FBI ait organisé l'un de ses fameux raids sur "tous les serveurs que nous voyons", etc. Nous avons ensuite passé au niveau suivant et nous nous sommes demandé ce que nous ferions si Hostgator avait une panne prolongée et que nous ne pouvions pas accéder à nos sauvegardes locales. Cela peut être dû à un incendie, à une inondation, etc. Je sais que les chances que notre serveur soit hors service pendant une période prolongée et nos fichiers locaux étant simultanément inaccessibles sont distantes, mais tout ce qu'il faut, c'est juste - deux mauvaises choses et c'est ce que nous voudrions faire. (Si vous avez déjà eu un pneu crevé et que vous avez découvert que votre roue de secours était crevée ou manquante, vous savez à quel point il est facile que deux choses difficiles se produisent simultanément).
Inutile de dire que nous voulons être prêts pour des événements du type "pire scénario", car cela nous mettrait presque certainement à l’écart. Donc mes deux questions sont:
Que pourrions-nous faire pour nous préparer à une panne prolongée de Hostgator? Un scénario idéal consiste à placer les sites Web de nos clients et, espérons-le, à nouveau opérationnels rapidement.
Qu'est-ce qu'un plan de secours solide comprendrait si des données importantes ne sont jamais perdues? Une solution idéale sera automatisée.
Vous pouvez supposer que le coût n'est pas un problème dans vos réponses, mais plus une solution est abordable, mieux c'est.
La récupération après sinistre peut être une tâche énorme, en particulier lorsqu'il s'agit de plusieurs serveurs, sites et bases de données. Avec la solution que vous sélectionnez, vous devez prendre en compte deux éléments clés: les objectifs de temps de récupération (RTO) et les objectifs de point de récupération (RPO).
RTO indique essentiellement combien de temps il faudra avant que les sites ne soient sauvegardés. Si vous avez un RTO d'une minute ou deux (ou moins), vous devriez envisager une solution conforme à ce que Nick a suggéré, à savoir que la réplication en temps réel de vos fichiers et données sur un centre de données secondaire et le basculement automatique du DNS pourraient être effectué avec un service payant ou avec du matériel dans les deux centres de données (comme le gestionnaire de trafic global BIG-IP de F5 Networks. Cela peut coûter cher, mais cela dépend en grande partie de la réponse à la question "Quelle est la "Si votre RTO dure quelques heures, voire quelques jours, vous pouvez envisager des procédures de reprise après sinistre pouvant impliquer une implication plus manuelle, telles que la mise en ligne de serveurs, le changement de DNS, etc. fastidieux, mais certainement rentable si votre RTO permet cela.
RPO indique la fréquence à laquelle les sauvegardes sont effectuées et la quantité de données que vous êtes prêt à perdre en cas de sinistre. Si les modifications apportées au contenu et/ou aux données sont fréquentes, il est probable que votre RPO dure quelques minutes ou heures et que vous ayez peut-être affaire à une réplication en temps réel ou à des sauvegardes haute fréquence. Si le contenu ne change pas si souvent ou si vous avez des clients qui ne se soucient pas nécessairement de perdre leurs données pendant quelques jours, vos sauvegardes peuvent être moins fréquentes.
Comme je l'ai mentionné, je suis d'accord avec une grande partie de ce que Nick avait à dire. Une autre solution que vous pouvez envisager consiste à utiliser les services basés sur le cloud de l’un des plus grands fournisseurs basés sur le cloud, tels que Rackspace ou Amazon. Ces deux fournisseurs en particulier ont une infrastructure massive en place leur permettant de faire face à presque toutes les catastrophes. Avec quelque chose comme un site cloud ou un serveur cloud (termes utilisés par Rackspace), vous avez l’avantage de pouvoir également évoluer et de ne pas avoir à vous soucier de l’aspect matériel physique de celui-ci.
Rackspace propose également des options personnalisées où vous pouvez mélanger votre infrastructure, en combinant des serveurs cloud, des serveurs physiques et des fichiers cloud dans le cadre de votre solution. Une approche hybride peut être envisagée en fonction des besoins de vos clients si vous ne souhaitez pas adopter une approche unique.
Si cela vous aide, il existe également une page dédiée à la reprise sur sinistre sur le site Rackspace qui peut être trouvée ici . (Aussi pour mémoire, je ne suis pas affilié à Rackspace, mais j'ai utilisé leurs services dans le passé).
J'espère que cela a aidé.
EDIT: Cela pourrait vous aider si vous évaluiez des solutions cloud. Le rapport du Gartner Magic Quadrant pour l’infrastructure et en tant que service et hébergement Web peut vous donner un aperçu des autres fournisseurs de solutions.
La réplication complète du serveur sur un autre site d'une autre société d'hébergement semble être la solution la plus évidente.
Les fichiers peuvent être synchronisés avec des outils tels que rsync et unison. Les sauvegardes SQL peuvent aussi être rynchronisées, puis téléchargées sur la base de données esclave par des scripts.
Assurez-vous que vous exécutez le contrôle de version de tout votre code avec un référentiel de code source (SVN ou GIT). Utilisez-vous SVN ou GIT?
Vous pouvez obtenir un compte (gratuit ou payant) sur un référentiel tiers, tel que Project Locker , et si vous modifiez tout votre code pendant que vous travaillez, vous avez essentiellement tout sauvegardé sur votre référentiel qui est sur un troisième emplacement. De ce fait, vous diminuez encore plus vos chances (presque nulles) de perdre tout le travail en même temps.
Vous pouvez effectuer vos commits/extractions SVN via une ligne de commande ou un client tel que Versions (pour Mac) ou TortoiseSVN (pour Windows).