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?

[]s
Danilo
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a