Planifier une catastrophe

Je travaille pour une petite entreprise de marketing qui s'occupe é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 une défaillance catastrophique d'une certaine sorte. Ce pourrait être le serveur qui a explosé, Hostgator a eu de sérieux problèmes de réseau, le FBI a fait un de leurs fameux raids "prenez tous les serveurs que nous voyons", etc. Fondamentalement, tout scénario où une panne prolongée est attendue. Nous sommes ensuite passés au niveau supérieur 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 pourrait être dû à un incendie, une inondation, etc. Je sais que les probabilités que notre serveur soit en panne pendant une longue période de temps et que nos fichiers locaux soient simultanément inaccessibles sont éloignés, mais il suffit de deuxde mauvaises choses se produisent et c'est là que nous en serions. (Si vous avez déjà eu un pneu crevé et découvert que votre roue de secours était crevée ou manquante, vous savez à quel point il est facile pour deux mauvaises choses de se produire simultanément).

Inutile de dire que nous voulons être préparés à des événements de type «pire scénario», car cela nous ferait presque certainement faillite. Mes deux questions sont donc:

1. Que pourrions-nous faire pour nous préparer à une panne prolongée de Hostgator? Dans un scénario idéal, les sites Web de nos clients et, espérons-le, les e-mails seront de nouveau opérationnels rapidement.

2. Qu'est-ce qu'un plan de sauvegarde robuste 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 les solutions sont abordables, mieux c'est.

Je vous suggère:

1. Mettez automatiquement en miroir tout le contenu et la configuration de votre serveur principal vers un serveur de sauvegarde secondaire sur un réseau complètement séparé dans un centre de données différent. Utilisez RSync, FXP, voodoo cPanel ou toute autre méthode que vous souhaitez automatiser la synchronisation.

2. Utilisez la commutation de basculement DNS pour acheminer automatiquement le trafic vers le serveur de sauvegarde si le serveur Hostgator ne répond pas.

Cela signifie que vous avez constamment une sauvegarde «à chaud» en attente au pire, plutôt qu'une sauvegarde «à froid» qui nécessite une intervention manuelle et beaucoup de brouillage et de panique. Cela signifie également que vos clients ne sauront jamais que leur site est tombé en panne avant vous, ce qui peut être pénible pour tout le monde.

Vous pouvez configurer le DNS de basculement à l'aide d'un fournisseur tel que DNS Made Easy . Pour chaque domaine que vous hébergez, vous devez configurer jusqu'à cinq adresses IP de sauvegarde, une pour chacun de vos serveurs de sauvegarde. Une fois cela fait ...

1. DNS Made Easy vérifie votre serveur principal de deux à quatre minutes et, s'il ne détecte pas de réponse, il achemine le trafic vers l'adresse IP secondaire.

2. DNS Made Easy continue de vérifier le serveur principal. Lorsqu'il apparaît, il redirige le trafic vers le premier serveur ou, si vous préférez, le conserve à la sauvegarde pendant que vous diagnostiquez ce qui s'est mal passé et corrigez le serveur principal.

Bien sûr, cette solution augmentera vos coûts d'exploitation, que vous devrez en quelque sorte répercuter sur les clients, mais - si vous êtes dans un secteur où les temps d'arrêt vous mettraient hors service - le paiement d'un serveur largement redondant vaut probablement la peine pour une seule fois, il sauve l'entreprise.

Au-delà de ça:

Dupliquer, dupliquer, dupliquer

Plus vous avez de sauvegardes indépendantes, mieux c'est. Je stocke des sauvegardes distantes sur un disque dur local, qui est mis en miroir sur un disque dur externe, sur Dropbox, un référentiel git et un compte FTP distant. Ne prenez aucune chance. Dupliquez autant que vous le pouvez. Si vous devez restaurer à partir d'une sauvegarde manuelle, il est préférable d'avoir un choix de cinq plutôt qu'un choix. La paranoïa est sous-estimée.

Entraînez-vous à restaurer les sauvegardes manuellement

