22.3. Cópia de segurança em-linha

22.3.1. Cópia dos arquivos de segmento do WAL

Em um sentido abstrato, a execução do sistema PostgreSQL produz uma seqüência indefinidamente longa de entradas no WAL. O sistema divide fisicamente esta seqüência em arquivos de segmento do WAL, normalmente com 16 MB cada (embora o tamanho possa ser alterado durante a construção do PostgreSQL). São atribuídos nomes numéricos aos arquivos de segmento para refletir sua posição na seqüência abstrata do WAL. Quando não é feita cópia dos arquivos de segmento do WAL, normalmente o sistema cria apenas uns poucos arquivos de segmento e, depois, "recicla-os" renomeando os arquivos que não são mais de interesse com número de segmento mais alto. Assume-se não existir mais interesse em um arquivo de segmento cujo conteúdo preceda o ponto de verificação anterior ao último, podendo, portanto, ser reciclado.

Quando é feita a cópia dos arquivos de segmento do WAL, deseja-se capturar o conteúdo de cada arquivo quando este é completado, guardando os dados em algum lugar antes do arquivo de segmento ser reciclado para ser reutilizado. Dependendo da aplicação e dos periféricos disponíveis, podem haver muitas maneiras de "guardar os dados em algum lugar": os arquivos de segmento podem ser copiados para outra máquina usando um diretório NFS montado, podem ser escritos em uma unidade de fita (havendo garantia que os arquivos poderão ser restaurados com seus nomes originais), podem ser agrupados e gravados em CD, ou de alguma outra forma. Para que o administrador de banco de dados tenha a máxima flexibilidade possível, o PostgreSQL tenta não assumir nada sobre como as cópias serão feitas. Em vez disso, o PostgreSQL deixa o administrador escolher o comando a ser executado para copiar o arquivo de segmento completado para o local de destino. O comando pode ser tão simples como cp, ou pode envolver um script complexo para o interpretador de comandos — tudo depende do administrador.

O comando a ser executado é especificado através do parâmetro de configuração archive_command, que na prática é sempre colocado no arquivo postgresql.conf. Na cadeia de caracteres do comando, todo %p é substituído pelo caminho absoluto do arquivo a ser copiado, enquanto todo %f é substituído pelo nome do arquivo apenas. Se for necessário incorporar o caractere % ao comando, deve ser escrito %%. A forma mais simples de um comando útil é algo como

archive_command = 'cp -i %p /mnt/servidor/dir_copias/%f </dev/null'

que irá copiar os arquivos de segmento do WAL, prontos para serem copiados, para o diretório /mnt/servidor/dir_copias (Isto é um exemplo, e não uma recomendação, e pode não funcionar em todas as plataformas).

O comando para realizar a cópia é executado sob a propriedade do mesmo usuário que está executando o servidor PostgreSQL. Como a série de arquivos do WAL contém efetivamente tudo que está no banco de dados, deve haver certeza que a cópia está protegida contra olhos curiosos; por exemplo, colocando a cópia em diretório sem acesso para grupo ou para todos.

É importante que o comando para realizar a cópia retorne o status de saída zero se, e somente se, for bem-sucedido. Ao receber o resultado zero, o PostgreSQL assume que a cópia do arquivo de segmento do WAL foi bem-sucedida, e remove ou recicla o arquivo de segmento. Entretanto, um status diferente de zero informa ao PostgreSQL que o arquivo não foi copiado; serão feitas tentativas periódicas até ser bem-sucedida.

Geralmente o comando de cópia deve ser projetado de tal forma que não sobrescreva algum arquivo de cópia pré-existente. Esta é uma característica de segurança importante para preservar a integridade da cópia no caso de um erro do administrador (tal como enviar a saída de dois servidores diferentes para o mesmo diretório de cópias). Aconselha-se a testar o comando de cópia proposto para ter certeza que não sobrescreve um arquivo existente, e que retorna um status diferente de zero neste caso. Tem sido observado que cp -i faz isto corretamente em algumas plataformas, mas não em outras. Se o comando escolhido não tratar este caso corretamente por conta própria, deve ser adicionado um comando para testar a existência do arquivo de cópia. Por exemplo, algo como

