Estratégias e softwares de backup e restauração usados pelos administradores de sistema

Question

Recentemente tenho lido muito sobre software e estratégias de backup do lado do servidor.

Estou curioso para saber quais estratégias e administradores experientes do software (aqui no ServerFault) usam.

• O que fazer e não fazer para os dados backup e backup do servidor.
• O que fazer quando o servidor realmente explode.
• Qualquer outro tipo de informação relacionada a técnicas de backup e restauração que você gostaria de compartilhar.

Por favor, publique também o ambiente em que você usa essa estratégia (Windows, Linux, etc)

Espero aprender muito com este post e contribuir de qualquer maneira possível no momento em que eu finalizar uma estratégia de backup própria. ;)

    

Answer 1

"Backup e Recuperação" do livro O'Reilly. Altamente recomendado.

link

    

Answer 2

Eu tenho várias regras para mim e minha equipe. Espero que alguns deles sejam úteis para você.

• Todos os dados (exceto logs e caches) devem ser armazenados em backup. Não espere que o sistema nunca falhe. Será. Às vezes nós também fazemos backup de partições de log e cache, para acelerar um processo de restauração do sistema sem fazer diretórios, jogando com permissões, etc.
• Guarde uma documentação do que está em backup e de onde foi feito o backup. Ao trabalhar com qualquer dado, acostume-se a sempre lembrar de onde foi feito o backup, com que frequência e como restaurá-lo.
• Quando você escolhe uma plataforma, sempre verifique as soluções de backup para ela. Especialmente, a rapidez com que você pode restaurar um sistema após a falha. Não escolha uma plataforma até saber como fazer o backup e agora restaurá-la rapidamente. TENTE backup / restaurá-lo antes de instalar, um anúncio sempre mentir.
• Faça backups freqüentes somente para os dados alterados com freqüência. Fazer o backup de todo o sistema a cada hora é simplesmente idiota.
• Qualquer servidor crítico deve ter pelo menos uma duplicata que possa substituir o servidor com falha automaticamente.
• Faça uma auditoria de backup. Pelo menos uma vez por semana. Um sistema de backup automatizado gosta de falhar, especialmente falha alguns dias antes do dia X.
• Mantenha todos os dados possíveis no armazenamento compartilhado. Isso torna o backup muito mais fácil. Mas não confie em seu armazenamento compartilhado, verifique se você pode mudar tudo para o armazenamento de backup rapidamente, de preferência se o sistema puder fazer isso automaticamente.
• Use instantâneos do ZFS ou tecnologia semelhante. Um backup completo + incrementais, combinado com o total. Se o sistema requer fazer um backup completo mais de uma vez - é um sistema BAD (exceto uma fita, é claro), nós vivemos no século 21.
• Quando você escolhe uma solução de fita, sempre calcula um preço por TB. Se é igual ou um pouco mais barato que um HD comum - esqueça a fita. A menos que você não precise restaurar os dados rapidamente, para os arquivos não urgentes, prefiro a fita mesmo que seja mais cara.
• Treine você mesmo. Sem um treinamento, você restaurará sua produção por muito mais tempo.

e o final, o principal:

• Erros humanos - o problema mais comum da perda de dados. Mantenha todos os dados nas duas cópias. Bastante separado para evitar matar ambos com um ou dois comandos. Esta é a principal razão pela qual o RAID NÃO é um backup. Uma falha de hardware significativa é apenas em um segundo ou até em um terceiro lugar.

O que usamos:

Para os servidores - temos tudo no VMWare VSphere e estamos quase satisfeitos com o DataRecovery. Para Oracle e outros bancos de dados, usamos suas ferramentas internas. Para as estações de trabalho - nós finalmente migramos tudo para iSCSI ou thin clients, então não mais lento Acronis e outras merdas.

    

Answer 3

Temos um ambiente misto (70% Linux e 30% Windows). Por motivos (principalmente) herdados, usamos o EMC Networker (com um trocador de fitas) no lado do Windows e o bacula no lado do Linux. Todos os servidores linux são cobertos pelo bacula, e o diretório de backup resultante nesse servidor é então incluído nos backups da EMC (nossos backups noturnos têm aproximadamente 3 TB de tamanho).

A estratégia básica é que, para todas as máquinas, cobrimos apenas aquela parte que não é recuperável através de fontes padrão. Em outras palavras: arquivos de dados, bancos de dados, arquivos de configuração e assim por diante. Em alguns casos, o processo de backup não tem um cliente local e usa uma montagem NFS para obter acesso ao material que precisa de backup (porque, além da montagem NFS, esses servidores de destino mudam o tempo todo e é mais fácil fornecer apenas Ponto de montagem do NFS).

Se um servidor ficar completamente AWOL (nunca teve esse caso), nós compraríamos o hardware de substituição, instalaríamos o sistema operacional e todos os pacotes, restauraríamos os arquivos de configuração e os dados e o tempo todo. Como disse, nunca tivemos o caso em que um servidor foi completamente doolally tap. Nossos backups são usados principalmente para usuários que acidentalmente excluam arquivos ou arquivos corrompidos. Tivemos casos em que alguns servidores de compilação tiveram que ser restaurados do zero porque alguns engenheiros os colocaram em tal estado que a recuperação normal era impossível, e o princípio funcionou bem (além do fato de que restaurar 30 GB de dados leva algum tempo) . Eu provavelmente devo acrescentar que todos os nossos servidores de missão crítica são executados em matrizes RAID e fontes de alimentação redundantes, e que normalmente também guardamos algumas peças de hardware sobressalentes.

    

