O backup não é uma tecnologia da moda que é gritada por todos os ferros. Só precisa estar em qualquer empresa séria, só isso. Vários milhares de servidores são armazenados em backup em nosso banco - este é um trabalho complicado e interessante, sobre algumas de suas sutilezas, bem como sobre conceitos errôneos típicos sobre backups que eu apenas quero contar.
Eu tenho lidado com esse tópico há quase 20 anos, dos quais nos últimos 2 anos - no Promsvyazbank. No começo da prática, fiz backup quase manualmente, com scripts que simplesmente copiavam os arquivos. Em seguida, apareceram ferramentas convenientes no Windows: utilitário Robocopy para preparar arquivos e NT Backup para copiar. E chegou a hora de um software especializado, principalmente o Veritas Backup Exec, que agora é chamado de Symantec Backup Exec. Por isso, conheço os backups há muito tempo.
Simplificando, fazer backup é salvar uma cópia dos dados (máquinas virtuais, aplicativos, bancos de dados e arquivos), apenas com certa regularidade. Qualquer caso geralmente se manifesta na forma de uma falha de hardware ou lógica e leva à perda de dados. A tarefa do sistema de backup é reduzir as perdas resultantes da perda de informações. Uma falha de hardware é, por exemplo, uma falha no servidor ou no armazenamento em que o banco de dados está localizado. Lógico - é a perda ou alteração de uma parte dos dados, inclusive devido ao fator humano: excluiu inadvertidamente uma tabela, arquivo, lançou um script para executar uma curva. Também existem requisitos do regulador para armazenar um determinado tipo de informação por um longo período, por exemplo, até vários anos.
O apelo mais típico para backups é a restauração de uma cópia salva dos bancos de dados para a implantação de vários sistemas de teste, clones para desenvolvedores.
Existem vários mitos típicos sobre backups que já é hora de dissipar. Aqui estão os mais famosos deles.
Mito 1. O backup tem sido apenas uma pequena função nos sistemas de segurança ou armazenamento.
Os sistemas de backup ainda são uma classe separada de soluções e muito independentes. Negócios muito importantes confiados a eles. Na verdade, eles são a última linha de defesa quando se trata de segurança de dados. Portanto, o backup funciona em seu próprio ritmo, em sua própria agenda. Um relatório diário é gerado nos servidores; existem eventos que atuam como gatilhos para o sistema de monitoramento.
Além disso, o modelo de acesso ao sistema de backup permite delegar parte da autoridade aos administradores dos sistemas de destino para gerenciar backups.
Mito 2. Quando há RAID, o backup não é mais necessário.
Sem dúvida, matrizes RAID e replicação de dados são uma boa maneira de proteger os sistemas de informações contra falhas de hardware e, se houver um servidor em espera, você poderá alternar rapidamente para ele em caso de falha da máquina principal.
Dos erros lógicos cometidos pelos usuários do sistema, a redundância e a replicação não são salvas. Aqui está um servidor em espera com uma gravação atrasada - sim, ele pode ajudar se um erro for detectado antes de ser sincronizado. E se o momento for perdido? Somente o backup feito no prazo ajudará aqui. Se você souber que os dados foram alterados ontem, poderá restaurar o sistema antes de ontem e extrair os dados necessários. Dado que os erros lógicos são os mais comuns, o bom e antigo backup permanece uma ferramenta comprovada e necessária.
Mito 3. O backup é realizado uma vez por mês.
A frequência do backup é um parâmetro configurável, principalmente dependendo dos requisitos do sistema de backup. É bem possível encontrar dados que quase nunca mudam e não são particularmente importantes, a perda deles não será crítica para a empresa.
Na verdade, eles podem ser copiados uma vez por mês ou até menos. Porém, dados mais críticos são armazenados com mais frequência, dependendo do indicador RPO (Objetivo do ponto de recuperação), que define a perda de dados aceitável. 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.
Ao introduzir sistemas em operação comercial, a documentação de backup é necessariamente aprovada, o que reflete os principais pontos, o cronograma de atualização, o procedimento para restaurar o sistema, o procedimento para armazenar backups e similares.
Mito 4. O volume de cópias está em constante crescimento e ocupa todo o espaço alocado completamente
Os backups têm uma vida útil limitada. Não faz sentido, por exemplo, armazenar todos os 365 backups diários durante o ano. Como regra, é permitido 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 para armazenamento a longo prazo. Por sua vez, também é armazenado por um certo tempo - cada cópia tem uma vida útil.
Há proteção contra perda de dados. A regra se aplica: antes que o backup seja excluído, é necessário formar o seguinte. Portanto, os dados não serão excluídos se o backup falhar, por exemplo, devido à indisponibilidade do servidor. Não apenas o período de tempo é respeitado, mas também o número de cópias no conjunto é controlado. Se o sistema disser que deve haver dois backups completos, sempre haverá dois, e o antigo será excluído somente quando um novo terceiro for gravado com êxito. Portanto, o aumento no volume ocupado pelo arquivo de backup está associado apenas ao aumento no número de dados protegidos e não depende do tempo.
Mito 5. Backup iniciado - tudo travou
É melhor dizer o seguinte: se tudo travar, as mãos do administrador não crescerão a partir daí. Em geral, o desempenho do backup depende de muitos fatores. Por exemplo, a partir da velocidade do próprio sistema de backup: com que rapidez existem armazenamentos de disco, bibliotecas de fitas. Com a velocidade dos servidores do sistema de backup: eles conseguem processar dados, executar compactação e desduplicação. Bem como a velocidade das linhas de comunicação entre o cliente e o servidor.
Um backup pode entrar em um ou vários encadeamentos, dependendo se o sistema redundante suporta multithreading. Por exemplo, o Oracle DBMS permite que você forneça vários encadeamentos, de acordo com o número de processadores disponíveis, até que a velocidade de transmissão esteja contra a limitação da largura de banda da rede.
Se você tentar fazer backup com um grande número de threads, ou seja, uma chance de sobrecarregar um sistema em funcionamento, ele realmente começará a ficar mais lento. Portanto, o número ideal de threads é selecionado para fornecer desempenho suficiente. Se mesmo a menor redução no desempenho for crítica, existe uma ótima opção quando o backup é realizado não no servidor de batalha, mas no modo de espera por clone na terminologia do banco de dados. Este processo não carrega o sistema de produção principal. Os dados podem ser obtidos através de um número maior de threads, 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 as vendas. Além disso, o tráfego pode não ser transmitido pela rede, mas pela SAN.
Tentamos distribuir a carga também ao longo do tempo. Os backups geralmente ficam fora do horário de funcionamento: à noite, nos fins de semana. Além disso, eles não iniciam tudo ao mesmo tempo. Os 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 manchado durante o dia e não adiar tudo durante a noite. Existem muitas sutilezas, considerando tudo, o backup não afetará o desempenho do sistema.
Mito 6. Lançado um sistema de backup - aqui está a tolerância a falhas.
Nunca se esqueça que um sistema de backup é a última linha de defesa, o que significa que devem existir outros cinco sistemas à sua frente que garantam a continuidade, alta disponibilidade e tolerância a desastres da infraestrutura de TI e sistemas de informação da empresa.
Não vale a pena esperar que o backup restaure todos os dados e aumente rapidamente o serviço desativado. A perda de dados desde o momento do backup até o momento da falha é garantida, e os dados no novo servidor podem ser carregados por várias horas (ou dias, por sorte). Portanto, faz sentido criar sistemas tolerantes a falhas completos sem mudar tudo para o backup.
Mito 7. Configurei um backup uma vez, verifiquei se ele funciona. Resta apenas olhar para os logs
Este é um dos mitos mais prejudiciais, dos quais você só percebe falso durante o incidente. Logs sobre backups bem-sucedidos não garantem que tudo correu como deveria. É importante verificar antecipadamente a cópia armazenada quanto à capacidade de implantação. 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. O IBS moderno pode fazer backup de quase tudo, você só precisa configurá-lo corretamente. Se um novo servidor foi adicionado, registre políticas: selecione o conteúdo que será copiado, especifique 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 recursos de arquivos no Windows e Linux / Unix. Os funcionários que suportam o sistema de backup não estão ociosos.
Em homenagem ao feriado, gostaria de desejar a todos os administradores nervos fortes, clareza de movimentos e espaço infinito para armazenar backups!