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

Question

Eu construí um script para realizar um backup físico de um banco de dados Postgresql 9.0.8 seguindo a receita "Backup de banco de dados físico autónomo" no PostgreSQL 9 Administration Cookbook (Riggs/Krosing), mas adaptei-o 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 muitas vezes um dos arquivos não pode ser copiado e resulta em “Acesso negado”. A cópia manual do arquivo falha com "Acesso negado"longoapós a falha do script de backup - portanto, este não é um problema intermitente que pode ser tentado novamente. O arquivo só pode ser copiado após reiniciar o processo PostgreSQL. É sempre um arquivo diferente. Na noite passada foi %PGDATADIR%\5432\base\24609\38122 .

Gostaria de saber se você já passou por isso e o que fez para corrigir isso. Estou considerando:

1. Reinicie o servidor PostgreSQL logo 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 (nota: não robocopy)
3. Talvez haja alguma maneira de instruir o PostgreSQL a liberar todos os bloqueios?
4. [adicionado] veja abaixo - parece que adicionar "aspiração" regular elimina o sintoma

Answer 1

OK, comecemos pelo princípio: guarde o seu livro de receitas. Em vez disso, vá lera seção do manual do Postgres sobre backup. Leia o capítulo inteiro – não é 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 aprimoradas do manual - mas você deve sempre trabalhar a partir do manual como sua referência principal.).

Toda a terminologia que usarei abaixo vem do manual (então, se você pensou que poderia pular a tarefa de leitura, não pode - se o fizer, provavelmente ficará terrivelmente confuso).

---

Agora, para o seu problema real - uma solução Unix geralmente não é diretamente portável para o Windows, e este é um desses casos: um sistema *nix terá prazer em capturar um arquivo que está sendo manipulado - o Windows gera o erro que você está vendo.

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

Backups em nível de sistema de arquivos

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

Arquivamento contínuo/recuperação pontual e servidores escravos

Se você está fazendo umbackup básicocomo parte da configuraçãoRecuperação pontual& envio de log você tem duas opções:

• Desligue o servidor de qualquer maneira.
• 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/envio de log, criando um servidor escravo.
Quando você quiser copiar seu servidor de banco de dados para o disco, simplesmente pare o escravo, faça backup dele e reinicie-o - o mundo continua girando em seu servidor mestre, e o escravo recuperará o que perdeu quando for reiniciado.

Você também pode usar o backup base mais os logs de transações rolados que você normalmente enviaria ao escravo como um backup de banco de dados confiável. Isso parece ser o mais próximo do que você está tentando alcançar em sua pergunta, mas eu recomendaria o backup escravo que descrevi - Mais benefícios (você tem uma espera ativa) e menos trabalho para o servidor mestre (não pontos de verificação extras para rolar o log de transações do backup).

Algo mais

Se nenhuma das opções acima lhe agrada, você está praticamente preso ao usoDespejos SQL.
Existem desvantagens: o Postgres precisa bloquear cada tabela à medida que ela é despejada (o que significa que as gravações em seu banco de dados serão bloqueadas) e os despejos SQL são mais lentos que as outras opções.
Se o seu banco de dados tiver algum tamanho real, eu não recomendaria esse método.