Faça backup de tudo que você gosta - mas você pode ressuscitar seus dados depois de uma enchente?

Nuvem de armazenamento: Menor custo e aumentar o tempo de atividade

Quando se trata de backups duas palavras valem a pena manter em mente: "se os dados não existe em pelo menos dois locais, ela não existe" e "um backup de restauração, cujo processo não foi testado há apoio em tudo" .

Não há nada como um desastre natural que afeta um de seus locais ao vivo para testar seus procedimentos.

Acabei de ter que lidar com isso, vamos dar uma olhada em como.

Pipe Dreams

Para se ter uma discussão sobre backups, precisamos começar com o que estamos a fazer o backup e por quê.

O cliente em questão tem dois sites, um em Edmonton e uma em Calgary. Cada local é servido por um tubo de fibra - teoricamente capaz de 100Mb em caso de emergência, mas estrangulado abaixo que para atender o nosso acordo ISP.

Se mantivermos o uso cumulativo entre os dois sites abaixo 'X'Mbps (medido no percentil 95), podemos usar toda a largura de banda que queremos. Não há limites, não há cobrança por GB. É uma boa, o custo previsível que podemos gerenciar facilmente.

Mais crítica, em caso de "oh não!", Destapar os tubos de modo que cada um pode usar a 100Mb completa leva um único comando.

Cada local recebe uma grande quantidade de informação de clientes para uso nesse local específico. Esta informação é feita altamente disponível para lidar com a falha de hardware, mas não é replicado fora do local.

Nós spec nossa largura de banda apenas um pouco acima do que precisamos para lidar com dados de entrada, que nunca poderia arcar com o custo de armazenamento em nuvem , mesmo que estamos enviando para um de nossos próprios centros de dados.

Uma vez que temos toda essa infra-estrutura no local para atender às necessidades locais, parece bobo não para hospedar nossos sites voltados para o público e serviços de TI em nossa própria infra-estrutura. Temos nuvens privadas em cada local, bocas de armazenamento, no-breaks e um tubo de gordura. Não é exatamente o Amazon, mas deve ser viável.

Replicar, replicar

Nenhum dos bancos de dados para nossos sites públicos pode ser configurado para replicação ao vivo, porque isso exigiria reescrever o código para acomodá-lo. Por várias razões que não vai acontecer tão cedo.

Então backups são até cron rodando em cada servidor MySQL para criar dumps de banco de dados regulares, zip, criptografar e, em seguida, disparar-los para o nosso servidor de arquivos.

Ao mesmo tempo, a base de código para cada um servidor sofre uma cópia de segurança semelhante. Os servidores de arquivos em questão são os sistemas Windows que executam replicação Distributed File System (DFSR), que faz um trabalho maravilhoso de replicar os backups.

Cada local tem dois servidores de arquivos idênticos em um cluster e ambos têm uma cópia dos arquivos. Os arquivos são disparados através da WAN para o outro local onde vive em um par de cluster de servidor de arquivo que o site também. Neste ponto, eu diria que estamos muito bem imune a falhas de hardware.

Um servidor de backup na sede executa uma versão verdadeiramente arcaica do Retrospect que cria backups de versão para proteger contra Mcfumblefingers Oopsie, malware ou outras questões que possam excluir os backups na participação DFSR. Então, qualquer coisa que é colocada no diretório de backups em qualquer site é automaticamente replicada para dois sistemas por site e controle de versão.

Informação potencial de identificação pessoal é criptografada - tanto no banco de dados e nos rarballs (arquivos que foram compactados ou embalados usando compressão zip) - e nenhuma delas deixa de controle corporativo.

Tão longe, tão bom, ou melhor soluções certamente existem, mas sem orçamento acho que ele começa o trabalho feito.