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.