archive_command = 'test ! -f .../%f && cp %p .../%f'

funciona corretamente na maioria das variantes do Unix.

Ao projetar a configuração de cópia deve ser considerado o que vai acontecer quando o comando de cópia falhar repetidas vezes, seja porque alguma funcionalidade requer intervenção do operador, ou porque não há espaço para armazenar a cópia. Esta situação pode ocorrer, por exemplo, quando a cópia é escrita em fita e não há um sistema automático para troca de fitas: quando a fita ficar cheia, não será possível fazer outras cópias enquanto a fita não for trocada. Deve-se garantir que qualquer condição de erro, ou solicitação feita a um operador humano, seja relatada de forma apropriada para que a situação possa ser resolvida o mais rápido possível. Enquanto a situação não for resolvida, continuarão sendo criados novos arquivos de segmento do WAL no diretório pg_xlog.

A velocidade do comando de cópia não é importante, desde que possa acompanhar a taxa média de geração de dados para o WAL. A operação normal prossegue mesmo que o processo de cópia fique um pouco atrasado. Se o processo de cópia ficar muito atrasado, vai aumentar a quantidade de dados perdidos caso ocorra um desastre. Significa, também, que o diretório pg_xlog vai conter um número grande de arquivos de segmento que ainda não foram copiados, podendo, inclusive, exceder o espaço livre em disco. Aconselha-se que o processo de cópia seja monitorado para garantir que esteja funcionando da forma planejada.

Havendo preocupação em se poder recuperar até o presente instante, devem ser efetuados passos adicionais para garantir que o arquivo de segmento do WAL corrente, parcialmente preenchido, também seja copiado para algum lugar. Isto é particularmente importante no caso do servidor gerar pouco tráfego para o WAL (ou tiver períodos ociosos onde isto acontece), uma vez que pode levar muito tempo até que o arquivo de segmento fique totalmente preenchido e pronto para ser copiado. Uma forma possível de tratar esta situação é definir uma entrada no cron [1] que periodicamente, talvez uma vez por minuto, identifique o arquivo de segmento do WAL corrente e o guarde em algum lugar seguro. Então, a combinação dos arquivos de segmento do WAL guardados, com o arquivo de segmento do WAL corrente guardado, será suficiente para garantir que o banco de dados pode ser restaurado até um minuto, ou menos, antes do presente instante. Atualmente este comportamento não está presente no PostgreSQL, porque não se deseja complicar a definição de archive_command requerendo que este acompanhe cópias bem-sucedidas, mas diferentes, do mesmo arquivo do WAL. O archive_command é chamado apenas para segmentos do WAL completados. Exceto no caso de novas tentativas devido a falha, só é chamado uma vez para um determinado nome de arquivo.

Ao escrever o comando de cópia, deve ser assumido que os nomes dos arquivos a serem copiados podem ter comprimento de até 64 caracteres, e que podem conter qualquer combinação de letras ASCII, dígitos e pontos. Não é necessário recordar o caminho original completo (%p), mas é necessário recordar o nome do arquivo (%f).

Deve ser lembrado que embora a cópia do WAL permita restaurar toda modificação feita nos dados dos bancos de dados do PostgreSQL, não restaura a alterações feitas nos arquivos de configuração (ou seja, nos arquivos postgresql.conf, pg_hba.conf e pg_ident.conf), uma vez que estes arquivos são editados manualmente, em vez de através de operações SQL. Aconselha-se a manter os arquivos de configuração em um local onde são feitas cópias de segurança regulares do sistema de arquivos. Para mudar os arquivos de configuração de lugar, deve ser consultada a Seção 16.4.1.

22.3.2. Criação da cópia de segurança base

O procedimento para fazer a cópia de segurança base é relativamente simples:

