O backup físico do Postgresql 9.0.8 no Windows Server 2008 R2 resulta em “Acesso negado”

2

Eu criei um script para executar um backup físico de um banco de dados Postgresql 9.0.8 seguindo a receita "Backup de banco de dados físico quente autônomo" no Cookbook de Administração do PostgreSQL 9 (Riggs / Krosing), mas o adaptei para o Windows Server 2008 R2.

Para a etapa # 4 da receita, que usa o rsync para copiar todos os arquivos de dados (excluindo o diretório pg_xlog), estou usando o robocopy.exe (já que o rsync é um utilitário * nix e estou usando o Windows). O problema é que, com freqüência, um dos arquivos não pode ser copiado e resulta em "Acesso negado". Copiar o arquivo manualmente falha com "Acesso negado" por muito tempo depois que o script de backup falhou - portanto, esse não é um problema intermitente que pode ser revogado. O arquivo pode ser copiado somente depois de reiniciar o processo do PostgreSQL. É sempre um arquivo diferente. Última noite foi% PGDATADIR% \ 5432 \ base \ 24609 \ 38122.

Gostaria de saber se você já experimentou isso e o que fez para corrigir isso. Estou pensando:

  1. Reinicie o servidor PostgreSQL antes do backup (admito que isso é um hack)
  2. Usando algum tipo de utilitário que pode copiar arquivos abertos, como VSHADOW, DISKSHADOW e hobocopy (observação: não é robocopy)
  3. Talvez haja alguma maneira de instruir o PostgreSQL a liberar todos os bloqueios?
  4. [adicionado] veja abaixo - parece que adicionar "vácuo" regular elimina o sintoma
por sevzas 22.08.2012 / 15:21

1 resposta

1

OK, as primeiras coisas primeiro - guarde o seu livro de receitas. Em vez disso, leia a seção do manual do Postgres sobre o backup . Leia o capítulo inteiro - não é assim tão longo.
(Você provavelmente notará algumas semelhanças entre este e o livro - a maioria dos livros do Postgres são apenas versões refinadas do manual - mas você deve sempre trabalhar no manual como referência principal.)

Toda a terminologia que vou usar abaixo é do manual (por isso, se você pensou que poderia pular a tarefa de leitura que não pode - se é provável que você fique terrivelmente confuso).

Agora, para o seu problema real - Uma solução Unix geralmente não é portável diretamente para o Windows, e este é um desses casos: O sistema A * nix ficará feliz pegando um arquivo que está sendo manipulado - o Windows gera o erro vendo.

Como você lida com isso depende do tipo de backup que você está fazendo.

Backups em nível de arquivosystyem

Se você estiver fazendo um "backup em nível de sistema de arquivos" , deve fechar o servidor. Ponto final, fim de discussão, sem outras opções. O banco de dados deve ser desligado completamente para que esse tipo de backup seja confiável (e se o backup que você está obtendo não for confiável).

Arquivamento contínuo / Recuperação point-in-time & Servidores escravos

Se você estiver fazendo um backup de base como parte da configuração da Recuperação point-in-time & envio de log você tem duas opções:

  • Encerre o servidor mesmo assim.
  • Use uma ferramenta que possa copiar arquivos abertos (opção (2) da sua pergunta)

Em seguida, você prossegue de acordo com o restante da documentação para recuperação pontual / remessa de log, criando um servidor slave.
Quando você quiser copiar seu servidor de banco de dados para o disco, simplesmente pare o escravo, faça o backup e reinicie-o - o mundo continua ligando seu servidor mestre, e o escravo vai ficar sabendo o que perdeu quando reiniciar.

You can also use the base backup plus the rolled transaction logs that you would normally ship to the slave as a good reliable database backup. This would seem to be the closest thing to what you're trying to achieve in your question, but I would recommend the slave backup I described instead -- More benefits (you have a hot standby) and less work for the master server (no extra checkpointing to roll the backup's transaction log).

Algo mais

Se nenhuma das opções acima lhe agradar, você está praticamente preso usando SQL Dumps .
Existem desvantagens: o Postgres tem que bloquear cada tabela à medida que ela é descartada (o que significa que as gravações no banco de dados serão bloqueadas) e os dumps do SQL são mais lentos do que as outras opções. Se o seu banco de dados for de tamanho real, eu não aconselharia este método.

    
por 22.08.2012 / 17:51