Si vous n'avez jamais essayé de récupérer à partir de l'une de vos sauvegardes, comment savez-vous qu'elles fonctionnent? Cela vaut la peine de faire des exercices d'urgence pour voir ce qui se passerait si vos procédures automatisées échouaient.

• Cloudflare, qui fournit des fonctionnalités de sécurité et de mise en cache pour garder les sites actifs lorsque votre serveur tombe en panne. (Ils reflètent votre site et le servent à partir de leur cache distribué mondialement plutôt qu'à partir de votre serveur directement.)
• Codeguard, qui fournit des sauvegardes automatisées et la restauration du code du site Web (FTP uniquement).
• Site Auto Backup, qui fournit des sauvegardes automatisées et la restauration du code du site Web, des données de messagerie et des informations MySQL via les sauvegardes cPanel. Notez que cela est géré par Hostgator, donc ce n'est pas nécessairement approprié si vous hébergez également votre site avec eux, mais cela pourrait aider les autres.

Cloudflare en particulier semble qu'il serait utile d'éviter les temps d'arrêt et d'améliorer généralement la réactivité du site.

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. Deux éléments clés à prendre en compte avec la solution que vous sélectionnez sont les objectifs de temps de récupération (RTO) et les objectifs de point de récupération (RPO).

Le RTO est essentiellement l'attente du temps qu'il faut pour que les sites soient sauvegardés. Si vous avez un RTO d'une minute ou deux (ou moins), alors vous devriez envisager une solution conforme à ce que Nick a suggéré qui implique la réplication en temps réel de vos fichiers et données vers un centre de données secondaire et un basculement automatique du DNS qui pourrait être effectué avec un service payant ou avec du matériel dans les deux centres de données (comme le BIG-IP Global Traffic Managerde F5 Networks. Cela peut coûter cher, mais cela dépend en grande partie de la réponse à la question "Quel est le coût des temps d'arrêt?" Si votre RTO dure quelques heures ou même quelques jours, vous pouvez envisager des procédures de récupération après sinistre qui peuvent impliquer une implication plus manuelle, comme la mise en ligne de serveurs, le changement de DNS, etc.

Le RPO est essentiellement la fréquence des sauvegardes et la quantité de données que vous êtes prêt à perdre en cas de catastrophe. Si des modifications de contenu et / ou de données se produisent fréquemment, vous aurez probablement un RPO de quelques minutes ou heures et vous devrez peut-être effectuer 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 des données pendant quelques jours, vos sauvegardes peuvent se produire moins souvent.

Comme je l'ai mentionné, je suis d'accord avec une grande partie de ce que Nick avait à dire. Une autre alternative que vous voudrez peut-être envisager est d'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 pour être en mesure de gérer à peu près n'importe quel désastre. Avec quelque chose comme un site cloud ou un serveur cloud (termes utilisés par Rackspace), vous avez l'avantage de pouvoir évoluer également et vous n'avez pas à vous soucier nécessairement de l'aspect matériel physique de celui-ci.

Rackspace propose également des options personnalisées où vous pouvez mélanger votre infrastructure, avec une combinaison de serveurs cloud, de serveurs physiques et de fichiers cloud dans le cadre de votre solution. Une approche hybride peut être quelque chose à considérer en fonction des besoins de vos clients si vous ne voulez pas adopter une approche universelle.

Si cela peut vous aider, il y a aussi une page dédiée à la reprise après 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 vous a aidé.

EDIT : J'ai pensé que cela pourrait aider si vous évaluez des solutions cloud. Le rapport 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 dans une autre installation d'une autre société d'hébergement semble la solution la plus évidente.

Les fichiers peuvent être synchronisés avec des outils comme rsync et unisson. Les sauvegardes SQL peuvent également être synchronisé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) dans un référentiel tiers, comme Project Locker , et si vous versionnez tout votre code pendant que vous travaillez, vous l'avez essentiellement sauvegardé dans votre référentiel qui se trouve sur un troisième emplacement . De ce fait, diminuant encore plus vos chances (presque nulles) de perdre tout le travail en même temps.

Vous pouvez soit effectuer vos validations / vérifications SVN via la ligne de commande, soit via un client comme Versions (pour Mac) ou TortoiseSVN (pour Windows).