O que é necessário para um sistema de backup completo?

Question

Para o meu novo servidor, quero configurar uma solução de backup adequada. Eu encontrei uma ótima configuração que fará backups incrementais duas vezes ao dia por meio do Dropbox. Eu planejo fazer backup dos meus vários bancos de dados, do diretório webroot, do diretório / etc / repository / etc / var / log.

O que mais preciso saber para fazer um backup adequado e qual é a configuração padrão aqui para garantir que você possa restaurar rapidamente a partir de um backup em caso de falha do sistema?

Estou pensando em usar o Puppet, pois ele descreve como o sistema deve ser. Meu procedimento de restauração ficaria assim:

1. Instalar o fantoche
2. Executar minha configuração de marionetes
3. Restaurar meus backups do Dropbox (devo criar um script para fazer isso? Provavelmente)

Isso também deve permitir que eu crie um clone do meu servidor de produção para uso em ambientes dev, correto? Estou perdendo alguma coisa de importância?

    

Answer 1

Nós construímos sistemas de backup para uma finalidade: Para habilitar restaurações. Ninguém se importa com backups; eles se importam com restaurações.

Existem três motivos para a necessidade de restaurar o (s) arquivo (s): Exclusão acidental de arquivos, falha de hardware ou motivos de arquivamento / legais. Um sistema de backup "completo" permitiria restaurar arquivos em todos esses cenários.

Para a exclusão acidental de arquivos, coisas como Dropbox e RAID falham porque elas simplesmente refletem todas as alterações feitas no sistema de arquivos, e um arquivo excluído desaparece nesses cenários. Seu sistema de backup deve ser capaz de restaurar um arquivo para um ponto recente no tempo com bastante rapidez; de preferência, a restauração terminaria em segundos a minutos.

Para falhas de hardware, você deve usar soluções como RAID e outras abordagens de alta disponibilidade sempre que possível para garantir que seu serviço permaneça ativo e em execução, pois uma restauração completa de um sistema pode levar horas ou possivelmente dias devido à necessidade de lendo e escrevendo para mídia (relativamente) lenta.

Por fim, os arquivos, ou backups completos (ou equivalentes) dos sistemas em um ponto específico no tempo, podem fornecer restaurações em cenários legais e de recuperação de desastres. Estes normalmente seriam armazenados fora do local, no caso de um meteoro perdido transformar seu data center em uma cratera fumegante ...

Seu sistema de backup completo deve ser capaz de suportar restaurações para qualquer um desses três tipos, com níveis variados de serviço (SLA). Por exemplo, você pode decidir que um arquivo excluído pode ser restaurado com uma granularidade de dia útil nos últimos seis meses e uma granularidade de um mês nos últimos três anos; e que uma falha de disco deve ser capaz de ser restaurada dentro de quatro horas, com não mais do que dois dias úteis de perda de dados. O sistema de backup deve ser capaz de implementar o SLA em um agendamento de backup.

Seu sistema de backup deve ser totalmente automatizado . Isso não pode ser estressante o suficiente. Se os backups não forem totalmente automatizados, eles simplesmente não acontecerão. Seu sistema de backup deve ser capaz de backups totalmente automatizados, prontos para uso, com pouca ou nenhuma configuração especial ou scripts necessários.

Você deve testar periodicamente as restaurações. Qualquer sistema de backup é totalmente inútil se a restauração a partir do backup não funcionar. Eu acho que a maioria de nós tem histórias de horror nesse sentido. Seu sistema de backup deve ser capaz de restaurar arquivos únicos ou sistemas inteiros dentro do SLA que você está implementando.

Você deve comprar mídia de backup continuamente. Não importa se você está apenas fazendo backup de fita no local ou fazendo um backup de nuvem fora do local, verifique se está com o orçamento necessário para pagar os gigabytes (ou terabytes!) De espaço necessários.

Este foi um breve resumo de uma parte do Capítulo 26 de A Prática de Administração de Sistemas e Redes, Segunda Edição , que qualquer pessoa que seja ou aspire a ser um administrador do sistema deve possuir, ler e memorizar.

Eu mencionei muitas coisas que não se aplicam necessariamente à sua situação particular ou que não fazem sentido em um ambiente pequeno como o que você descreveu. No entanto, deve ser uma descrição razoável dos recursos que seu sistema de backup "completo" deve ter, bem como por que eles são necessários.

    

Answer 2

