Backup automático do PostgreSQL

Question

Eu tenho tentado configurar um script de backup em um servidor Windows. Eu usei pgAgent (agendamento para pgAdmin), para executar o script de backup. Nenhum problema com o script de backup.

No entanto, meus trabalhos não estão funcionando como deveriam. Eu defini o horário e os passos.

Estou bastante certo de que estou executando o serviço com um usuário ou usuário incorreto sem as permissões necessárias.

Eu executo o serviço da seguinte forma: "C:\Program Files\pgAdmin III\pgAgent" INSTALL pgAgent -u postgres -p secret hostaddr=127.0.0.1 dbname=pgadmin user=postgres

E recebo um erro dizendo que houve um erro nas informações de login, embora eu saiba que está correto. Quando entro em serviços (controlpanel - > administration - > services), consigo iniciar o serviço com o usuário local.

Este pode ser o problema?

Onde posso ver ou alterar as permissões no usuário postgres?

    

Answer 1

O PostgreSQL fornece a você todas as ferramentas necessárias para fazer o backup em sua instalação base. Foi o que fiz há algumas semanas para configurar o backup de backups a quente de instâncias do PostgreSQL hospedadas em um host do Windows:

1. Crie um usuário especificamente para backups, vamos chamá-lo de 'backups'. Você pode usar o comando createuser da sua instalação do PostgreSQL.

2. Dê ao usuário uma senha e leia o acesso a tudo. Isso pode ficar um pouco complexo. Alternativamente, você também pode torná-lo um superusuário do PostgreSQL e impor restrições de login como mencionado abaixo.

3. Permitem que ele faça login a partir do host local usando apenas uma senha (mecanismo 'md5'), ou se você é um usuário do jogo na sua máquina do MS Windows e usa o mecanismo 'ident'. Você precisará modificar o arquivo pg_hba.conf para impor um desses comportamentos e a restrição para efetuar login somente a partir do host local.

4. Crie um script para usar pg_dumpall para fazer backup do banco de dados. O script pode ser chamado por meio de uma configuração de tarefa no Agendador de Tarefas ou por meio de um agendador de backup, como o Bacula. Se você optar por autenticar usando uma senha, poderá especificar que, como uma variável de ambiente, pg_dumpall lerá ou especificará um arquivo contendo a senha usando uma variável de ambiente diferente.

Detalhes deste método podem ser encontrados no link .

Não sei por que você está usando o pgAdmin para backups automatizados do PostgreSQL. Eu adoraria ouvir suas razões considerando que o PostgreSQL tem uma maneira de fazer isso sem ferramentas externas e tem um documento bem escrito sobre o assunto.

    

Answer 2

Eu configurei o pgAdmin dessa maneira

pgagent.exe INSTALL pgAgent -u postgres -p secret host=localhost dbname=pgadmin user=postgres

Então você precisa configurar o arquivo pgpass.conf no diretório de usuários do postgres, no winxp isso está em Application Data / postgres / pgpass.conf e no win7 deve ser appdata / local / postgres / pgpass.conf (não 100 % de certeza)

É definido aqui link

hostname:port:database:username:password

isso permite que o pgAgent acesse o servidor postgreSQL, haveria um pgpass criado para seu usuário quando você lembrou a senha do pgAdmin.

Sem este pgpass pgAgent não pode acessar o banco de dados.

    

Answer 3

O Postgres é muito flexível - há mais de uma maneira de obter um backup bom e utilizável (e muitos dos melhores não exigem que você use o pgAgent - você pode fazer o script deles com ferramentas comuns do SO).

nearora já descrita usando pg_dumpall , que pode ser viável para você.

O manual do Postgres descreve duas outras opções que podem ser automatizadas no Windows com um pequeno script .

Opção 2: backup no nível do sistema de arquivos

Normalmente isto é feito desligando o servidor e pegando o diretório PGDATA .
Se você não puder desligar o servidor, contrário ao que o manual diz aqui , você pode obter um backup utilizável sem desligar o servidor - Simplesmente para fazer um "backup base" como você faria para configurar um Escravo do WAL / PITR .

O resultado desse backup deve ser uma cópia do diretório PGDATA , mais alguns segmentos do WAL, armazenados em um local separado no servidor que seus processos normais de backup no nível do sistema de arquivos podem selecionar.
Você deve garantir que o backup básico seja concluído antes de pegar os arquivos com o processo regular de backup do sistema de arquivos, caso contrário você pode acabar obtendo um backup inutilizável.

Opção 3: Fazendo backup de um escravo

Com este método, você precisará criar um servidor slave, seja log-shipping ou hot standby, conforme descrito nos documentos do Postgres .
Quando for hora de fazer backup de seu cluster, desligue o escravo e faça o backup de seu diretório PGDATA como faria para um backup regular do sistema de arquivos , então reinicie o escravo e deixe-o alcançar o mestre novamente .

Esta é de longe a minha opção favorita para fazer backup de um cluster do Postgres - Se você dedicar um servidor escravo específico para ser o "escravo de backups", pode executar backups do seu cluster sem afetar os aplicativos de produção usando o banco de dados.

As maiores desvantagens são que ele requer um servidor escravo, e você deve ter certeza de que o Postgres está parado no escravo antes você pega o diretório PGDATA , e não é iniciado novamente até você ' É feito pegar os arquivos.
Você também precisa garantir que os backups sejam concluídos em um período de tempo razoável, para que os segmentos do WAL que você precisa alcançar até o mestre ainda estejam disponíveis. Na prática, isso será apenas um problema para clusters com cargas de gravação altas EXTREMELY , ou se você fizer algo como VACUUM FULL no mestre enquanto o escravo está sendo copiado.