🥇Backup a postos: desmistificando mitos em celebração

O backup não é uma tecnologia da moda, sobre a qual todos gritam incessantemente. Ele simplesmente deve estar presente em qualquer empresa séria, e é isso. No nosso banco, milhares de servidores são respaldados – é um trabalho complexo e interessante, sobre algumas nuances do qual, assim como sobre crenças equivocadas a respeito de backups, gostaria de falar.

Estou lidando com esse tema há quase 20 anos, sendo que nos últimos 2 anos estou no PromSvyazBank. No início da prática, eu fazia backups praticamente manualmente, com scripts que apenas copiavam arquivos. Depois, surgiram ferramentas convenientes no Windows: o utilitário Robocopy para preparar arquivos e o NT Backup para cópia. E então chegou a hora de softwares especializados, principalmente o Veritas Backup Exec, que agora é chamado de Symantec Backup Exec. Portanto, conheço bem os backups.

Falando de maneira simples, backup é a preservação de uma cópia dos dados (máquinas virtuais, aplicações, bancos de dados e arquivos) por precaução, com uma certa regularidade. A precaução geralmente se manifesta na forma de uma falha de hardware ou lógica, levando à perda de dados. A tarefa do sistema de backup é minimizar os danos causados pela perda de informações. Uma falha de hardware, por exemplo, é a falha de um servidor ou de um armazenamento onde a base de dados reside. A falha lógica é a perda ou modificação de parte dos dados, incluindo devido ao fator humano: acidentalmente excluir uma tabela, um arquivo ou executar um script incorreto. Também existem exigências regulatórias relacionadas à retenção de determinados tipos de informações por longos períodos, por exemplo, de vários anos.

O uso mais típico de backups é a recuperação de uma cópia salvaguardada de bancos de dados para implementação de diferentes sistemas de teste, clones para desenvolvedores.

Ao redor do backup existem vários mitos típicos que já é hora de desmistificar. Aqui estão os mais conhecidos.

Mito 1. O backup é apenas uma função menor dentro dos sistemas de segurança ou armazenamento.

Sistemas de backup ainda são uma classe separada de soluções, e bastante independentes. Eles têm uma tarefa extremamente importante. Na verdade, eles representam a última linha de defesa quando se trata de proteger dados. Portanto, o backup opera em seu próprio ritmo, de acordo com sua própria programação. Relatórios diários são gerados para os servidores, com eventos que atuam como gatilhos para o sistema de monitoramento.

Além disso, o modelo de acesso baseado em funções ao sistema de backup permite delegar parte dos poderes aos administradores dos sistemas-alvo para gerenciar os 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 sistemas de informação contra falhas de hardware, e com um servidor de standby disponível, a mudança para ele pode ser feita rapidamente em caso de falha da máquina principal.

Erros lógicos cometidos pelos usuários do sistema não podem ser evitados apenas com redundância e replicação. Um servidor de standby com gravação delayed - sim, pode ajudar se o erro for detectado antes de ser sincronizado. E se o momento for perdido? Só um backup feito a tempo pode ajudar. Se é sabido que os dados mudaram ontem, é possível restaurar o sistema ao estado de anteontem e recuperar os dados necessários. Considerando que erros lógicos são os mais comuns, o bom e velho backup continua sendo uma ferramenta confiável e necessária.

Mito 3. O backup é algo que é feito uma vez por mês.

A frequência de backup é um parâmetro configurável, que depende principalmente das exigências do sistema de backup. É totalmente possível encontrar dados que praticamente nunca mudam e que não são particularmente importantes, cuja perda não será crítica para a empresa.
Esses dados podem realmente ser salvos uma vez por mês ou até com menos frequência. No entanto, dados mais críticos são salvos com mais frequência, dependendo do valor de RPO (Recovery Point Objective), que estabelece a perda de dados aceitável. Isso pode ser uma vez por semana, uma vez por dia ou até várias vezes por hora. Aqui, são os registros de transações do SGBD.

Ao implementar sistemas em produção, é imprescindível que a documentação sobre backup seja aprovada, refletindo os principais pontos, regulamentação de atualização, procedimentos de recuperação do sistema, armazenamento de backups, entre outros.

Mito 4. O volume de cópias cresce continuamente e ocupa todo o espaço alocado.

Os backups têm um prazo de armazenamento limitado. Não faz sentido, por exemplo, acumular todos os 365 backups diários por um ano. Geralmente, é aceitável guardar 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 é mantida para armazenamento a longo prazo. Esta, por sua vez, também tem um tempo de retenção – cada cópia tem um tempo de vida específico.

