"Backup e Recuperação" do livro O'Reilly. Altamente recomendado.
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.
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. ;)
"Backup e Recuperação" do livro O'Reilly. Altamente recomendado.
Eu tenho várias regras para mim e minha equipe. Espero que alguns deles sejam úteis para você.
e o final, o principal:
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.
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.
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.
Princípios que tento aplicar ao backup:
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.
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'.
Tags backup-restoration