1. Garantir que a cópia dos arquivos de segmento do WAL esteja ativada e funcionando.

2. Conectar ao banco de dados como um superusuário e executar o comando

   SELECT pg_start_backup('rótulo');
   

   onde rótulo é qualquer cadeia de caracteres que se deseje usar para identificar unicamente esta operação de cópia de segurança (Uma boa prática é utilizar o caminho completo de onde se deseja colocar o arquivo de cópia de segurança). A função pg_start_backup cria o arquivo rótulo da cópia de segurança, chamado backup_label, com informações sobre a cópia de segurança, no diretório do agrupamento.

   Para executar este comando, não importa qual banco de dados do agrupamento é usado para fazer a conexão. O resultado retornado pela função pode ser ignorado; mas se for relatado um erro, este deve ser tratado antes de prosseguir.

3. Realizar a cópia de segurança utilizando qualquer ferramenta conveniente para cópia de segurança do sistema de arquivos, como tar ou cpio. Não é necessário, nem desejado, parar a operação normal do banco de dados enquanto a cópia é feita.

4. Conectar novamente ao banco de dados como um superusuário e executar o comando:

   SELECT pg_stop_backup();
   

   Se a execução for bem sucedida, está terminado.

Não é necessário ficar muito preocupado com o tempo decorrido entre a execução de pg_start_backup e o início da realização da cópia de segurança, nem entre o fim da realização da cópia de segurança e a execução de pg_stop_backup; uns poucos minutos de atraso não vão criar nenhum problema. Entretanto, deve haver certeza que as operações são realizadas seqüencialmente, sem que haja sobreposição.

Deve haver certeza que a cópia de segurança inclui todos os arquivos sob o diretório do agrupamento de bancos de dados (por exemplo, /usr/local/pgsql/data). Se estiverem sendo utilizados espaços de tabelas que não residem sob este diretório, deve-se ter o cuidado de inclui-los também (e ter certeza que a cópia de segurança guarda vínculos simbólicos como vínculos, senão a restauração vai danificar os espaços de tabelas).

Entretanto, podem ser omitidos da cópia de segurança os arquivos sob o subdiretório pg_xlog do diretório do agrupamento. Esta pequena complicação a mais vale a pena ser feita porque reduz o risco de erros na restauração. É fácil de ser feito se pg_xlog for um vínculo simbólico apontando para algum lugar fora do agrupamento, o que é uma configuração comum por razões de desempenho.

Para poder utilizar esta cópia de segurança base, devem ser mantidas por perto todas as cópias dos arquivos de segmento do WAL gerados no momento ou após o início da mesma. Para ajudar a realizar esta tarefa, a função pg_stop_backup cria o arquivo de histórico de cópia de segurança, que é armazenado imediatamente na área de cópia do WAL. Este arquivo recebe um nome derivado do primeiro arquivo de segmento do WAL, que é necessário possuir para fazer uso da cópia de segurança. Por exemplo, se o arquivo do WAL tiver o nome 0000000100001234000055CD, o arquivo de histórico de cópia de segurança vai ter um nome parecido com 0000000100001234000055CD.007C9330.backup (A segunda parte do nome do arquivo representa a posição exata dentro do arquivo do WAL, podendo normalmente ser ignorada). Uma vez que o arquivo contendo a cópia de segurança base tenha sido guardado em local seguro, podem ser apagados todos os arquivos de segmento do WAL com nomes numericamente precedentes a este número. O arquivo de histórico de cópia de segurança é apenas um pequeno arquivo texto. Contém a cadeia de caracteres rótulo fornecida à função pg_start_backup, assim como as horas de início e fim da cópia de segurança. Se o rótulo for utilizado para identificar onde está armazenada a cópia de segurança base do banco de dados, então basta o arquivo de histórico de cópia de segurança para se saber qual é o arquivo de cópia de segurança a ser restaurado, no caso disto precisar ser feito.

