Planejando uma catástrofe

Eu trabalho para uma pequena empresa de marketing que também faz web design e desenvolvimento. Hospedamos todos os nossos clientes de web design e desenvolvimento em um servidor dedicado na Hostgator. Temos um servidor dedicado com discos rígidos configurados para RAID 1. Também fazemos backups semanais que são automatizados através do cPanel e baixados localmente por software FTP automatizado.

Hoje estávamos discutindo o que faríamos se a Hostgator tivesse algum tipo de falha catastrófica. Pode ser que o servidor tenha explodido, o Hostgator tenha sérios problemas de rede, o FBI fez um dos seus famosos ataques "pegue todos os servidores que vemos" etc. etc. Basicamente, qualquer cenário em que se espera uma interrupção prolongada. Em seguida, elevamos o nível para o próximo nível e nos perguntamos o que faríamos se o Hostgator tivesse uma interrupção prolongada e não pudéssemos acessar nossos backups locais. Isso pode ser causado por incêndio, inundação etc. Sei que as chances de o servidor ficar inativo por um longo período de tempo e nossos arquivos locais estarem inacessíveis simultaneamente são remotas, mas basta apenas doiscoisas ruins acontecem e é onde ficamos. (Se você já comprou um pneu furado e descobriu que o seu sobressalente estava vazio ou faltando, sabe como é fácil duas coisas ruins acontecerem simultaneamente).

Escusado será dizer que queremos estar preparados para eventos do tipo "pior cenário", pois isso quase certamente nos afastaria dos negócios. Então, minhas duas perguntas são:

1. O que podemos fazer para estarmos preparados para uma interrupção prolongada da Hostgator? Um cenário ideal terá os sites de nossos clientes e, com sorte, e-mails, funcionando novamente rapidamente.

2. O que um plano de backup robusto incluiria para que dados importantes nunca sejam perdidos? Uma solução ideal será automatizada.

Você pode assumir que o custo não é um problema em suas respostas, mas quanto mais acessível for a solução, melhor.

Eu sugiro que você:

1. Espelhe automaticamente todo o conteúdo e a configuração do servidor principal em um servidor de backup secundário em uma rede completamente separada em um data center diferente. Use RSync, FXP, cPanel voodoo ou qualquer outro método que você deseja automatizar a sincronização.

2. Usar comutação de failover de DNS para rotear automaticamente o tráfego para o servidor de backup, caso o servidor Hostgator não responda.

Isso significa que você sempre terá um backup "quente" esperando o pior acontecer, em vez de um backup "frio" que requer intervenção manual e muita movimentação e pânico. Isso também significa que seus clientes nunca saberão que o site deles caiu antes de você, o que pode ser angustiante para todos.

Você pode configurar o DNS de failover usando um provedor como o DNS Made Easy . Para cada domínio que você está hospedando, você configuraria até cinco endereços IP de backup, um para cada servidor de backup. Feito isso ...

1. O DNS Made Easy verifica o servidor principal a cada dois a quatro minutos e, se não detectar uma resposta, encaminha o tráfego para o endereço IP secundário.

2. O DNS Made Easy continua a verificar o servidor principal. Quando surgir, ele redirecionará o tráfego para o primeiro servidor ou, se preferir, o manterá no backup enquanto você diagnostica o que deu errado e corrige o servidor principal.

Obviamente, esta solução aumentará seus custos operacionais, que você terá que repassar aos clientes de alguma forma, mas - se você estiver em um setor em que o tempo de inatividade o afastaria - pagar por um servidor amplamente redundante provavelmente vale a pena. por aquela vez salva a empresa.

Além disso:

Duplicar, duplicar, duplicar

Quanto mais backups independentes você tiver, melhor. Eu armazeno backups remotos em um disco rígido local, espelhado em um disco rígido externo, no Dropbox, em um repositório git e em uma conta FTP remota. Não se arrisque. Duplique o máximo que puder. Se você precisar restaurar a partir de um backup manual, é melhor escolher cinco do que escolher um. A paranóia é subestimada.

Pratique a restauração manual dos backups

Se você nunca tentou se recuperar de um de seus backups, como sabe que eles funcionam? Vale a pena fazer exercícios de emergência para ver o que aconteceria se seus procedimentos automatizados falhassem.

