O backup não é uma das tecnologias da moda que são comentadas em todos os ferros. Só tem que ser em qualquer empresa séria, só isso. Fazemos backup de vários milhares de servidores em nosso banco - este é um trabalho complexo e interessante, algumas das sutilezas das quais, bem como equívocos típicos sobre backups, só querem ser contadas.
Trabalho neste tópico há quase 20 anos, dos quais os últimos 2 anos foram no Promsvyazbank. Logo no início da prática, fiz backups quase manualmente, com scripts que simplesmente copiavam arquivos. Em seguida, ferramentas convenientes apareceram no Windows: o utilitário Robocopy para preparar arquivos e o NT Backup para copiar. E só então chegou a hora do software especializado, principalmente o Veritas Backup Exec, que agora se chama Symantec Backup Exec. Conheço os backups há muito tempo.
Em termos simples, o backup é manter uma cópia dos dados (máquinas virtuais, aplicativos, bancos de dados e arquivos) apenas por precaução com certa regularidade. Cada caso geralmente se manifesta como uma falha de hardware ou lógica e resulta em perda de dados. O objetivo de um sistema de backup é reduzir a perda de informações. Uma falha de hardware é, por exemplo, uma falha do servidor ou armazenamento onde o banco de dados está localizado. Lógico - trata-se da perda ou alteração de parte dos dados, inclusive devido ao fator humano: apagaram acidentalmente uma tabela, arquivo, lançaram um script torto para execução. Existem também requisitos do regulador para armazenar um determinado tipo de informação por um longo período, por exemplo, até vários anos.
O uso mais comum de backups é a restauração de uma cópia salva de bancos de dados para a implantação de vários sistemas de teste, clones para desenvolvedores.
Existem alguns mitos típicos sobre backup que devem ser dissipados há muito tempo. Aqui estão os mais famosos deles.
Mito 1. O backup sempre foi apenas uma pequena função dentro dos sistemas de segurança ou armazenamento
Os sistemas de backup ainda são uma classe separada de soluções e muito independentes. Eles têm muito trabalho a fazer. Na verdade, eles são a última linha de defesa quando se trata de integridade de dados. Portanto, o backup funciona em seu próprio ritmo, em sua própria programação. Diariamente é gerado um relatório para os servidores, existem eventos que funcionam como gatilhos para o sistema de monitoramento.
Além disso, o modelo de função de acesso ao sistema de backup permite que você delegue parte da autoridade aos administradores dos sistemas de destino para gerenciar os backups.
Mito 2. Quando há um RAID, um backup não é mais necessário.
Sem dúvida, as matrizes RAID e a replicação de dados são uma boa maneira de proteger os sistemas de informação contra falhas de hardware e, se você tiver um servidor em espera, poderá organizar rapidamente a troca para ele caso a máquina principal falhe.
Dos erros lógicos cometidos pelos usuários do sistema, a redundância e a replicação não salvam. Aqui está um servidor de espera de write-back - sim, ele pode ajudar se um erro for detectado antes de ser sincronizado. E se o momento for perdido? Apenas um backup oportuno ajudará aqui. Se você souber que os dados foram alterados ontem, poderá restaurar o sistema para anteontem e extrair os dados necessários dele. Dado o fato de que os erros lógicos são os mais comuns, o bom e velho backup continua sendo uma ferramenta comprovada e necessária.
Mito 3. Um backup é algo que é feito uma vez por mês.
A frequência de backup é uma configuração configurável que depende principalmente dos requisitos do sistema de backup. É bem possível encontrar dados que quase nunca mudam e não são particularmente importantes, sua perda não será crítica para a empresa.
Eles, de fato, podem ser copiados uma vez por mês e ainda com menos frequência. Porém, dados mais críticos são salvos com mais frequência, dependendo do indicador RPO (ponto de recuperação objretivo), que define a perda de dados permitida. Isso pode ser uma vez por semana, uma vez por dia ou até várias vezes por hora. Temos esses logs de transações do DBMS.
Quando os sistemas são colocados em operação comercial, deve ser aprovada a documentação de backup, que reflete os pontos principais, o procedimento de atualização, o procedimento de restauração do sistema, o procedimento de armazenamento de backups e outros.
Mito 4. O volume de cópias está crescendo constantemente e ocupa completamente qualquer espaço alocado.
Os backups têm um período de retenção limitado. Não faz sentido, por exemplo, armazenar todos os 365 backups diários durante o ano. Via de regra, é aceitável manter cópias diárias por 2 semanas, após as quais são substituídas por novas, e a versão que foi feita primeiro no mês permanece em armazenamento de longo prazo. Ele, por sua vez, também é armazenado por um determinado tempo - cada cópia tem uma vida útil.
Há proteção contra perda de dados. A regra se aplica: antes de um backup ser excluído, o próximo deve ser formado. Portanto, os dados não serão excluídos caso o backup não tenha sido concluído, por exemplo, por indisponibilidade do servidor. Não apenas os prazos são respeitados, mas o número de cópias no conjunto também é controlado. Se o sistema for projetado para ter dois backups completos, sempre haverá dois deles, e o antigo será excluído somente quando um novo terceiro for gravado com sucesso. Assim, o crescimento do volume ocupado pelo arquivo de backup está associado apenas ao crescimento da quantidade de dados protegidos e não depende do tempo.
Mito 5. Backup iniciado - tudo travou
É melhor dizer o seguinte: se tudo está pendurado, as mãos do administrador não crescem daí. Em geral, o desempenho de um backup depende de muitos fatores. Por exemplo, na velocidade do próprio sistema de backup: quão rápido são os armazenamentos em disco, bibliotecas de fitas. Da velocidade dos servidores do sistema de backup: se eles têm tempo para processar dados, realizar compactação e desduplicação. E também na velocidade das linhas de comunicação entre o cliente e o servidor.
O backup pode ir para um ou mais fluxos, dependendo se o sistema que está sendo copiado suporta multithreading. Por exemplo, o SGBD Oracle permite dar vários threads, de acordo com o número de processadores disponíveis, até que a taxa de transferência atinja o limite de largura de banda da rede.
Se você tentar fazer backup de um grande número de threads, há uma chance de sobrecarregar um sistema em execução, ele realmente começará a desacelerar. Portanto, o número ideal de threads é escolhido para garantir desempenho suficiente. Se mesmo a menor diminuição no desempenho for crítica, existe uma excelente opção quando o backup é realizado não de um servidor de combate, mas de seu clone - espera na terminologia do banco de dados. Este processo não inicializa o sistema de trabalho principal. Os dados podem ser recuperados por meio de mais fluxos, pois o servidor não é usado para manutenção.
Em grandes organizações, uma rede separada é criada para o sistema de backup para que o backup não afete a produção. Além disso, o tráfego pode não ser transmitido pela rede, mas pela SAN.
Tentamos distribuir a carga ao longo do tempo também. Os backups são feitos principalmente fora do horário comercial: à noite, nos finais de semana. Além disso, eles não funcionam todos ao mesmo tempo. Backups de máquinas virtuais são um caso especial. O processo praticamente não afeta o desempenho da própria máquina, portanto, o backup pode ser distribuído durante o dia e não adiar tudo à noite. Existem muitas sutilezas, se você levar tudo em consideração, o backup não afetará o desempenho dos sistemas.
Mito 6. Lançou um sistema de backup - isso é tolerância a falhas para você
Nunca esqueça que um sistema de backup é a última linha de defesa, o que significa que deve haver mais cinco sistemas à sua frente que garantam a continuidade, alta disponibilidade e tolerância a desastres da infraestrutura de TI e dos sistemas de informações corporativos.
Esperar que o backup restaure todos os dados e levante rapidamente o serviço caído não vale a pena. A perda de dados desde o momento do backup até o momento da falha é garantida, e os dados podem ser enviados para um novo servidor por várias horas (ou dias, se você tiver sorte). Portanto, faz sentido criar sistemas tolerantes a falhas completos sem mudar tudo para um backup.
Mito 7. Configurei um backup uma vez, verifiquei se funciona. Resta apenas olhar os logs
Este é um dos mitos mais prejudiciais, cuja falsidade você percebe apenas durante o incidente. Logs de backup bem-sucedidos não são uma garantia de que tudo realmente ocorreu como deveria. É importante verificar a cópia salva para implantação com antecedência. Ou seja, inicie o processo de recuperação em um ambiente de teste e observe o resultado.
E um pouco sobre o trabalho do administrador do sistema
No modo manual, ninguém copia dados há muito tempo. Os SRKs modernos podem fazer backup de quase tudo, você só precisa configurá-lo corretamente. Se um novo servidor foi adicionado, defina políticas: selecione o conteúdo que será copiado, especifique as opções de armazenamento e aplique a programação.
Ao mesmo tempo, ainda há muito trabalho devido à extensa frota de servidores, incluindo bancos de dados, sistemas de correio, clusters de máquinas virtuais e compartilhamentos de arquivos no Windows e no Linux/Unix. Os funcionários que mantêm o sistema de backup funcionando não ficam ociosos.
Em homenagem ao feriado, gostaria de desejar a todos os administradores nervos fortes, clareza de movimentos e espaço infinito para armazenar backups!
Fonte: habr.com