Uma vez que é necessário manter por perto todos os arquivos de segmento do WAL copiados desde a última cópia de segurança base, o intervalo entre estas cópias de segurança geralmente deve ser escolhido tendo por base quanto armazenamento se deseja consumir para os arquivos do WAL guardados. Também deve ser considerado quanto tempo se está preparado para despender com a restauração, no caso de ser necessário fazer uma restauração — o sistema terá que refazer todos os segmentos do WAL, o que pode ser muito demorado se tiver sido decorrido muito tempo desde a última cópia de segurança base.

Também vale a pena notar que a função pg_start_backup cria no diretório do agrupamento de bancos de dados um arquivo chamado backup_label, que depois é removido pela função pg_stop_backup. Este arquivo fica guardado como parte do arquivo de cópia de segurança base. O arquivo rótulo de cópia de segurança inclui a cadeia de caracteres rótulo fornecida para a função pg_start_backup, assim como a hora em que pg_start_backup foi executada, e o nome do arquivo de segmento inicial do WAL. Em caso de dúvida, é possível olhar dentro do arquivo de cópia de segurança base e determinar com exatidão de qual sessão de cópia de segurança este arquivo provém.

Também é possível fazer a cópia de segurança base enquanto o postmaster está parado. Neste caso, obviamente não podem ser utilizadas as funções pg_start_backup e pg_stop_backup, sendo responsabilidade do administrador controlar a que cópia de segurança cada arquivo pertence, e até quanto tempo atrás os arquivos de segmento do WAL associados vão. Geralmente é melhor seguir os procedimentos para cópia de segurança mostrados acima.

22.3.3. Recuperação a partir de cópia de segurança em-linha

Certo, aconteceu o pior e é necessário recuperar a partir da cópia de segurança. O procedimento está mostrado abaixo:

1. Parar o postmaster, se estiver executando.

2. Havendo espaço para isso, copiar todo o diretório de dados do agrupamento, e todos os espaços de tabelas, para um lugar temporário, para o caso de necessidade. Deve ser observado que esta medida de precaução requer a existência de espaço no sistema suficiente para manter duas cópias do banco de dados existente. Se não houver espaço suficiente, é necessário pelo menos uma cópia do conteúdo do subdiretório pg_xlog do diretório de dados do agrupamento, porque pode conter arquivos de segmento do WAL que não foram copiados quando o sistema parou.

3. Apagar todos os arquivos e subdiretórios existentes sob o diretório de dados do agrupamento, e sob os diretórios raiz dos espaços de tabelas em uso.

4. Restaurar os arquivos do banco de dados a partir da cópia de segurança base. Deve-se tomar cuidado para que sejam restaurados com o dono correto (o usuário do sistema de banco de dados, e não o usuário root), e com as permissões corretas. Se estiverem sendo utilizados espaços de tabelas, deve ser verificado se foram restaurados corretamente os vínculos simbólicos no subdiretório pg_tblspc/.

5. Remover todos os arquivos presentes no subdiretório pg_xlog; porque estes vêm da cópia de segurança base e, portanto, provavelmente estão obsoletos. Se o subdiretório pg_xlog não fizer parte da cópia de segurança base, então este subdiretório deve ser criado, assim como o subdiretório pg_xlog/archive_status.

6. Se existirem arquivos de segmento do WAL que não foram copiados para o diretório de cópias, mas que foram salvos no passo 2, estes devem ser copiados para o diretório pg_xlog; é melhor copiá-los em vez de movê-los, para que ainda existam arquivos não modificados caso ocorra algum problema e o processo tenha de ser recomeçado.

7. Criar o arquivo de comando de recuperação recovery.conf no diretório de dados do agrupamento (consulte Recovery Settings). Também pode ser útil modificar temporariamente o arquivo pg_hba.conf, para impedir que os usuários comuns se conectem até que se tenha certeza que a recuperação foi bem-sucedida.