Answer 4

Nossa solução de backup provavelmente não é a melhor prática, mas funcionou muito bem. O ambiente é misto Windows (80%) e Linux (20%). Costumávamos usar backups em fita para nossos servidores de banco de dados e Repositórios de controle de origem, mas abandonamos essa ideia recentemente (uma decisão tomada acima da minha cabeça!)

Usamos a edição do StorageCraft ShadowProtect Server em nossos servidores Windows com políticas variáveis, dependendo da importância do serviço (por exemplo, o backup do Exchange foi feito a cada meia hora). Ele cria imagens de base do sistema com impacto mínimo no desempenho (embora em servidores de banco de dados de carga pesada, vimos uma série de problemas - principalmente a paralisação da máquina devido ao estouro de E / S do disco). Funcionou muito bem e nos deu a opção de Hardware Independent Restore, o que significa que não precisávamos nos preocupar muito com o fornecedor que usamos para substituir o hardware (temos servidores da IBM, HP, Dell e Custom build usando barebones da Tyan).

Os servidores Linux eram um assunto diferente, nós usamos principalmente scripts personalizados escritos pelo engenheiro de sistemas sênior. O princípio básico era fazer backup de dados importantes e não se preocupar muito com o SO.

Temos uma SAN HP EVA StorageWorks de 40 TB apresentada aos nossos servidores de arquivos e servidores de e-mail, que fornecem um nível extra de proteção. Nossos servidores de backup foram criados com 24 TB de armazenamento usando o RAID 5. Usamos o SyncBack Pro para fazer backups noturnos de compartilhamentos de arquivos de projetos e quaisquer outros backups de nível de arquivo que fossem necessários. Uma vez no servidor de backup principal, os dados eram SCP para o servidor off-site.

Também garantimos que temos contratos de suporte para a maioria de nossos hardwares. Correção de 24 horas para Desktops, 8 horas para Servidores que temos da Dell e da HP, o que torna a vida muito mais simples.

    

Answer 5

Princípios que tento aplicar ao backup:

1. Os arquivos que compõem o backup devem ser idênticos aos que estão sendo armazenados em backup, para facilitar a restauração. A compactação e a criptografia, se necessário, devem ser tratadas no nível do sistema de arquivos.
2. Os backups devem ser automatizados e todas as noites, e você deve receber um e-mail do processo quando ele for concluído, declarando se foi bem-sucedido ou não e como a mídia de backup estava completa
3. Os backups devem ser mantidos em um local geograficamente remoto para os dados de que eles fazem backup
4. Bancos de dados e outros sistemas que não podem ser suportados de forma sensata, fazendo uma cópia de seus arquivos, devem ser despejados regularmente e os arquivos copiados devem ser copiados.

No que diz respeito ao software, eu encontrei rdiff-backup é uma boa solução para me permitir chegar nos últimos 30 dias de backups. Eu executo um script de wrapper simples em volta dele todas as noites, o que faz o backup de todos meus servidores linux para o servidor de backup, onde os backups vivem em uma partição LVM criptografada. O BackupNinja é executado em todos os servidores e cuida do despejo de bancos de dados, etc., antes que os backups noturnos sejam executados.

    

Answer 6

Faça backup por um segundo. Existem três "razões" para fazer backup dos seus dados.

1) Recuperação de desastres
Isso protege você dos cenários "um meteoro atingiu o seu prédio". Você precisa de uma maneira rápida de reconstruir seus servidores rapidamente. A resposta clássica a essa pergunta é backups completos do sistema. O problema é que depois de alguns dias, uma grande parte dos seus dados é quase inútil para DR (os dados do sistema operacional, muitos dados de aplicativos que são extremamente estáticos, etc).

2) Erro do usuário.
Este tipo de backup cobre o "uh, eu estraguei esse arquivo há dois meses, e é realmente importante", ou "uh, nosso DBA deixou cair essa tabela, mas esqueci deste relatório mensal que precisamos executar uma última vez", etc. Por quanto tempo você mantém esses backups é uma decisão de negócios. Eu ouvi tudo de 1 mês a 2 anos.

3) Arquivamento.
Esses são os backups REALMENTE de longo prazo, geralmente exigidos por agências governamentais ... "O IRS exige essa classe de registros financeiros por 7 ou 14 anos". A boa notícia é que isso geralmente é um pequeno subconjunto de seus dados. As fitas são boas para isso, ou muitas vezes mídias óticas.

Armado com essas classes de dados (e uma boa auditoria do seu ambiente), você pode começar a classificar de que tipo de dados você realmente precisa.

Aqui está nossa estratégia de backup (nota: é um pouco complicado). Estratégia geral: faça backup em disco, duplique alguns dados em fita. Nós executamos backups completos uma vez por mês, backups de nível 2, um por semana, e backups de nível 3, uma vez por dia. Mantemos os backups completos por 3 meses em disco e 1 ano em fita. Mantemos os backups de L2 por 4 semanas e os backups de L3 por 2 semanas. Isso nos dá uma alta resolução de backup nas últimas duas semanas e, quanto menor a resolução, mais tempo de volta você precisa. Em nossos compartilhamentos de usuários (netapp), não fazemos backups L3, em vez disso, confiamos em instantâneos. Isso torna a restauração muito mais fácil de gerenciar.

A grande vitória que temos é que temos 3 'sites'. Um deles é o site primário, e nosso ambiente de backup (discos, servidores de mídia, robôs de fita, etc) vive em um dos sites secundários. Esta é a nossa grande proteção contra os problemas do tipo 'datacenter gone'.