Desenvolvendo uma estratégia eficiente de Backup & Restore em ambientes transacionais
Sálvio Padlipskas
Na área de administração de banco de dados, a definição e implementação da política de Backup & Restore serve para garantir a disponibilidade contínua da informação em tempo hábil para a tomada das decisões corporativas, principalmente quando ocorrem contratempos.
Esse artigo propõe como desenvolver, inicialmente, uma política do processo de Backup corporativo. Para alcançar esse resultado, detalham-se as etapas necessárias para garantir uma estratégia consistente de backup e recover em bancos de dados transacionais, podendo ser incorporada em qualquer ambiente corporativo que armazena desde pequenos volumes de informações até ambientes críticos. Exemplos desses ambientes são leilões on-line e bolsa de valores, onde o tempo e o uso da informação pode fazer a diferença entre a prosperidade e a ruína.
Estratégia de backup
O ponto chave para o desenvolvimento de uma boa estratégia de backup está diretamente associada à disponibilidade do dado para a empresa. O bom senso deve imperar nesse momento, pois de nada adianta ter um ambiente “supersônico” de backup e restore instalado, quando na verdade o que a empresa precisa é simplesmente ter um “teco-teco” ativo e operante.
O resultado a ser alcançado é manter os ambientes de desenvolvimento, teste, integração, homologação e produção disponíveis e atualizadas para uso constante. As equipes envolvidas: DBA, DataCenter (responsável pela execução e checklist do processo) e a gerência da empresa devem estar sempre atualizados em relação às informações geradas pelo processo de backup.
O alicerce dessa estratégia está baseado em três fases bem conhecidas:
1. Catalogar servidores de banco de dados / aplicações;
2. Levantamento dos requisitos do ambiente;
3. Implementação do processo de Backup & Recover.
Catalogar servidores de banco de dados / aplicações
Os servidores de banco de dados e suas respectivas aplicações devem ser mapeados para que seja possível identificar o grau de importância da disponibilidade dos dados. Nessa fase, o papel da equipe de desenvolvimento e das áreas afins que se utilizam da informação é primordial para desenvolver estratégias globais (por servidor) e distintas (para cada aplicação) de procedimentos de backups.
O resultado final do material desenvolvido deve ser aprovado pela área técnica e de negócio, e as informações atualizadas a respeito dos backups realizados devem ser disponibilizadas para as pessoas interessadas.
A Tabela 1 exibe um exemplo de servidores, aplicações e objetos que devem participar de um determinado procedimento de backup.
Tabela 1. Servidores e Aplicações mapeadas em um procedimento de backup.
Dependendo da quantidade de aplicações existentes, é necessário conhecer quais fazem parte do servidor e suas principais características.
A Tabela 2 realiza um ranking das aplicações ordenadas por importância de disponibilidade nos servidores.
Tabela 2. Ranking de aplicações ordenadas por disponibilidade nos servidores.
A tabela indica as prioridades de disponibilidade de acesso das aplicações do banco de dados a ser analisado. Percebe-se claramente que a empresa optou por dar preferência ao ambiente de desenvolvimento em termos de disponibilidade, indicando que muitas customizações são implementadas no ambiente de produção sem passar pelas fases essenciais TEIN e HOMO (nomes dados para os ambientes de Teste e Homologação) devido às constantes mudanças exigidas pelo mercado para alavancar as vendas.
Um ponto extremamente positivo nessa fase é a documentação fornecida para cada servidor de banco de dados. O nível de detalhamento pode ser enriquecido de itens importantes como: Sistema Operacional utilizado, versão do banco de dados, versão das aplicações, linguagens de programação utilizada no desenvolvimento das aplicações, entre outros.
Nessa fase têm-se os servidores e as aplicações que irão participar do processo de backup. O volume de dados a ser manuseado por aplicação é de extrema importância para desenvolver uma estratégia que adeque a necessidade da empresa ao tempo de recuperação dos dados.
Levantamento dos requisitos do ambiente
Essa fase delimita o escopo do projeto a ser desenvolvido, proporcionando definir qual é o tempo limite de indisponibilidade para cada ambiente e identificando quais são os tipos de backups a serem implementados. Para definir corretamente a atuação das pessoas envolvidas nessa etapa do processo, os requisitos podem ser assim divididos:
1. Requisitos operacionais;
2. Requisitos de negócios;
3. Requisitos técnicos.
Os requisitos operacionais de um ambiente de banco de dados afetam a definição da estratégia de Backup & Recover. Ao levar em conta esses requisitos, determine se um banco de dados está disponível para operações contínuas. Por exemplo: caso seja necessário ter um banco de dados trabalhando 24 horas por dia e 7 dias por semana, ou seja, de forma ininterrupta, desenvolva um procedimento de backup que possibilite o mínimo de incomodo para os usuários que estão conectados.
Questões importantes são definidas nessa fase. A volatilidade dos dados no database; a freqüência de atualizações ocorridas nas tabelas e índices; o agendamento e a documentação das alterações realizadas na estrutura dos objetos bem como com qual freqüência o ambiente sofre intervenção do DBA são aspectos importantíssimos de serem abordados. Por exemplo: se os dados forem altamente voláteis ou até mesmo se o ambiente é extremamente instável, será necessário criar uma estratégia para tornar o backup freqüente.
No requisito de negócio é importante reconhecer qual é o impacto negativo do período de inatividade do banco de dados para o negócio. A idéia é reduzir o tempo do MTTR (Mean Time To Recover – Tempo Médio de Recuperação) para garantir que o banco de dados esteja indisponível o menor tempo possível.
Nos requisitos técnicos, a configuração e parametrização do banco de dados fornecem informações indispensáveis no desenvolvimento da estratégia de backup. Os recursos do ambiente, como o espaço físico disponível em disco para Backup & Recover podem ser limitados. Por exemplo: caso seja necessário armazenar imagens físicas dos arquivos de dados em disco, o espaço em disco deverá ser reavaliado.
Um requisito técnico muito difundido é determinar o volume das transações realizadas em um banco de dados ou até mesmo em determinada aplicação. Por exemplo: as operações ininterruptas e os backups regulares aumentam a carga sobre o recurso do ambiente.
Os requisitos podem ser tratados de forma detalhada (como a citada acima) ou como sendo um aglomerado de informações que serão trabalhadas posteriormente.
Desenvolver formulários com perguntas chave pode auxiliar na identificação de pontos cruciais a serem utilizados na fase de execução do processo de backup.
A Tabela 3 propõe algumas perguntas básicas que devem ser respondidas pertinentes ao tratamento e uso das informações contidas no banco de dados, bem como identificar aspectos específicos da infra-estrutura em que ele se encontra. Essas informações fornecerão a base para o desenvolvimento da estratégia de backup de sua empresa.
Tabela 3. Perguntas a serem feitas para identificar a forma de backup utilizada para cada servidor de banco de dados.
Além das perguntas inseridas na Tabela 3, outro ponto importante a ser considerado é quais backups devem ser feitos por aplicação.
A estratégia deve abordar situações cotidianas como: a backup físico completo com grande volume de dados pode demorar a ser restaurado; já backups lógicos (estruturas de dados, organizações lógicas) ou backups parciais (de determinadas tabelas) podem ser eficientes em situações críticas de recuperação de dados.
Analise cada situação detalhadamente para criar diversas opções de restore, pensando sempre em diminuir o MTTR.
Existem outras inúmeras perguntas possíveis de utilização nessa fase que devem ser colocadas em prática sempre que venham a contribuir para alcançar uma boa estratégia de Backup & Recover.
Implementação do processo de Backup & Recover
Antes de colocar em prática o plano de Backup & Recover, é necessário que seja feito um apêndice referente aos principais tipos de backups possíveis de serem utilizados:
· Backup Consistente
o Cold Backup (offline)
· Backup Inconsistente
o Hot Backup (online)
o Backup Incremental (online)
o Backup Acumulativo (online)
O Backup Consistente permite que o banco de dados seja copiado com seus arquivos de controles sincronizados, facilitando uma possível recuperação. Um ponto negativo na utilização deste tipo de backup é que o ambiente fica indisponível (fora do ar) para que essa tarefa seja realizada, ou seja, as aplicações que fazem acesso ao banco de dados não estarão disponíveis para uso.
Pensando em termos de segurança, esse backup é o que garante a menor quantidade de falhas de recuperação dentro de um processo de restore.
Um uso muito comum desse tipo de backup ocorre quando é necessário realizar um clone do ambiente de produção para outro.
O Backup Inconsistente permite que os dados sejam copiados em modo on-line, permitindo a disponibilidade de uso das aplicações sempre que necessário. Esse tipo de backup é muito utilizado em ambiente transacional crítico e com alta taxa de transferência de dados.
O ponto positivo do uso desse tipo de backup é que existem inúmeras formas de implementação, garantindo a granularidade necessária para que os dados estejam prontos e atualizados para servirem as aplicações utilizadas. Para realizar o restore feito a partir desse tipo de backup, é necessário sincronizar os dados com os arquivos de controle, que estão disponíveis na área de segmentos de rollback e nos arquivos de logs, exemplificado na Figura 1.
Figura 1. Exemplo de um processo de recover feito sobre um backup Oracle inconsistente.
O Hot Backup é um dos mecanismos mais utilizados para realização de backup inconsistente. Ele permite o uso das aplicações de forma concorrente, realizando a cópia dos dados de acordo com a estratégia adotada. O nível de granularidade pode garantir o retorno da informação de diversas formas: cópia completa por aplicação (owner), cópia por organização lógica (tablespace, owner), cópia por tabela, entre outras.
O Backup Incremental permite que apenas os blocos de dados modificados após o último backup sejam copiados. Esse tipo de técnica é muito útil para ambientes críticos e de alta disponibilidade.
O Backup Acumulativo permite que os dados sejam copiados de forma acumulativa a partir de um backup utilizado como referência. Esse tipo de técnica é muito útil para realizar clones entre ambientes, além de garantir diversas cópias de segurança (duplicidade de dados) para a realização do procedimento de recover.
O tempo de recuperação é diretamente proporcional à quantidade de dados a ser manuseada. O tempo final de recuperação tende a aumentar nos casos onde existem muitos arquivos a serem recuperados.
Outro ponto importante a ser considerado nessa técnica é a infra-estrutura necessária para manter o ambiente disponível no menor tempo possível. Vamos citar um exemplo onde exista um banco de dados transacional de 850Gb (Gigabytes), sendo utilizado por aplicações via internet, onde o tempo máximo de recuperação estimado pela corporação é de 20 minutos após ter ocorrido a falha. A técnica de Backup & Restore a ser utilizada deverá ter uma réplica dessa base de dados em uma infra-estrutura semelhante ao ambiente original, bem como ser acrescida de espaço físico para os arquivos gerados após o último backup.
Uma técnica muito utilizada nesses casos é a cópia de blocos de dados por meio do sistema operacional, garantindo um menor tempo de recuperação (MTTR). A Figura 2 mostra um ambiente de banco de dados transacional distribuído em diversos continentes que trafegam milhares de informações diariamente.
Figura 2. Um ambiente complexo de banco de dados transacional.
A partir de agora já é possível descrever as aplicações e os tipos de backups a serem utilizados. O exemplo da Tabela 3 mostra um formulário (simples) dos tipos de backups por aplicação.
Tabela 4. Tipos de backups por aplicação.
Para que o processo alcance o sucesso desejado é necessário o envolvimento das equipes de desenvolvimento de sistemas, de suporte e da equipe que irá executar os procedimentos de backup. O resultado alcançado deve ser disponibilizado em um mural para a comunidade de usuários, para que estejam cientes e satisfeitos com a política de segurança dos dados adotada.
A Figura 3 exibe um exemplo de checklist eletrônico de backup extraído de um mural corporativo.
Figura 3. Checklist eletrônico exibido em um mural corporativo.
A execução do processo de Backup & Recover pode ser feita de forma manual (ambiente pequeno) ou eletrônico (ambientes complexos) como no exemplo acima. Pontos importantes como: tempo médio de execução de cada backup, horário de início - término de execução e observações devem ser considerados para ambientes críticos e com alta volatilidade de dados.
De posse dos tipos de backup x periodicidade x Nome do Backup (associado por servidor), sugere-se a escolha de soluções já prontas de fabricantes de banco de dados. O RMAN (Recover Manager) da Oracle atua de forma eficiente em todos os tipos de Backup & Restore descritos nesse artigo. Softwares de backup como Veritas e ArcServer garantem a transferência dos dados para as fitas, que devem ser enviadas a uma outra disposição física, fornecendo segurança adicional dos dados.
Por fim, a diminuição do MTTR é diretamente proporcional à quantidade de dados a ser recuperada e também à volatilidade dos mesmos. As políticas de backup têm que garantir os dados atualizados à necessidade do negócio da empresa, não utilizando espaço físico desnecessário (com backups obsoletos), que é um dos grandes vilões de custos na área de infra-estrutura.
Conclusão
Esse artigo descreveu as etapas iniciais para o desenvolvimento de uma política de backup & recover corporativo para que seja utilizada na medida certa, evitando desperdícios desnecessários de espaço físico e recursos do ambiente.
Os backups dos dados devem atender à estratégia de disponibilidade da aplicação e pode ser granularizado de diversas maneiras, ocorrendo pequenas redundâncias em algumas situações.
Um ponto extremamente delicado da política de backup é o desenvolvimento de um plano para testar regularmente a validade das cópias, pois uma operação de restore com sucesso somente é possível de ser realizada se o seu respectivo backup estiver disponível.
Por fim, gostaria de ressaltar que a criatividade de cada política deve ser aplicada a necessidades individuais, tendo como objetivo diminuir o tempo total de indisponibilidade do ambiente de banco de dados.
Sálvio Padlipskas (salvio@fiap.com.br) é professor titular da FIAP na área de Banco de Dados. Atua há 16 anos nas áreas de : Análise de Sistemas e Administração de Banco de Dados. É mestre pelo IPT/USP, na área de Engenharia de Software. Profissional certificado Oracle, atualmente trabalha no Grupo Ultra como DBA Oracle.