8. Iniciar o postmaster. O postmaster vai entrar no modo de recuperação e prosseguir lendo os arquivos do WAL necessários. Após o término do processo de recuperação, o postmaster muda o nome do arquivo recovery.conf para recovery.done (para impedir que entre novamente no modo de recuperação no caso de uma queda posterior), e depois começa as operações normais de banco de dados.

9. Deve ser feita a inspeção do conteúdo do banco de dados para garantir que a recuperação foi feita até onde deveria ser feita. Caso contrário, deve-se retornar ao passo 1. Se tudo correu bem, liberar o acesso aos usuários retornando pg_hba.conf à sua condição normal.

A parte chave de todo este procedimento é a definição do arquivo contendo o comando de recuperação, que descreve como se deseja fazer a recuperação, e até onde a recuperação deve ir. Pode ser utilizado o arquivo recovery.conf.sample (geralmente presente no diretório de instalação share) na forma de um protótipo [2]. O único parâmetro requerido no arquivo recovery.conf é restore_command, que informa ao PostgreSQL como trazer de volta os arquivos de segmento do WAL copiados. Como no archive_command, este parâmetro é uma cadeia de caracteres para o interpretador de comandos. Pode conter %f, que é substituído pelo nome do arquivo do WAL a ser trazido de volta, e %p, que é substituído pelo caminho absoluto para onde o arquivo do WAL será copiado. Se for necessário incorporar o caractere % ao comando, deve ser escrito %%. A forma mais simples de um comando útil é algo como

restore_command = 'cp /mnt/servidor/dir_copias/%f %p'

que irá copiar os arquivos de segmento do WAL previamente guardados a partir do diretório /mnt/servidor/dir_copias. É claro que pode ser utilizado algo muito mais complicado, talvez um script que solicite ao operador a montagem da fita apropriada.

É importante que o comando retorne um status de saída diferente de zero em caso de falha. Será solicitado ao comando os arquivos do WAL cujos nomes não estejam presente entre as cópias; deve retornar um status diferente de zero quando for feita a solicitação. Esta não é uma condição de erro. Deve-se tomar cuidado para que o nome base do caminho %p seja diferente de %f; não deve ser esperado que sejam intercambiáveis.

Os arquivos de segmento do WAL que não puderem ser encontrados entre as cópias, serão procurados no diretório pg_xlog/; isto permite que os arquivos de segmento recentes, ainda não copiados, sejam utilizados. Entretanto, os arquivos de segmento que estiverem entre as cópias terão preferência sobre os arquivos em pg_xlog. O sistema não sobrescreve os arquivos presentes em pg_xlog quando busca os arquivos guardados.

Normalmente a recuperação prossegue através de todos os arquivos de segmento do WAL, portanto restaurando o banco de dados até o presente momento (ou tão próximo quanto se pode chegar utilizando os segmentos do WAL). Mas se for necessário recuperar até algum ponto anterior no tempo (digamos, logo antes do DBA júnior ter apagado a tabela principal de transação de alguém), deve-se simplesmente especificar no arquivo recovery.conf o ponto de parada requerido. O ponto de parada, conhecido como "destino da recuperação", pode ser especificado tanto pela data e hora quanto pelo término de um ID de transação específico. Até o momento em que este manual foi escrito, somente podia ser utilizada a opção data e hora, pela falta de ferramenta para ajudar a descobrir com precisão o identificador de transação a ser utilizado.

22.3.4. Cronologias

A capacidade de restaurar um banco de dados para um determinado ponto anterior no tempo cria algumas complexidades que são semelhantes às das narrativas de ficção científica sobre viagem no tempo e universos paralelos. Por exemplo, na história original do banco de dados talvez tenha sido removida uma tabela importante às 5:15 da tarde de terça-feira. Imperturbável, o administrador pega a cópia de segurança e faz uma restauração para o ponto no tempo 5:14 da tarde de terça feira, e o sistema volta a funcionar. Nesta história do universo do banco de dados, a tabela nunca foi removida. Mas suponha que mais tarde seja descoberto que esta não foi uma boa idéia, e que se deseja voltar para algum ponto posterior da história original. Mas isto não poderá ser feito, porque quando o banco de dados foi posto em atividade este sobrescreveu alguns dos arquivos de segmento do WAL que levariam ao ponto no tempo onde agora quer se chegar. Portanto, realmente é necessário fazer distinção entre a série de entradas no WAL geradas após a recuperação para um ponto no tempo, e àquelas geradas durante a história original do banco de dados.