Há proteção contra perda de dados. A regra é: antes que um backup seja excluído, o próximo deve ser criado. Portanto, os dados não serão deletados se o backup falhar, por exemplo, devido à indisponibilidade do servidor. Não são apenas os prazos que são respeitados, mas também é controlada a quantidade de cópias no conjunto. Se o sistema definir que deve haver dois backups completos, sempre haverá dois, e o antigo será excluído apenas quando um novo terceiro for gravado com sucesso. Assim, o aumento do volume ocupado pelo arquivo de backups está relacionado apenas ao crescimento da quantidade de dados protegidos e não depende do tempo.

Mito 5. O backup começou - tudo travou.

É melhor dizer assim: se tudo travou, significa que as habilidades do administrador não são as adequadas. Na verdade, o desempenho do backup depende de muitos fatores. Por exemplo, da velocidade do próprio sistema de backup: quão rápidas são as unidades de armazenamento, bibliotecas de fitas. Do desempenho servidores do sistema de backup: se ele consegue processar os dados, realizar compressão e deduplicação. E também da velocidade das linhas de comunicação entre o cliente e o servidor.

O backup pode ser feito em um ou vários fluxos, dependendo de o sistema sendo salvo suportar multithreading. Por exemplo, o SGBD Oracle permite iniciar vários fluxos, correspondendo ao número de processadores disponíveis, até que a velocidade de transferência atinja o limite da largura de banda da rede.

Se você tentar fazer backup com um grande número de threads, há uma chance de sobrecarregar o sistema em funcionamento, e ele realmente começará a desacelerar. Portanto, escolhe-se um número otimizado de threads para garantir desempenho adequado. Se uma redução mesmo mínima no desempenho for crítica, existe uma excelente opção: fazer o backup não do servidor em produção, mas de sua cópia – standby na terminologia de bancos de dados. Esse processo não sobrecarrega o sistema principal. Os dados podem ser capturados através de um maior número de threads, já que o servidor não é utilizado para atendimento.

Em grandes organizações, uma rede separada é criada para o sistema de backup, para que o backup não impacte a produção. Além disso, o tráfego pode ser transferido não pela rede, mas através de SAN.

Nós também tentamos distribuir a carga ao longo do tempo. Os backups geralmente ocorrem fora do horário comercial: à noite, nos finais de semana. Além disso, não são iniciados todos 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, por isso o backup pode ser distribuído ao longo do dia, e não deixado todo para a noite. Há muitas sutilezas; se tudo for considerado, o backup não impactará o desempenho dos sistemas.

Mito 6. Iniciei o sistema de backup – e aqui está a redundância.

Nunca se esqueça de que o sistema de backup é a última linha de defesa, e isso significa que deve haver mais cinco sistemas antes dele, garantindo continuidade, alta disponibilidade e resiliência da infraestrutura de TI e dos sistemas de informação da empresa.

Não deve-se esperar que o backup recupere todos os dados e restaure rapidamente o serviço que caiu. A perda de dados do momento do backup até o momento da falha é garantida, e os dados no novo servidor podem ser transferidos por várias horas (ou dias, dependendo da situação). Portanto, faz sentido criar sistemas de redundância completos, sem deixar tudo a cargo do backup.

Mito 7. Configurei o backup uma vez, verifiquei que está funcionando. Apenas resta olhar os registros.

Este é um dos mitos mais prejudiciais, cuja falsidade só se percebe durante um incidente. Os logs de uma cópia de segurança bem-sucedida não garantem que tudo ocorreu como deveria. É importante verificar antecipadamente se a cópia salva é recuperável. Ou seja, devemos iniciar o processo de restauração em um ambiente de teste e analisar o resultado.

E um pouco sobre o trabalho do administrador de sistemas

Ninguém copia dados manualmente há muito tempo. Os modernos sistemas de recuperação podem fazer backups de praticamente tudo, basta configurá-los corretamente. Se um novo servidor for adicionado, deve-se definir as políticas: escolher o conteúdo a ser copiado, especificar os parâmetros de armazenamento e aplicar um cronograma.

Ainda assim, o trabalho não é pouco devido ao extenso parque de servidores, que inclui bancos de dados, sistemas de e-mail, clusters de máquinas virtuais e recursos de arquivos tanto no Windows quanto no Linux/Unix. Os funcionários que mantêm a funcionalidade do sistema de backup não ficam parados.