No meu trabalho, usamos uma caixa Linux para armazenar nosso código-fonte e hospedar nosso software de controle de revisão (svn). Também temos alguns outros produtos como "trac" para gerenciamento de projetos, fisheye e crucible para revisões de código. Se ou quando esta caixa falir, eu gostaria de poder manter todos os serviços, software, contas de usuário, etc., funcionando com quase zero tempo de inatividade. Que solução procuro?
Algumas dicas úteis:
- O custo da solução não é um problema. Eu preferiria ter um custo único do que uma assinatura.
- Quero um trabalho administrativo mínimo para manter o backup e restaurar.
- A caixa fica ociosa à noite e nos finais de semana.
- Temos outra instalação a alguns quilômetros de distância, mas uma conexão relativamente lenta entre os dois edifícios (embora mais rápida à noite). Gostaria desta opção de restauração fora do local em caso de incêndio, etc.
- Quero que o backup seja adquirido, esteja em execução e pronto antes de acessá-lo. Não "após o travamento, compre uma nova caixa, ..."
- A caixa não é nada sofisticada, apenas um desktop padrão com Ubuntu Linux. Nada para o qual o usamos é alto desempenho.
Alguém sabe de uma solução para mim? Não sou muito versado em nada relacionado a Linux ou servidor, então, por favor, dê explicações básicas com suas respostas.
Obrigado!
Responder1
Na verdade, você está falando de três coisas inter-relacionadas, mas diferentes:
- Tolerância a falhas (como continuo executando ou obtenho backup com tempo de inatividade mínimo)
- Backup de dados (o que eu faço quando alguém rm -rf está no meu repositório)
- Recuperação de desastres (o que devo fazer se meu escritório for eliminado da face da terra)
Você realmente deveria pensar neles como três processos distintos, mas inter-relacionados. Entrarei em mais detalhes sobre tolerância a falhas, pois parece ser isso que você realmente está procurando com o tempo de inatividade máximo de 1 hora.
Algumas coisas a considerar para tolerância a falhas:
- Quanto tempo levarei para adquirir novos equipamentos?
- Quanto tempo levarei para reconstruir a caixa?
- Quanto tempo levarei para verificar e restaurar os dados?
Pegue a soma desses tempos, multiplique apenas 30% (nada corre tão bem quanto você pensa em uma emergência) e se essa soma for maior que o tempo de inatividade aceitável, você precisará começar a observar algumas configurações de alta disponibilidade. Se for menor, é sua decisão assumir o risco de que suas estimativas estejam erradas e as pessoas possam ficar inativas por mais tempo do que você esperava.
No que diz respeito a algumas soluções possíveis, há muitas coisas que você pode fazer. Mas em todos os casos eu fariaaltamenterecomendo substituir o desktop por uma máquina de classe de servidor. A qualidade dos componentes é maior e eles são construídos para funcionar 24x7x365, portanto, há uma quantidade razoável de redundância já incorporada ao hardware (boas placas RAID, fontes de alimentação redundantes, etc.)
- Você pode configurar um servidor em espera em seu segundo site e, em seguida, sincronizar novamente seus dados a cada x período de tempo - onde x é a quantidade de dados que você deseja perder se o servidor ficar inativo entre as replicações. O rsync é compatível com tubos de dados muito pequenos após a primeira sincronização, pois envia apenas arquivos delta e alterados. Configure também seus servidores para que eles sejam acessados via CNAME para que você possa simplesmente trocar para onde ele está apontado e pronto.
- Faça o mesmo acima, exceto que o servidor em espera está em seu local principal.
- Obtenha um SAN/NAS e dois servidores. Em seguida, configure-os em um cluster Ativo/Ativo ou em um cluster Ativo/Passivo
Os backups também são uma parte muito importante do cenário. Você deve se lembrar que não há substituto para um backup pontual armazenado fora do local. Pessoalmente, ainda acho que fazer backup em fita e armazená-lo fora do local por uma empresa como a Iron Mountain é a melhor opção. Para o seu ambiente de tamanho, qualquer uma das "grandes" soluções de backup - ArcServ, BackupExec, NetBackup deve funcionar perfeitamente. Certifique-se também de TESTAR seus backups pelo menos trimestralmente. Nada é mais chato do que descobrir que o backup que você precisa é ruim.
A recuperação de desastres é, na verdade, apenas sentar e planejar onde você trabalhará, de onde obterá o equipamento de reposição, certificando-se de ter bons backups externos. Vejo a RD como a integração de todos os componentes mencionados acima em um plano de ação coeso para quando o pior acontecer.
Responder2
Você poderia virtualizar o ambiente e tudo o que precisaria fazer seria restaurar a imagem.
Responder3
Existem muitas opções aqui dependendo da quantidade de dados, da complexidade do sistema principal e de quanto gerenciamento você deseja fazer.
Eu gosto do XenServer para isso se a caixa virtualizada for relativamente pequena (alguns GB). Por exemplo, um servidor de aplicativo interno que executamos tem apenas 3 GB de tamanho. Posso facilmente pará-lo, fazer um backup e transferi-lo para outro sistema. No entanto, se você não estiver familiarizado com o XenServer, esta poderá ser uma curva de aprendizado acentuada.
Eu também uso o software de backup de servidor CDP da R1Soft, mas ele não é adequado para uma recuperação rápida. É ótimo para fazer uma restauração bare-metal completa de um servidor com falha, mas para backup e recuperação em menos de uma hora.
Eu fiz algo assim para clientes: use o software de backup CDP para clonar um sistema primário em um sistema de reserva frio. Isso garante que o sobressalente seja idêntico ao sistema primário. Depois, temos instantâneos de hora em hora armazenados no servidor CDP. O servidor CDP usa um algoritmo de backup muito eficiente, portanto há pouco impacto no servidor ativo.
Em caso de falha, você pode restaurar os dados do servidor CDP para o seu cold spare.
O problema com essa abordagem ou com uma abordagem baseada em rsync é que você precisa ter certeza de gerenciar o hot e o cold spare para que o software permaneça sincronizado. Você não gostaria de executar atualizações do sistema operacional em um e esquecer de fazê-las no outro.
Uma recomendação é tentar da melhor maneira possível usar a configuração padronizada em seu servidor, isso reduzirá o impacto das alterações de configuração/atualização na restauração/ressincronização de dados para o sistema de espera fria.
Além disso, gosto de manter meus dados - são coisas que adiciono - bem isolados do sistema. Se você usar o LVM, os métodos de snapshot do LVM também poderão funcionar.
Há muitas opções a serem consideradas, mas a melhor dependerá de sua experiência interna, do tempo para gerenciar o sistema e dos padrões de uso de dados.
Além disso, se a quantidade de dados for muito pequena, você pode querer procurar ferramentas de backup/recuperação no nível da área de trabalho. Não estou tão familiarizado com eles.
http://www.r1soft.com/ Software de servidor CDP
http://www.citrix.com/XenServer
http://samba.anu.edu.au/rsync/sincronizar novamente
Responder4
parece que algo tão simples como rsync + cron pode ser suficiente aqui.