Para lidar com estes problemas, o PostgreSQL possui a noção de cronologias (timelines). Cada vez que é feita uma recuperação no tempo anterior ao fim da seqüência do WAL, é criada uma nova cronologia para identificar a série de registros do WAL geradas após a recuperação (entretanto, se a recuperação prosseguir até o final do WAL, não é criada uma nova cronologia: apenas se estende a cronologia existente). O número identificador da cronologia é parte dos nomes dos arquivos de segmento do WAL e, portanto, uma nova cronologia não sobrescreve os dados do WAL gerados pelas cronologias anteriores. É possível, na verdade, guardar muitas cronologias diferentes. Embora possa parecer uma funcionalidade sem utilidade, muitas vezes é de grande valia. Considere a situação onde não se tem certeza absoluta de até que ponto no tempo deve ser feita a recuperação e, portanto, devem ser feitas muitas tentativas de recuperação até ser encontrado o melhor lugar para se desviar da história antiga. Sem as cronologias este processo em pouco tempo cria uma confusão impossível de ser gerenciada. Com as cronologias, pode ser feita a recuperação até qualquer estado anterior, inclusive os estados no desvio de cronologia abandonados posteriormente.

Toda vez que é criada uma nova cronologia, o PostgreSQL cria um arquivo de "história da cronologia" que mostra de que cronologia foi feito o desvio, e quando. Os arquivos de cronologia são necessários para permitir o sistema buscar os arquivos de segmento do WAL corretos ao fazer a recuperação a partir de uma área de cópias que contém várias cronologias. Portanto, estes arquivos são guardados na área de cópias como qualquer arquivo de segmento do WAL. Os arquivos de cronologia são apenas pequenos arquivos texto sendo, portanto, barato e apropriado mantê-los guardados indefinidamente (ao contrário dos arquivos de segmento que são grandes). É possível, caso se deseje fazê-lo, adicionar comentários aos arquivos de cronologia para fazer anotações personalizadas sobre como e porque foi criada uma determinada cronologia. Estes comentários são muito úteis quando há um grande número de cronologias criadas como resultado de experiências.

O comportamento padrão de recuperação é recuperar ao longo da cronologia que era a cronologia corrente quando foi feita a cópia de segurança base. Se for desejado fazer a recuperação utilizando uma cronologia filha (ou seja, deseja-se retornar para algum estado que foi gerado após uma tentativa de recuperação), é necessário especificar o identificador da cronologia de destino no arquivo recovery.conf. Não é possível fazer a recuperação para um estado que foi um desvio anterior à cópia de segurança base.

22.3.5. Cuidado

No momento em que esta documentação foi escrita, haviam várias limitações para o método de cópia de segurança em-linha, que provavelmente serão corrigidas nas versões futuras:

• Atualmente não são gravadas no WAL as operações em índices que não são B-tree (índices hash, R-tree e GiST), portanto quando o WAL é refeito os índices destes tipos não são atualizados. A prática recomendada para contornar este problema é reindexar manualmente todos os índices destes tipos após o término da operação de recuperação.

Também deve ser notado que o formato atual do WAL é muito volumoso, uma vez que inclui muitos instantâneos de páginas de disco. Isto é apropriado para a finalidade de recuperação de quedas, uma vez que pode ser necessário corrigir páginas de disco parcialmente preenchidas. Entretanto, não é necessário armazenar tantas cópias de páginas para operações de recuperação para um determinado ponto no tempo. Uma área para desenvolvimento futuro é a compressão dos dados do WAL copiados, pela remoção das cópias de página desnecessárias.