• Cloudflare, que fornece recursos de segurança e armazenamento em cache para manter os sites ativos quando o servidor estiver inativo. (Eles espelham seu site e o servem a partir do cache distribuído globalmente, em vez de diretamente do servidor.)
• Codeguard, que fornece backups automatizados e reversão do código do site (somente FTP).
• Site Auto Backup, que fornece backups automatizados e reversão do código do site, dados de email e informações do MySQL via backups do cPanel. Observe que isso é executado pelo Hostgator, portanto, não é necessariamente adequado se você hospeda seu site com eles também, mas pode ajudar outras pessoas.

O Cloudflare, em particular, parece que seria útil evitar o tempo de inatividade e, geralmente, melhorar a capacidade de resposta do site.

A recuperação de desastres pode ser uma tarefa enorme, especialmente quando se lida com vários servidores, sites e bancos de dados. Dois itens principais a serem considerados na solução que você seleciona são os objetivos de tempo de recuperação (RTOs) e os objetivos de ponto de recuperação (RPOs).

RTO é essencialmente a expectativa de quanto tempo deve levar até que os sites voltem a funcionar. Se você tem uma RTO de um minuto ou dois (ou menos), deve considerar uma solução alinhada com o que Nick sugeriu que envolve a replicação em tempo real de seus arquivos e dados para um data center secundário e failover automático do DNS, o que poderia ser feito com um serviço pago ou com hardware nos dois data centers (como o Global Traffic Manager BIG-IPdas redes F5. Isso pode ficar caro, mas depende em grande parte da resposta à pergunta "Qual é o custo do tempo de inatividade?" Se a sua RTO demorar algumas horas ou até alguns dias, considere os procedimentos de recuperação de desastre que podem envolver mais envolvimento manual, como colocar servidores on-line, alternar DNS, etc. Tedioso, mas certamente econômico, se a sua RTO permitir.

O RPO é basicamente a frequência com que os backups são feitos e a quantidade de dados que você está disposto a perder no caso de um desastre. Se alterações no conteúdo e / ou dados ocorrerem com frequência, é provável que você tenha um RPO de talvez minutos ou horas e esteja lidando com replicação em tempo real ou backups de alta frequência. Se o conteúdo não mudar com tanta frequência ou se você tiver clientes que não se importam necessariamente com a perda de dados por alguns dias, seus backups podem ocorrer com menos frequência.

Como mencionei, concordo com muito do que Nick tinha a dizer. Outra alternativa que você pode considerar é utilizar serviços baseados em nuvem de um dos maiores provedores baseados em nuvem, como Rackspace ou Amazon. Ambos os provedores, em particular, possuem uma infraestrutura maciça para poder lidar com praticamente qualquer desastre causado a eles. Com algo como um site em nuvem ou servidor em nuvem (termos usados ​​pelo Rackspace), você tem a vantagem de poder escalar também e não precisa necessariamente se preocupar com o aspecto físico do hardware.

O Rackspace também possui opções personalizadas disponíveis, nas quais você pode misturar sua infraestrutura, tendo uma combinação de servidores em nuvem, servidores físicos e arquivos em nuvem como parte de sua solução. Uma abordagem híbrida pode ser algo a considerar, dependendo das necessidades do cliente, se você não quiser usar uma abordagem única.

Se isso ajudar, também há uma página dedicada à recuperação de desastres no site da Rackspace, que pode ser encontrada aqui . (Também para constar, eu não sou afiliado à Rackspace, mas usei seus serviços no passado).

Espero que isso tenha ajudado.

EDIT : Pensei que isso poderia ajudar se você estiver avaliando soluções em nuvem. O Relatório do Quadrante Mágico do Gartner para infraestrutura e como serviço e hospedagem na Web pode fornecer algumas dicas sobre outros fornecedores de soluções.

A replicação completa do servidor em outra instalação de outra empresa de hospedagem parece a solução mais óbvia.

Os arquivos podem ser mantidos sincronizados com ferramentas como rsync e unison. Os backups do SQL também podem ser sincronizados e depois carregados no db do slave por scripts.

Verifique se você está executando o controle de versão de todo o seu código com um repositório de código-fonte (SVN ou GIT). Você está usando SVN ou GIT?

Você pode obter uma conta (gratuita ou paga) em um repositório de terceiros, como o Project Locker , e se você fizer a versão de todo o seu código enquanto estiver trabalhando, basicamente terá tudo feito em backup no seu repositório, que está em um terceiro local . Assim, diminuindo ainda mais suas chances (quase nulas) de perder todo o trabalho de uma só vez.

Você pode realizar as confirmações / verificações do SVN por linha de comando ou por um cliente como Versions (para Mac) ou TortoiseSVN (para Windows).