Você possui o ambiente estável que descrevi no artigo sobre after-image. Porém você está preocupado (e com razão) com o tempo de recovery caso ocorra algum desastre com o servidor. Talvez você ainda não tenha sido apresentado ao "servidor redundante", ou "servidor de contingência", que o artigo comenta, mas vamos discutí-lo agora.
A questão fundamental que une o tempo de recovery ao servidor redundante é: de quanto tempo você precisa para comprar um novo hardware, instalá-lo e disponibilizá-lo para os usuários? Isso é inviável. Um servidor redundante serve para ser disponibilizado aos usuários assim que o servidor de produção parar.
Muito bem, então agora você tem um servidor parado que dificilmente conseguirá justificar para o diretor financeiro. Então vamos botá-lo para trabalhar.
O primeiro passo é copiar os arquivos .st dos bancos utilizados para o novo servidor e adequá-los à nova estrutura de diretórios. Lembre-se de configurá-los para somente leitura para eles nunca serem substituídos. Comece a restaurar o backup diário nesse servidor. Dessa forma, além de testar o backup (sim, é necessário testar os backups) você eliminará esse tempo para a recuperação de desastre.
Agora, em caso de desastre, você tira o HD do after-image do servidor quebrado e coloca-o no seu servidor de contingência. Espero que não tenha economizado ao investir em HDs hot-swap, ou passará alguns minutos apertando parafusos e seu estagiário andará pela empresa inteira para achar uma chave philips. Com o HD instalado, aplica-se o after-image sobre o banco já restaurado do backup e voilà, seu ambiente está no ar.
O after-image armazena as transações efetuadas no banco de dados e não blocos como o before-image. Nessa característica, se seu ambiente for muito utilizado (na casa de milhões de transações por hora), facilmente um arquivo de after-image chegará a 1 GByte.
O tamanho do after-image é diretamente proporcional ao tempo que demandará o seu recovery. Por isso, é recomendável "quebrar" o after-image em vários arquivos (a cada hora ou meia-hora, por exemplo) copiá-los e aplicá-los sequencialmente no banco de dados que foi restaurado no servidor redundante. Dessa forma, após o crash do servidor de produção será necessário aplicar apenas o último arquivo de after-image no banco de dados no servidor redundante, reduzindo significativamente o tempo de recovery.
Essa quebra dos arquivos de after-image pode ser feita manualmente (aimage new) ou através de um utilitário disponível a partir do Progress 10.1A, chamado AI Archiver. Esse utilitário programa o banco de dados para quebrar automaticamente os arquivos de after-image e copiá-los para um destino qualquer. Isso economiza alguns comandos nos seus scripts.
Além de toda essa programação, é preciso ressaltar que o Progress demanda uma licença para o servidor redundante, afinal de contas, você estará executando comandos Progress nele. Com uma licença de banco você poderá inclusive serví-lo em modo somente leitura para executar consultas nessa base, liberando recursos do servidor de produção. A recomendação da Progress é uma licença Replication Target, porém acredito que o seu vendedor poderá esclarecer melhor que eu as possibilidades de licenciamento.
Assinar feeds (RSS)