O OpenEdge, assim como outros bancos de dados de mercado, permite a realização de backups online. A vantagem mais aparente deste método é a criação de cópias de segurança com o banco de dados em operação, enquanto as aplicações continuam disponíveis e os usuários trabalham normalmente. Outra vantagem não tão óbvia é que mantendo o banco de dados ativo, todas as estruturas e buffers de memória continuam ativas, evitando degradação de desempenho associado a parar e iniciar novamente o banco de dados.
A maior dificuldade em realizar um backup online é conseguir uma cópia consistente do banco de dados. Quando o banco de dados está parado (backup offline) está é uma tarefa simples: basta copiar os arquivos do banco (dados e BI). Quando o backup é restaurado, o crash-recovery processa as notas de transações pendentes no BI e o banco de dados está consistente. Não há preocupação de que os arquivos de dados sejam alterados durante a cópia, pois ninguém está acessando o banco.
Quando o banco de dados está ativo e processando transações (backup online) há um complicador adicional: uma parte dos dados está atualizada somente em memória e a imagem dos dados no disco é antiga. Além disto, o processo de backup pode demorar vários minutos ou horas. Durante o backup, alguma transação pode alterar vários blocos diferentes do banco, que podem ser gravados para o disco em diferentes momentos. Estes blocos podem ser de dados, índices ou blocos internos de controle e alocação de espaço do banco de dados. Um processo de cópia simples não conseguiria obter uma imagem consistente do banco de dados (todos os blocos no mesmo instante no tempo), e esta cópia apresentaria corrupção lógica e possivelmente corrupção física.
O OpenEdge provê a opção de realizar backups online consistentes através da ferramenta probkup. O probkup possui outras vantagens além da opção de backup online. Para obter uma cópia consistente do banco de dados o probkup executa os seguintes passos:
- adquire um latch, congelando toda a atividade de BI. Este passo efetivamente congela o banco de dados;
- grava em disco os buffers de dados e buffers de BI alterados. Este passo é importante para sincronizar o conteúdo da memória com a imagem em disco do banco de dados. Se os processos APW, BIW a AIW estiverem executando, haverá menos buffers alterados necessitando gravação;
- efetua uma troca (switch) das extensões de AI (after-image), exceto quando o AI não está habilitado para o banco;
- efetua cópia da porção ativa do BI. Depois que o BI foi copiado, a atividade de BI pode continuar;
- libera o latch adquirido no passo 1, descongelando o banco de dados e permitindo que alterações sejam realizadas;
- efetua cópia dos blocos dos arquivos de dados. Se o backup é incremental, apenas os blocos modificados desde o último backup completo ou incremental são copiados.
Apesar de o probkup congelar o banco de dados por algum tempo para sincronização e cópia do BI, o banco está disponível para consultas e alterações durante a cópia dos dados. O tempo para cópia do BI normalmente é pequeno se comparado ao tempo necessário para copiar todos os blocos de dados.
Durante a execução do backup, os blocos que ainda não foram copiados e precisam ser alterados são copiados para o backup antes da alteração ser aplicada ao bloco. Depois da cópia o bloco é alterado. Desta forma, o probkup garante uma cópia de todos os blocos com os mesmos dados que existiam no momento que o backup iniciou. As transações que iniciaram depois que o backup começou a executar não são refletidas no backup. As transações que estavam em andamento quando o backup começou a executar serão abortadas (rollback) na restauração do backup.
Efetivamente, o probkup gera uma imagem consistente de todas as transações confirmadas (commit) até momento do início do probkup. Isto significa que ao final de um backup que demorou 4 horas, os dados são de 4 horas atrás (horário de início do backup). Este é um dos motivos pelo qual é necessário complementar o backup utilizando o after-image.