2013/9/2 Danilo Silva <[email protected]> > > > > Em 31 de agosto de 2013 08:54, Matheus de Oliveira < > [email protected]> escreveu: > > >> >> >> 2013/8/30 Danilo Silva <[email protected]> >> >>> >>> [...] >>> >>> Realmente, quando você faz **só** um backup base, sem arquivamento, >>>>> você irá precisar de todos os logs de transação gerados entre a chamada do >>>>> pg_start_backup e pg_stop_backup. Em primeiro lugar, eu recomendaria você >>>>> a >>>>> tentar criar uma política de backup para PITR e habilitar **sempre** o >>>>> arquivamento. >>>>> >>>>> Mas... De forma temporária, você pode fazer o seguinte: >>>>> >>>>> 1. Engane o PostgreSQL e habilite o arquivamento sem arquivar (loucura >>>>> né?!): >>>>> >>>>> archive_mode = on >>>>> archive_command = 'exit 0' # veja, não faz nada, só finge que copiou >>>>> >>>>> Reinicie o PostgreSQL (terás de reiniciar somente uma vez, por causa >>>>> do archive_mode). >>>>> >>>>> 2. Quando for executar o backup base, configure o archive_command para >>>>> efetivamente copiar os logs de transação: >>>>> >>>>> archive_command = 'cp %p /path/to/%f' # ou seu comando... >>>>> >>>>> Execute um reload no PostgreSQL (veja, não precisa de restart). >>>>> >>>>> 3. Realize sua cópia normalmente: pg_start_backup => cópia (tar, cp, >>>>> etc.) => pg_stop_backup >>>>> >>>>> 4. Volte o archive_command para 'exit 0' >>>>> >>>>> Pronto, agora basta você "pegar" os arquivos salvos pelo >>>>> archive_command "temporário" e salvá-los junto ao seu backup. Pode até >>>>> colocá-los dentro do diretório pg_xlog do backup, ou, numa restauração >>>>> você >>>>> precisará somente configurar o restore_command no recovery.conf. >>>>> >>>>> Mais uma vez, vejo isso como algo temporário e rápido enquanto não >>>>> define uma boa política de backup com arquivamento, pg_dump, etc... >>>>> >>>>> Era isso que eu precisava saber, vou testar e depois falo como foi. >>>> >>>> >>>> Pessoal deu certo a dica do Matheus, agora surgiu outra dúvida: >>> >>> Preciso montar um script que execute o backup base, até então beleza, >>> sem problemas, existe a possibilidade de colocar no script algum comando >>> que altere a diretiva archive_command ou algo similar? >>> >>> >>> >> Eu faria de forma diferente, criaria um script para fazer o arquivamento >> que verifique se um arquivo de trigger existe (acho que pode usar o próprio >> backup_label), e, se existir, realiza a cópia, caso contrário não faz nada, >> tipo assim: >> >> #!/bin/sh >> >> if [ -r backup_label ]; then >> cp "$1" "$2" >> exit $? >> fi >> exit 0 >> >> Daí você usa esse script no archive_command, tipo: archive_command = >> "/path/to/archive.sh '%f' '/path/to/%p'". >> >> OBS: IIRC, o diretório corrente ao executar o archive_command é o próprio >> PGDATA, por isso usei o caminho relativo para encontrar o backup_label >> (testar para confirmar). >> >> Dessa forma somente quando o backup estiver em progresso é que o script >> realmente copiará os logs de transação, caso contrário, o mesmo irá ignorar >> e "fingir" que copiou. >> >> PS: Mais uma vez, recomendo que, já que está tendo esse trabalho, faça o >> arquivamento contínuo, experimente comprimir com gzip caso ache que está >> ocupando muito espaço, verá que diminui +ou- para uns 20-30%. >> >> >> Obrigado pela dica, mas como ficaria o script sendo para windows? > > O que o script faz é verificar se o arquivo "backup_label" existe, e se existir copia o log de transação e retorna o resultado do comando de cópia como código de retorno, caso não exista, apenas retorna 0 (zero, significa sucesso) como retorno.
Agora é só adaptar para o Windows. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