O
1. DropBox seria uma maneira arriscada de fazer backups. Não há SLA / QoS, e é provavelmente contra seus TOS normais despejar tantos dados em seus servidores de maneira automatizada. Eles se isentam especificamente de qualquer responsabilidade em acessar seus dados - eles podem cortar o acesso, destruir dados ou ir à falência a seu próprio critério e sem aviso prévio.
2. Nenhum procedimento de backup é "válido" até que você tenha realmente restaurado, é a única maneira de ter certeza. Muitos softwares de backup fornecem um recurso de "validação", isso é pior do que inútil para a maioria das pessoas, pois valida que alguma coisa foi gravada em um meio de backup, não que o < em> algo é realmente útil para restaurar um sistema operacional.
3. Documentação implacavelmente completa garante que você será capaz de seguir os procedimentos de restauração quando ocorrer um desastre - a documentação de teste deve ser parte do teste de restauração do sistema. Além disso, essa outra pessoa será capaz de concluir os procedimentos caso você seja atingido por um ônibus (a Lei de Murphy e tudo mais).
4. A restauração só é útil se puder ser realizada em um período de tempo significativo. Por exemplo, se demorou um ano para restaurar os dados que seriam inúteis. Você deve determinar que intervalos de tempo são necessários para sua situação em três níveis de funcionalidade: funcionalidade mínima, operações diárias, completa. Teste sua solução proposta, veja se ela atende aos requisitos de tempo.

Answer 3

Naw. Você é bom por agora. Pelo menos com os conceitos ...

• Pense no estado do seu sistema no momento de seus backups. Talvez você não queira fazer backup de um banco de dados ativo ...
• Ou pense no seu hardware. Você está fazendo tudo o que pode para tornar a máquina o mais resiliente possível? Por exemplo, eu quero restaurar a partir de um backup para ser a última coisa que tenho que fazer em uma situação de emergência.
• As interrupções e as pequenas falhas de serviço podem ser reduzidas com o uso de hardware de qualidade, portanto, verifique se você está usando RAID, equipamentos de classe de servidor e observando uma abordagem mais local à proteção de dados.
• Pense nos tipos de falhas e situações contra as quais você está protegendo.
• Eu não usaria necessariamente o DropBox, mas a ideia de proteção externa está correta.

Answer 4

Meu sistema de backup preferido e verdadeiro é:

1. Instantâneos por hora de todos os bancos de dados (e um instantâneo arquivado por dia durante duas semanas, um instantâneo arquivado por semana durante um ano.)
2. Servidores descartáveis. Ou seja, todos os standups do servidor são armazenados no git e implantados automaticamente (muito parecido com o que você está dizendo com o fantoche, nossa ferramenta preferida é o chef.) Essencialmente, um novo servidor pode ser levantado do zero usando apenas o código que você tem no git, o que significa que quaisquer hosts de desenvolvimento são construídos de maneira semelhante aos seus servidores de produção.

O servidor puppetmaster ou chef nestes casos pode ser um potencial ponto de falha; novamente, automatize a reconstrução deles o máximo possível e tenha scripts disponíveis para permitir que nós existentes sejam inicializados em um novo host de gerenciamento de servidores o mais rápido possível, no caso de a caixa antiga ser derrubada. Descobri que às vezes pode demorar muito mais tempo para reconstruir esse tipo de host a partir de um backup, do que para criar um novo a partir do zero (e a restauração de backups pode reintroduzir acidentalmente as mesmas falhas ou problemas que causaram a queda no backup). primeiro lugar.)

Em uma veia diferente, se você tiver mais de um par de servidores, hosts, etc., vale a pena investir para usar um servidor de log central. Se eles estão alojados (e copiados) de uma fonte, isso poupa a dor de cabeça de ter logs no resto de seus hosts se acumulando e ocupando espaço. Os dados de log são de ouro, mas se eu tiver 20 servidores de APIs servindo todo o tráfego, e eu for atingido com algo como um DDoS, não ter a agregação de meus logs significa que estou procurando uma agulha em um palheiro. Se você for armazenar seus logs de infraestrutura (e você deve!), Armazene-os uma vez, em uma plataforma de backup robusta.

G'luck ~!

    

Answer 5

RAID, & serviços como dropbox "back up" todas suas mudanças. Incluindo os erros que você deseja recuperar usando um backup.

É por isso que todos os tipos sysadmin estão ficando muito impacientes sobre por que coisas como RAID ou serviços de armazenamento de arquivos em nuvem da toytown que dependem do espelhamento de alterações em seus arquivos à medida que acontecem são não backups. Isso não quer dizer que esses serviços não são úteis. Eles são, mas eles não são backups porque eles não fornecem integridade de dados.

Um backup deve ser um instantâneo de como as coisas estavam no momento em que o backup foi feito, não um registro ao vivo continuamente gravado de todas as coisas boas e ruins que acontecem com seus dados quando acontecem. Existem provedores de nuvem que oferecem backups reais se você procurar, e eles funcionam de maneira diferente dos serviços do tipo dropbox / skydrive.

Quando se trata disso, a escolha é a que tipo de risco você está disposto a se expor em relação ao seu orçamento para mitigar esses riscos. Se você acha que algo como o Dropbox é bom o suficiente, então depende de você. Mas você precisa ser claro sobre o que ele fará e o que não fará por você - por favor, não se engane, dizendo que é um backup real.