Você faz um backup completo do ambiente todas as noites. Restaura esse backup em um ambiente de teste para conferir sua integridade. Ao meio-dia faz um backup incremental do banco. Possui segurança restritamente definida, controla os usuários no banco de dados e os programas com chave de segurança. Investiu em um servidor de contingência para ficar parado, aguardando um possível problema no servidor de produção. No servidor de produção possui RAID 0 + 1 e fonte redundante. Basicamente, você se sente seguro com o ambiente que criou.
Porém, como Murphy é implacável, o último extent do seu banco de dados estoura 2 GB as 18:00 horas do dia do fechamento. O Progress por algum motivo não consegue identificar que o extent iria estourar 2 GB e permitiu que a extensão passasse desse tamanho, corrompendo o banco de dados.
Nesse caso, seu sistema de RAID não conseguirá te ajudar, você precisará de um backup. Ao voltar o backup da noite descobre que pelo crescimento do banco de dados, o backup não copiou o banco inteiro na última noite, pois faltou espaço no dispositivo de armazenamento. Você amargamente olha para o último extent do banco com apenas 100 MBytes. Como o backup incremental é sobreposto todos os meios-dias, seu último backup válido vai te colocar na posição da madrugada do dia anterior.
Sim, é impossível prever todas as catástrofes que podem ocorrer ao ambiente. É possível apenas se cercar com recursos que evitam as ocorrências mais comuns. Uma verdade universal em banco de dados é que se protege apenas os dados que são importantes. Logo, se sua rotina de recuperação de desastres não contempla as quatro horas de trabalho desde o último backup, significa que essas 4 horas não são importantes. Infelizmente, o padrão que ainda vemos nos ambientes é de apenas um backup noturno, revelando um ambiente que fica desprotegido por 24 horas.
Dentre os recursos que protegerão seu ambiente, o After-Image é essencial. Ele mantem armazenado as notas de transações que ocorreram no banco de dados, na ordem que foram concluídas. Dessa forma, a aplicação dele sobre o backup simula exatamente as transações feitas até a alguns segundos antes do momento da corrupção.
Como não faz sentido manter o after-image no mesmo disco do banco de dados, ele demanda um disco adicional no servidor. Além disso ele possui buffers (-aibufs) que deve ser configurado adequadamente. Mantendo esses requisitos, ele não afeta a performance do ambiente de forma perceptível.
Além de requisitos físicos, o after-image também demanda configurações estruturais. O banco precisa ter ao menos uma extensão de after-image (duas se utilizar backup online), que pode ter tamanho fixado ou variável por padrão até 2 GBytes.
A partir da versão 10.1B do Progress, o after-image dispõe de ferramentas funcionais de auto-arquivamento, configuradas pelo tamanho ou pelo tempo de utilização. Essa funcionalidade quando associada a um servidor de contingência poderá facilmente criar um ambiente de replicação de dados. Também a partir dessa versão é possível habilitar o after-image com o banco ativo, com a opção enableai do probkup.
Para recuperar um banco com after-image, retorne o backup válido e aplique as diversas extensões que foram geradas desde o último backup completo, na ordem que foram criadas. Caso deseje colocar o banco em uma posição anterior ao final do after-image, é possível especificar um parâmetro de hora, minuto e segundo que especificará o momento de quebra das transações: o que foi concluído será gravado no banco, o que não foi concluído será desfeito.
Os manuais do Progress apresentam um capítulo completo de como configurar, iniciar e manipular o after-image. Através da consultoria telefônica também já configuramos ambientes com after-image. Não importa a forma com que vá implementá-lo. O importante é que o after-image esteja funcionando no ambiente.
Quanto ao exemplo acima, trata-se de uma situação real de um cliente que ajudei a configurar o after-image. Nessa situação, as extensões de after-images eram copiados para o servidor de contingência a cada backup. Retornamos o último backup válido em uma estrutura já com um novo extent de dados, e aplicamos os after-images até o final. O cliente perdeu uma hora e quinze minutos, tempo que levamos para disponibilizar o ambiente novamente. Nenhum dado foi perdido.
Assinar feeds (RSS)