Re: [pgbr-geral] Backup and restore

[Manuel Garcia]

Bom eu tive a mesma pregunta e me sorprendi com a resposta ,
Resposta cliente: não o sistema faz backup automática mantendo somente o
mais atual.

Em qui, 12 de abr de 2018 11:44, Jorge Luiz 
escreveu:

> Uma pergunta meio obvia: não há nenhum backup anterior ao relatado agora?
>
>
> Em 12 de abril de 2018 08:21, Manuel Garcia 
> escreveu:
>
>> Bom dia,
>>
>> Sou Alejandro engenheiro em computação trabalho no brasil como dba
>> postgresql, meu problema é o cliente que tem un dba na sua empresa fez um
>> backup do postgresql only data , deleto o banco e foi restaurar em outra
>> maquina sem ter salvo o schema dele , como eu consigo recuperar as function
>> tables views resumindo a estrutura do banco desde un backup only data ???
>>
>>
>> --
>>Manuel Alejandro Garcia Mellado
>> Ingeniero Ejecución en Informática e computación
>> Concepcion - Chile VIII Region del Bio - Bio
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> Jorge Luiz
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup and restore

[Jorge Luiz]

Uma pergunta meio obvia: não há nenhum backup anterior ao relatado agora?


Em 12 de abril de 2018 08:21, Manuel Garcia 
escreveu:

> Bom dia,
>
> Sou Alejandro engenheiro em computação trabalho no brasil como dba
> postgresql, meu problema é o cliente que tem un dba na sua empresa fez um
> backup do postgresql only data , deleto o banco e foi restaurar em outra
> maquina sem ter salvo o schema dele , como eu consigo recuperar as function
> tables views resumindo a estrutura do banco desde un backup only data ???
>
>
> --
>Manuel Alejandro Garcia Mellado
> Ingeniero Ejecución en Informática e computación
> Concepcion - Chile VIII Region del Bio - Bio
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Jorge Luiz
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup and restore

[Manuel Garcia]

Ok muito obrigado a todos. Realmente tere que ver na mão mesmo.

Em qui, 12 de abr de 2018 09:04, Arlindo Neto  escreveu:

> Minha opinião: se o seu dump for data-only, você vai ter que recriar os
> schemas, views etc na mão e adapta-los ou seus dados... Resumidamente, boa
> sorte. Vai ser trabalhoso, mas não é impossível.
>
> Abraços.
>
> Em qui, 12 de abr de 2018 9:00 AM, Fábio Telles Rodriguez <
> fabio.tel...@gmail.com> escreveu:
>
>> Ahh... um backup only data é algo realmente feio. Pra começar... dump não
>> é backup! ;-)
>>
>> Vide: https://www.savepoint.blog.br/2010/05/06/dump-nao-e-backup/
>>
>> Se você não colocar as informações corretas no backup, não vai conseguir
>> extrair o que não existe.
>>
>>
>>
>> Em 12 de abril de 2018 08:22, Manuel Garcia 
>> escreveu:
>>
>>> alguém já tive algum problema similar que me possa orientar para poder
>>> resolver esse problema.
>>>
>>> 2018-04-12 8:21 GMT-03:00 Manuel Garcia :
>>>
 Bom dia,

 Sou Alejandro engenheiro em computação trabalho no brasil como dba
 postgresql, meu problema é o cliente que tem un dba na sua empresa fez um
 backup do postgresql only data , deleto o banco e foi restaurar em outra
 maquina sem ter salvo o schema dele , como eu consigo recuperar as function
 tables views resumindo a estrutura do banco desde un backup only data ???


 --
Manuel Alejandro Garcia Mellado
 Ingeniero Ejecución en Informática e computación
 Concepcion - Chile VIII Region del Bio - Bio


>>>
>>>
>>> --
>>>Manuel Alejandro Garcia Mellado
>>> Ingeniero Ejecución en Informática e computación
>>> Concepcion - Chile VIII Region del Bio - Bio
>>>
>>>
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>
>>
>>
>> --
>> Atenciosamente,
>> Fábio Telles Rodriguez
>> blog: http:// s
>> avepoint.blog.br
>> 
>> e-mail / gtalk / MSN: fabio.tel...@gmail.com
>> Skype: fabio_telles
>>
>> Timbira - A empresa brasileira de Postgres
>> http://www.timbira.com.br
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup and restore

[Arlindo Neto]

Minha opinião: se o seu dump for data-only, você vai ter que recriar os
schemas, views etc na mão e adapta-los ou seus dados... Resumidamente, boa
sorte. Vai ser trabalhoso, mas não é impossível.

Abraços.

Em qui, 12 de abr de 2018 9:00 AM, Fábio Telles Rodriguez <
fabio.tel...@gmail.com> escreveu:

> Ahh... um backup only data é algo realmente feio. Pra começar... dump não
> é backup! ;-)
>
> Vide: https://www.savepoint.blog.br/2010/05/06/dump-nao-e-backup/
>
> Se você não colocar as informações corretas no backup, não vai conseguir
> extrair o que não existe.
>
>
>
> Em 12 de abril de 2018 08:22, Manuel Garcia 
> escreveu:
>
>> alguém já tive algum problema similar que me possa orientar para poder
>> resolver esse problema.
>>
>> 2018-04-12 8:21 GMT-03:00 Manuel Garcia :
>>
>>> Bom dia,
>>>
>>> Sou Alejandro engenheiro em computação trabalho no brasil como dba
>>> postgresql, meu problema é o cliente que tem un dba na sua empresa fez um
>>> backup do postgresql only data , deleto o banco e foi restaurar em outra
>>> maquina sem ter salvo o schema dele , como eu consigo recuperar as function
>>> tables views resumindo a estrutura do banco desde un backup only data ???
>>>
>>>
>>> --
>>>Manuel Alejandro Garcia Mellado
>>> Ingeniero Ejecución en Informática e computación
>>> Concepcion - Chile VIII Region del Bio - Bio
>>>
>>>
>>
>>
>> --
>>Manuel Alejandro Garcia Mellado
>> Ingeniero Ejecución en Informática e computación
>> Concepcion - Chile VIII Region del Bio - Bio
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> Atenciosamente,
> Fábio Telles Rodriguez
> blog: http:// s
> avepoint.blog.br 
> e-mail / gtalk / MSN: fabio.tel...@gmail.com
> Skype: fabio_telles
>
> Timbira - A empresa brasileira de Postgres
> http://www.timbira.com.br
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup and restore

[Fábio Telles Rodriguez]

Ahh... um backup only data é algo realmente feio. Pra começar... dump não é
backup! ;-)

Vide: https://www.savepoint.blog.br/2010/05/06/dump-nao-e-backup/

Se você não colocar as informações corretas no backup, não vai conseguir
extrair o que não existe.



Em 12 de abril de 2018 08:22, Manuel Garcia 
escreveu:

> alguém já tive algum problema similar que me possa orientar para poder
> resolver esse problema.
>
> 2018-04-12 8:21 GMT-03:00 Manuel Garcia :
>
>> Bom dia,
>>
>> Sou Alejandro engenheiro em computação trabalho no brasil como dba
>> postgresql, meu problema é o cliente que tem un dba na sua empresa fez um
>> backup do postgresql only data , deleto o banco e foi restaurar em outra
>> maquina sem ter salvo o schema dele , como eu consigo recuperar as function
>> tables views resumindo a estrutura do banco desde un backup only data ???
>>
>>
>> --
>>Manuel Alejandro Garcia Mellado
>> Ingeniero Ejecución en Informática e computación
>> Concepcion - Chile VIII Region del Bio - Bio
>>
>>
>
>
> --
>Manuel Alejandro Garcia Mellado
> Ingeniero Ejecución en Informática e computación
> Concepcion - Chile VIII Region del Bio - Bio
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// s
avepoint.blog.br 
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

Timbira - A empresa brasileira de Postgres
http://www.timbira.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup and restore

[Manuel Garcia]

alguém já tive algum problema similar que me possa orientar para poder
resolver esse problema.

2018-04-12 8:21 GMT-03:00 Manuel Garcia :

> Bom dia,
>
> Sou Alejandro engenheiro em computação trabalho no brasil como dba
> postgresql, meu problema é o cliente que tem un dba na sua empresa fez um
> backup do postgresql only data , deleto o banco e foi restaurar em outra
> maquina sem ter salvo o schema dele , como eu consigo recuperar as function
> tables views resumindo a estrutura do banco desde un backup only data ???
>
>
> --
>Manuel Alejandro Garcia Mellado
> Ingeniero Ejecución en Informática e computación
> Concepcion - Chile VIII Region del Bio - Bio
>
>


-- 
   Manuel Alejandro Garcia Mellado
Ingeniero Ejecución en Informática e computación
Concepcion - Chile VIII Region del Bio - Bio
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com pg_probackup

[Fabrízio de Royes Mello]

Em 30 de junho de 2017 09:01, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:
>
> bom dia pessoal,
>
> alguem ja utilizou ou utiliza a ferramenta [1] para fazer os backups do
postgres?
> pelo que vi na documentação tanto o processo de fazer como o de restaurar
em caso de desastre é bem mais simples que outras como o [2] e o [3].
>

Eu não posso nem concordar e nem discordar com vc porque nunca usei [1]...
mas tanto [2] quanto [3] são bem simples...

Uma coisa que sempre observo nessas ferramentas é se o seu desenvolvimento
está ativo, então se vc observar o github delas pode notar que [1] deve seu
último commit em Mar/2017, já [2] há 3 dias atrás e [3] há 29 dias...

Isso não quer dizer nada em relação a uma ser melhor que a outra e tal, mas
acredito que software é algo quase que orgânico e que deve estar sempre em
movimento.

Att,

[1] https://github.com/postgrespro/pg_probackup
[2] http://www.pgbackrest.org/
[3] http://www.pgbarman.org/

--
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup sem o pg_dump

[Leandro Guimarães Faria Corcete DUTRA]

Le 15 janvier 2017 11:58:58 GMT-02:00, "POWER Informática" 
 a écrit :
>Pessoal vocês sabem de alguma classe PHP, ou algum projeto que realiza 
>backup sem a utilização do "pg_dump" ?

Tipo Barman ?



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691 (Vivo) ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[Adilson Domiciano Júnior]

Boa tarde,

Obrigado amigos pelas respostas, já me ajudou bastante.

Att,
Adilson Domiciano Júnior

Em 29/03/2016 16:21, Fabrízio de Royes Mello escreveu:

On 29-03-2016 15:42, Rafael Fialho wrote:

Em 28 de março de 2016 16:10, Franklin Anderson de Oliveira Souza
> escreveu:

 Como eu disse o pg_dump não bloquei as tabelas, segue abaixo o
 primeiro paragrafo da documentação:

 "...pg_dump is a utility for backing up a PostgreSQL database. It
 makes consistent backups even if the database is being used
 concurrently. *pg_dump does not block other users accessing the
 database (readers or writers)*..."


Boa tarde.
Realmente, não bloqueia *intencionalmente* os usuários, porém o pg_dump,
conforme a própria documentação informa, utiliza SELECTS, e estes, para
que o ACID seja mantido, podem promover diversos tipos de bloqueios nas
tabelas que estão sendo processadas.

Pode bloquer não, ele bloqueia, porém é um AccessShareLock que não
impede DML, porém impede DDL.



Na prática, existe a possibilidade de uma tabela ficar indisponível
enquanto está sofrendo o dump, e por isso o colega não está errado ao
informar que usuários ficam com operações bloqueadas.


Sim, se houver uma tentativa de execução de algum DDL na(s) tabela(s)
que está(ão) sendo exportada(s) então você terá um processo em espera.

Att,



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[Fabrízio de Royes Mello]

On 29-03-2016 15:42, Rafael Fialho wrote:
> Em 28 de março de 2016 16:10, Franklin Anderson de Oliveira Souza
> > escreveu:
> 
> Como eu disse o pg_dump não bloquei as tabelas, segue abaixo o
> primeiro paragrafo da documentação:
> 
> "...pg_dump is a utility for backing up a PostgreSQL database. It
> makes consistent backups even if the database is being used
> concurrently. *pg_dump does not block other users accessing the
> database (readers or writers)*..."
> 
> 
> Boa tarde.
> Realmente, não bloqueia *intencionalmente* os usuários, porém o pg_dump,
> conforme a própria documentação informa, utiliza SELECTS, e estes, para
> que o ACID seja mantido, podem promover diversos tipos de bloqueios nas
> tabelas que estão sendo processadas.

Pode bloquer não, ele bloqueia, porém é um AccessShareLock que não
impede DML, porém impede DDL.


> Na prática, existe a possibilidade de uma tabela ficar indisponível
> enquanto está sofrendo o dump, e por isso o colega não está errado ao
> informar que usuários ficam com operações bloqueadas.
> 

Sim, se houver uma tentativa de execução de algum DDL na(s) tabela(s)
que está(ão) sendo exportada(s) então você terá um processo em espera.

Att,

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[Rafael Fialho]

Em 28 de março de 2016 16:10, Franklin Anderson de Oliveira Souza <
frankli...@gmail.com> escreveu:

> Como eu disse o pg_dump não bloquei as tabelas, segue abaixo o primeiro
> paragrafo da documentação:
>
> "...pg_dump is a utility for backing up a PostgreSQL database. It makes
> consistent backups even if the database is being used concurrently. *pg_dump 
> does
> not block other users accessing the database (readers or writers)*..."
>
>
Boa tarde.
Realmente, não bloqueia *intencionalmente* os usuários, porém o pg_dump,
conforme a própria documentação informa, utiliza SELECTS, e estes, para que
o ACID seja mantido, podem promover diversos tipos de bloqueios nas tabelas
que estão sendo processadas.
Na prática, existe a possibilidade de uma tabela ficar indisponível
enquanto está sofrendo o dump, e por isso o colega não está errado ao
informar que usuários ficam com operações bloqueadas.

Não existe uma forma de evitar isso com o pg_dump, ou ao menos não conheço.
O que existem são outras soluções de backup que podem amenizar estes
problemas, como replicação, por exemplo. Aí vai da sua real necessidade e
possibilidades.

[]'s
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[Franklin Anderson de Oliveira Souza]

Como eu disse o pg_dump não bloquei as tabelas, segue abaixo o primeiro
paragrafo da documentação:

"...pg_dump is a utility for backing up a PostgreSQL database. It makes
consistent backups even if the database is being used concurrently.
*pg_dump does
not block other users accessing the database (readers or writers)*..."

Em 28 de março de 2016 15:00, Adilson Domiciano Júnior  escreveu:

>
>
> Acho que ele quer saber se o backup sofre algum tipo de bloqueio enquanto
> realiza o backup. Por default o dump é não bloqueante, vai usar recursos da
> maquinas mas pelo que sei não vai bloquear tabelas ou o banco para tal
> procedimento.
>
>
> Sim, isso que quero saber se tem algum jeito de não bloquear tabelas,
> estou usando o pg_dump e ao fazer o backup o banco fica bloqueado para
> fazer inserções, consigo ver isso pelo server status do pgAdmin. Alguém
> sabe se é possível através de alguma técnica ou configuração se é possível
> não bloquear?
>
>
> Em 28 de março de 2016 14:46, André Ormenese 
> escreveu:
>
>>
>>
>> Em 28 de março de 2016 15:21, Adilson Domiciano Júnior <
>> adilson...@gmail.com> escreveu:
>>
>>> Boa tarde,
>>>
>>> Queria saber se tem alguma configuração que eu possa fazer para que o
>>> banco faça um backup com os seus usuários operando, sem que atrapalhe o
>>> funcionamento do banco.
>>> Obrigado.
>>>
>>> Att,
>>> Adilson Domiciano
>>>
>>
>> Sim é possível.
>>  Tudo sobre backup do Postgres você encontra no próprio manual [1], e não
>> deixe de ler o texto do Telles [2].
>>
>> [1] http://www.postgresql.org/docs/9.5/static/backup.html
>> [2] http://savepoint.blog.br/dump-nao-e-backup/
>>
>>
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> foobar
>
>
> ___
> pgbr-geral mailing 
> listpgbr-ge...@listas.postgresql.org.brhttps://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
foobar
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[Adilson Domiciano Júnior]

Acho que ele quer saber se o backup sofre algum tipo de bloqueio 
enquanto realiza o backup. Por default o dump é não bloqueante, vai 
usar recursos da maquinas mas pelo que sei não vai bloquear tabelas ou 
o banco para tal procedimento.


Sim, isso que quero saber se tem algum jeito de não bloquear tabelas, 
estou usando o pg_dump e ao fazer o backup o banco fica bloqueado para 
fazer inserções, consigo ver isso pelo server status do pgAdmin. Alguém 
sabe se é possível através de alguma técnica ou configuração se é 
possível não bloquear?


Em 28 de março de 2016 14:46, André Ormenese > escreveu:




Em 28 de março de 2016 15:21, Adilson Domiciano Júnior
> escreveu:

Boa tarde,

Queria saber se tem alguma configuração que eu possa fazer
para que o banco faça um backup com os seus usuários operando,
sem que atrapalhe o funcionamento do banco.
Obrigado.

Att,
Adilson Domiciano


Sim é possível.
 Tudo sobre backup do Postgres você encontra no próprio manual
[1], e não deixe de ler o texto do Telles [2].

[1] http://www.postgresql.org/docs/9.5/static/backup.html
[2] http://savepoint.blog.br/dump-nao-e-backup/



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br

https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




--
foobar


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[Franklin Anderson de Oliveira Souza]

Acho que ele quer saber se o backup sofre algum tipo de bloqueio enquanto
realiza o backup. Por default o dump é não bloqueante, vai usar recursos da
maquinas mas pelo que sei não vai bloquear tabelas ou o banco para tal
procedimento.

Em 28 de março de 2016 14:46, André Ormenese  escreveu:

>
>
> Em 28 de março de 2016 15:21, Adilson Domiciano Júnior <
> adilson...@gmail.com> escreveu:
>
>> Boa tarde,
>>
>> Queria saber se tem alguma configuração que eu possa fazer para que o
>> banco faça um backup com os seus usuários operando, sem que atrapalhe o
>> funcionamento do banco.
>> Obrigado.
>>
>> Att,
>> Adilson Domiciano
>>
>
> Sim é possível.
>  Tudo sobre backup do Postgres você encontra no próprio manual [1], e não
> deixe de ler o texto do Telles [2].
>
> [1] http://www.postgresql.org/docs/9.5/static/backup.html
> [2] http://savepoint.blog.br/dump-nao-e-backup/
>
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
foobar
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[André Ormenese]

Em 28 de março de 2016 15:21, Adilson Domiciano Júnior  escreveu:

> Boa tarde,
>
> Queria saber se tem alguma configuração que eu possa fazer para que o
> banco faça um backup com os seus usuários operando, sem que atrapalhe o
> funcionamento do banco.
> Obrigado.
>
> Att,
> Adilson Domiciano
>

Sim é possível.
 Tudo sobre backup do Postgres você encontra no próprio manual [1], e não
deixe de ler o texto do Telles [2].

[1] http://www.postgresql.org/docs/9.5/static/backup.html
[2] http://savepoint.blog.br/dump-nao-e-backup/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup - Refresh DB PostgreSQL 9.2

[Glauco Torres]

> Pode parecer uma pergunta besta mas
> Quando vc pega algo já em producão fica difícil de ter certeza o que
> aconteceu e o que não aconteceu hehehehe
>
> Possuo um servidor de testes, com 4 DB. Cada uma delas é uma cópia
> perfeita da minha DB de producão, sempre excluindo algum schema ou outro.
>
> Queria saber como posso descobrir quando as 4 DB foram atualizadas pela
> última vez.
>
>
>
>
Até onde eu saiba não tem nenhuma forma 100% de conseguir essa informação.
(Posso estar desatualizado)

Já utilizei duas formas.

Você pode ver a data de criação do PG_VERSION que é criado durante o initdb
e quase não sofre modificação. *Este é o método mais confiável que eu
conheço.

Segue SQL:

postgres=# SELECT (pg_stat_file('base/'||oid||'/PG_VERSION')).modification
  FROM pg_database
 WHERE datname = current_database();
  modification

 2014-07-05 16:44:44-03
(1 row)


E tem outro, que já foi dito aqui na lista que não é confiável pois muda
der acordo com o uso. Mais já me auxilio bastante.

SQL:

postgres=# SELECT oid FROM pg_database WHERE datname = 'base';
  oid
---
 16466
(1 row)


Agora vá onde esta o seu $PGDATA,  no meu caso,

# ls -lt /dados/rplspace/PG_9.3_201306121/16466/ | tail -2
-rw--- 1 postgres postgres  0 Nov 16  2014 1410807334
-rw--- 1 postgres postgres  0 Nov 16  2014 1410807289



Att Glauco Torres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup - Refresh DB PostgreSQL 9.2

[Fabrízio de Royes Mello]

On 04-02-2016 07:44, Glauco Torres wrote:
> 
> Até onde eu saiba não tem nenhuma forma 100% de conseguir essa
> informação. (Posso estar desatualizado)
> 

Vc não está desatualizado quanto a isso...


> Já utilizei duas formas.
> 
> Você pode ver a data de criação do PG_VERSION que é criado durante o
> initdb e quase não sofre modificação. *Este é o método mais confiável
> que eu conheço.
> 
> Segue SQL:
> 
> postgres=# SELECT (pg_stat_file('base/'||oid||'/PG_VERSION')).modification
>   FROM pg_database
>  WHERE datname = current_database();
>   modification 
> 
>  2014-07-05 16:44:44-03
> (1 row)
> 

Só para complementar, o PG_VERSION é criado no diretório raiz do cluster
(aka $PGDATA) e em todo diretório dos databases ($PGDATA/base/$OID).

Há algum tempo atrás até enviei um patch para adicionar uma coluna
chamada "datcreated" na "pg_database", mas infelizmente foi rejeitado.


> E tem outro, que já foi dito aqui na lista que não é confiável pois muda
> der acordo com o uso. Mais já me auxilio bastante.
> 
> SQL:
> 
> postgres=# SELECT oid FROM pg_database WHERE datname = 'base';
>   oid 
> ---
>  16466
> (1 row)
> 
> 
> Agora vá onde esta o seu $PGDATA,  no meu caso,
> 
> # ls -lt /dados/rplspace/PG_9.3_201306121/16466/ | tail -2
> -rw--- 1 postgres postgres  0 Nov 16  2014 1410807334
> -rw--- 1 postgres postgres  0 Nov 16  2014 1410807289
> 

Não use esse... arriscado demais...

Att,

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup - Refresh DB PostgreSQL 9.2

[drum.lu...@gmail.com]

2016-02-05 5:43 GMT+13:00 Fabrízio de Royes Mello :

> On 04-02-2016 07:44, Glauco Torres wrote:
> >
> > Até onde eu saiba não tem nenhuma forma 100% de conseguir essa
> > informação. (Posso estar desatualizado)
> >
>
> Vc não está desatualizado quanto a isso...
>
>
> > Já utilizei duas formas.
> >
> > Você pode ver a data de criação do PG_VERSION que é criado durante o
> > initdb e quase não sofre modificação. *Este é o método mais confiável
> > que eu conheço.
> >
> > Segue SQL:
> >
> > postgres=# SELECT
> (pg_stat_file('base/'||oid||'/PG_VERSION')).modification
> >   FROM pg_database
> >  WHERE datname = current_database();
> >   modification
> > 
> >  2014-07-05 16:44:44-03
> > (1 row)
> >
>
> Só para complementar, o PG_VERSION é criado no diretório raiz do cluster
> (aka $PGDATA) e em todo diretório dos databases ($PGDATA/base/$OID).
>
> Há algum tempo atrás até enviei um patch para adicionar uma coluna
> chamada "datcreated" na "pg_database", mas infelizmente foi rejeitado.
>
>
> > E tem outro, que já foi dito aqui na lista que não é confiável pois muda
> > der acordo com o uso. Mais já me auxilio bastante.
> >
> > SQL:
> >
> > postgres=# SELECT oid FROM pg_database WHERE datname = 'base';
> >   oid
> > ---
> >  16466
> > (1 row)
> >
> >
> > Agora vá onde esta o seu $PGDATA,  no meu caso,
> >
> > # ls -lt /dados/rplspace/PG_9.3_201306121/16466/ | tail -2
> > -rw--- 1 postgres postgres  0 Nov 16  2014 1410807334
> > -rw--- 1 postgres postgres  0 Nov 16  2014 1410807289
> >
>
> Não use esse... arriscado demais...
>
>
> Certo. Obrigado pelas informacões galera.

Lucas
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup-Restore incremental

[ChIcO]

Em 30 de janeiro de 2016 12:48, Tiago José Adami 
escreveu:

> Em 29 de janeiro de 2016 17:51, Luiz Henrique
>  escreveu:
> > Pessoal,
> >
> > Tenho Postgresql 9.1, Linux CentOS. 5 Databases. 1 Database tem 254
> > GB.Preciso levar diariamente somente esse Database (254 GB) para outro
> > servidor (homologação).O tempo de pg_dump / pg_restore leva cerca de
> > 8h.Procuro alternativas para atualizar somente as diferenças do dia
> > anterior. Sugestões e dicas serão muito bem vindas.
>
> Para um ambiente de homologação manter uma replicação para "atualizar
> somente as diferenças do dia anterior" não é a melhor alternativa,
> pois espera-se que o banco de homologação receba alterações (INSERT,
> UPDATE, DELETE).
>
> Talvez um simples pg_basebackup[1] seja a melhor solução, considerando
> que ambos os servidores (origem e homologação) possuem o mesmo SO e
> mesma versão do PostgreSQL. O tempo para gerar um backup pelo
> pg_basebackup em comparação com um dump (que não é exatamente um
> backup [2]) é gritante, ao passo que é feito uma cópia dos arquivos
> originais.
>
> Lembrando que o pg_basebackup faz a cópia de todo o cluster, isto é,
> inclui todos os bancos de dados nele criados.
>

Bom dia,

Com função semelhante, mas mas antigo tem o pg_standby. Ele é um script que
por baixo faz o rsync do data, lembrando que no rsync ele irá copiar apenas
os arquivos diferentes, arquivos iguais ele não faz a cópia.

Caso existam mais databases no servidor e deseja copiar apenas este de
254GB, depois de ter sido feito uma cópia completa é possível iniciar um
backup e fazer o rsync da pasta do database desejado.

Tenho dúvida se o pg_basebackup copia todos os arquivos ou apenas os
alterados. Acredito que todos, então pode ser um pouco mais demorado q o
rsync.

Qualquer solução de cópia de filesystem a versão tem que ser a mesma e é
interessante q o linux também.


Att,
Francisco Summa


>
> [1] http://www.postgresql.org/docs/9.1/static/app-pgbasebackup.html
> [2] http://savepoint.blog.br/dump-nao-e-backup/
>
> TIAGO J. ADAMI
> http://www.adamiworks.com
> @tiadami
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup-Restore incremental

[Tiago José Adami]

Em 1 de fevereiro de 2016 09:00, ChIcO  escreveu:
> Tenho dúvida se o pg_basebackup copia todos os arquivos ou apenas os
> alterados. Acredito que todos, então pode ser um pouco mais demorado q o
> rsync.

O pg_basebackup não faz cópias incrementais, cada vez que é executado
é feito uma nova cópia integral de todos os arquivos.

Como é um ambiente de homologação e testes supõe-se que os dados serão
alterados no ambiente de homologação, logo não há como manter uma
baseline sincronizada com o ambiente de produção através pg_standby
[1] - este faz a replicação dos logs transacionais (WAL).

Usar o rsync é possível, mas é um procedimento passível de erros
(permissões, espaço em disco, pontos de montagem, etc.). Para
utilizá-lo com segurança é preciso parar o serviço nos dois ambientes
antes de executá-lo e dependendo da SLA isto nem sempre é permitido.

[1] http://www.postgresql.org/docs/9.1/static/pgstandby.html

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup-Restore incremental

[Euler Taveira]

On 29-01-2016 16:51, Luiz Henrique wrote:
> Tenho Postgresql 9.1, Linux CentOS. 5 Databases. 1 Database tem 254
> GB.Preciso levar diariamente somente esse Database (254 GB) para outro
> servidor (homologação).O tempo de pg_dump / pg_restore leva cerca de
> 8h.Procuro alternativas para atualizar somente as diferenças do dia
> anterior.
> 
Você não informou o tamanho do cluster. Todavia, vou supor que seja o
seu maior banco de dados.

Utilize backup físico e, depois de subir o servidor de homologação,
remova os 4 bancos de dados (isso se você tiver espaço para abrigar todo
o cluster na homologação). Para esse caso, não utilize pg_basebackup; ao
invés disso, utilize o rsync entre o pg_start_backup e pg_stop_backup
[1]. Na primeira execução ele vai copiar tudo; nas execuções
subsequentes, ele vai copiar somente os arquivos alterados e os arquivos
dos outros 4 bancos de dados.

Se os 4 bancos de dados não forem tão grandes, o procedimento será bem
mais rápido que as 8 horas do backup lógico.


[1]
http://www.postgresql.org/docs/9.1/static/continuous-archiving.html#BACKUP-BASE-BACKUP


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup-Restore incremental

[Tiago José Adami]

Em 29 de janeiro de 2016 17:51, Luiz Henrique
 escreveu:
> Pessoal,
>
> Tenho Postgresql 9.1, Linux CentOS. 5 Databases. 1 Database tem 254
> GB.Preciso levar diariamente somente esse Database (254 GB) para outro
> servidor (homologação).O tempo de pg_dump / pg_restore leva cerca de
> 8h.Procuro alternativas para atualizar somente as diferenças do dia
> anterior. Sugestões e dicas serão muito bem vindas.

Para um ambiente de homologação manter uma replicação para "atualizar
somente as diferenças do dia anterior" não é a melhor alternativa,
pois espera-se que o banco de homologação receba alterações (INSERT,
UPDATE, DELETE).

Talvez um simples pg_basebackup[1] seja a melhor solução, considerando
que ambos os servidores (origem e homologação) possuem o mesmo SO e
mesma versão do PostgreSQL. O tempo para gerar um backup pelo
pg_basebackup em comparação com um dump (que não é exatamente um
backup [2]) é gritante, ao passo que é feito uma cópia dos arquivos
originais.

Lembrando que o pg_basebackup faz a cópia de todo o cluster, isto é,
inclui todos os bancos de dados nele criados.

[1] http://www.postgresql.org/docs/9.1/static/app-pgbasebackup.html
[2] http://savepoint.blog.br/dump-nao-e-backup/

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[alfredo júnior]

Em 24-11-2015 08:43, Antonio Cesar escreveu:

Bom dia,
Fiz um arquivo .sh para efetuar o dump. Agora estou precisando copiar 
para uma maquina windows, alguem tem algum exemplo?


Compartilhe uma pasta no windows e monte essa pasta no linux, agora é só 
copiar para essa pasta que foi montada no linux.

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[Sebastian Webber]

Em 24 de novembro de 2015 08:43, Antonio Cesar 
escreveu:

> Bom dia,
> Fiz um arquivo .sh para efetuar o dump. Agora estou precisando copiar para
> uma maquina windows, alguem tem algum exemplo?
>

Melhor que isso: um link bonitão da wiki[1]!

[1] https://wiki.postgresql.org/wiki/Automated_Backup_on_Windows

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[Guimarães Faria Corcete DUTRA , Leandro]

2015-11-24 8:43 GMT-02:00 Antonio Cesar :
> Fiz um arquivo .sh para efetuar o dump. Agora estou precisando copiar para
> uma maquina windows, alguem tem algum exemplo?

Use o cygwin.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[Marcos - GMail]

Samba!
Em 24/11/2015 13:36, "Guimarães Faria Corcete DUTRA, Leandro" 
escreveu:

> 2015-11-24 8:43 GMT-02:00 Antonio Cesar :
> > Fiz um arquivo .sh para efetuar o dump. Agora estou precisando copiar
> para
> > uma maquina windows, alguem tem algum exemplo?
>
> Use o cygwin.
>
>
> --
> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup

[Rafael Fialho]

Em 24 de novembro de 2015 13:36, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2015-11-24 8:43 GMT-02:00 Antonio Cesar :
> > Fiz um arquivo .sh para efetuar o dump. Agora estou precisando copiar
> para
> > uma maquina windows, alguem tem algum exemplo?
>
> Use o cygwin.
>

+1
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico com rsync

[Everton Berz]

Oi
utilizamos essa estratégia por aqui em uma base de ~5TB (produção), fizemos
diversos testes de backup e restore e não encontramos problemas.
Inclusive fazemos rsync incremental durante a semana.





--
Everton

2015-08-16 2:05 GMT-03:00 Danilo Silva danilo.dsg.go...@gmail.com:

 Pessoal,

 Atualmente meu backup físico utilizando o pg_basebackup leva em torno de 2
 horas para ser concluído (ambiente linux com postgres 9.3).

 Efetuei alguns testes (em um cluster menor) utilizando o rsync para
 efetuar a cópia, ou seja, tudo manual (pg_start_backup, rsync,
 pg_stop_backup).

 Após alguns dias, simulando a realidade de cópia física com rsync, efetuei
 o restore, e aparentemente tudo ocorreu normalmente sem problemas.

 A minha dúvida está na confiabilidade, se eu colocar esse método em
 produção poderei ter problemas?

 []s
 Danilo

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico com rsync

[JFC.Jr]

Olá amigo,
Muito Boa Tarde
No meu sistema eu utilizo assim:
*** Para o BackUp ***:--

pg_dump --host localhost --port 5432 --username NOME_USUARIO_POSTGRES 
--format plain --create --column-inserts --disable-dollar-quoting --verbose 
--file NOME_ARQUIVO_SAIDA.sql NOME_DATABASE
ou
pg_dump --host IP_SERVIDOR --port 5432 --username NOME_USUARIO_POSTGRES 
--format plain --create --column-inserts --disable-dollar-quoting --verbose 
--file /CAMINHO/NOME_ARQUIVO_SAIDA.sql NOME_DATABASE
 
*** Para o Restore ***:---
psql -uXX -dYY
Onde: XX = NOME_USUARIO_POSTGRESOnde: YY = NOME_DATABASE
No Terminal do PSQL copie e cole a linha abaixo:
\i /CAMINHO/NOME_ARQUIVO_SAIDA.sql;
Espero ter ajudado.
Boa Sorte!
Abraços,

Janir Junior
CYBERDYNE Sistemas de Informática Ltda.
(011) 98956-1007
jfc_jun...@yahoo.com.br


 
  De: Everton Berz everton.b...@gmail.com
 Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br 
 Enviadas: Segunda-feira, 17 de Agosto de 2015 12:37
 Assunto: Re: [pgbr-geral] Backup físico com rsync
   
Oiutilizamos essa estratégia por aqui em uma base de ~5TB (produção), fizemos 
diversos testes de backup e restore e não encontramos problemas.Inclusive 
fazemos rsync incremental durante a semana.




--
Everton
2015-08-16 2:05 GMT-03:00 Danilo Silva danilo.dsg.go...@gmail.com:



Pessoal,
Atualmente meu backup físico utilizando o pg_basebackup leva em torno de 2 
horas para ser concluído (ambiente linux com postgres 9.3).
Efetuei alguns testes (em um cluster menor) utilizando o rsync para efetuar a 
cópia, ou seja, tudo manual (pg_start_backup, rsync, pg_stop_backup).
Após alguns dias, simulando a realidade de cópia física com rsync, efetuei o 
restore, e aparentemente tudo ocorreu normalmente sem problemas.
A minha dúvida está na confiabilidade, se eu colocar esse método em produção 
poderei ter problemas?
[]sDanilo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


   
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup incremental

[Lucas Viecelli]

Obrigado pelas respostas pessoal.

Sobre as politicas de backups escritas no seu artigo, achei todas
fundamentais e estou analisando a forma de implementar elas ou pelo
menos discutir com meus superiores, que por sinal é um ótimo artigo.

Sobre backups contra fatos desconhecidos e inesperados, acho que estou
protegido, mas isso não é uma certeza ainda.

A minha necessidade nesse momento realmente é Point In Time
Recovery, verifiquei que existem outras ferramentas que fazem esse
trabalho além do PgBarman, e existe a forma de fazer isso nativamente,
utilizando os famosos WAL, agora preciso ver se vale a pena usar uma
ferramenta ou tentar fazer isso utilizando os recursos do próprio
postgres.





Em 13 de julho de 2015 17:53, Fábio Telles Rodriguez
fabio.tel...@gmail.com escreveu:

 Em 13 de julho de 2015 11:44, Lucas Viecelli lviecelli...@gmail.com
 escreveu:

 Bom dia.

 Estou estudando formas de automatizar de uma maneira mais confiável os
 backup de uma base de dados postgres-9.4

 As necessidades são:
 -Backups incrementais a cada uma hora.(Existem diversos softwares de
 terceiros que utilizam a base, por isso 1 hora)
 -3 Backups completos durante o dia.
 -Salvar em outra máquina da rede.


 Lucas, é melhor você conhecer o conceito de Point In Time Recovery antes de
 continuar. Acho que você está pensando numa abordagem estilo Dump. Não faz
 sentido fazer um backup a cada uma hora.

 Veja o artigo: http://savepoint.blog.br/dump-nao-e-backup/

 Entenda o que é uma política de backup. Depois voltamos a conversar. Acho
 que vale à pena.




 O que mais atende as minhas necessidades é o PgBarman[1], queria saber
 sobre o que vocês utilizam para esse tipo de necessidade, se existem
 outras ferramentas.

  Se alguém tem alguns tutoriais para ajudar no estudo e implementação,
 será de grande ajuda.

 O sistema operacional é o Fedora, e a base de dados é pequena 20GB.

 1 - http://www.pgbarman.org/
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




 --
 Atenciosamente,
 Fábio Telles Rodriguez
 blog: http://savepoint.blog.br
 e-mail / gtalk / MSN: fabio.tel...@gmail.com
 Skype: fabio_telles

 Timbira - A empresa brasileira de Postgres
 http://www.timbira.com.br

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente.

Lucas Viecelli
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup incremental

[Cleiton Luiz Domazak]

Em 14 de julho de 2015 08:21, Lucas Viecelli lviecelli...@gmail.com
escreveu:

 Obrigado pelas respostas pessoal.

 Sobre as politicas de backups escritas no seu artigo, achei todas
 fundamentais e estou analisando a forma de implementar elas ou pelo
 menos discutir com meus superiores, que por sinal é um ótimo artigo.

 Sobre backups contra fatos desconhecidos e inesperados, acho que estou
 protegido, mas isso não é uma certeza ainda.

 A minha necessidade nesse momento realmente é Point In Time
 Recovery, verifiquei que existem outras ferramentas que fazem esse
 trabalho além do PgBarman, e existe a forma de fazer isso nativamente,
 utilizando os famosos WAL, agora preciso ver se vale a pena usar uma
 ferramenta ou tentar fazer isso utilizando os recursos do próprio
 postgres.


Eu utilizo o pgBarman e funciona muito bem, muito fácil de configurar e até
o momento se mostrou confiável. Além do PITR você pode pensar em um
servidor replica, que pode ser uma solução muito rápida de restore em
caso de falhas físicas do seu servidor Master.






 Em 13 de julho de 2015 17:53, Fábio Telles Rodriguez
 fabio.tel...@gmail.com escreveu:
 
  Em 13 de julho de 2015 11:44, Lucas Viecelli lviecelli...@gmail.com
  escreveu:
 
  Bom dia.
 
  Estou estudando formas de automatizar de uma maneira mais confiável os
  backup de uma base de dados postgres-9.4
 
  As necessidades são:
  -Backups incrementais a cada uma hora.(Existem diversos softwares de
  terceiros que utilizam a base, por isso 1 hora)
  -3 Backups completos durante o dia.
  -Salvar em outra máquina da rede.
 
 
  Lucas, é melhor você conhecer o conceito de Point In Time Recovery antes
 de
  continuar. Acho que você está pensando numa abordagem estilo Dump. Não
 faz
  sentido fazer um backup a cada uma hora.
 
  Veja o artigo: http://savepoint.blog.br/dump-nao-e-backup/
 
  Entenda o que é uma política de backup. Depois voltamos a conversar. Acho
  que vale à pena.
 
 
 
 
  O que mais atende as minhas necessidades é o PgBarman[1], queria saber
  sobre o que vocês utilizam para esse tipo de necessidade, se existem
  outras ferramentas.
 
   Se alguém tem alguns tutoriais para ajudar no estudo e implementação,
  será de grande ajuda.
 
  O sistema operacional é o Fedora, e a base de dados é pequena 20GB.
 
  1 - http://www.pgbarman.org/
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 
 
 
 
  --
  Atenciosamente,
  Fábio Telles Rodriguez
  blog: http://savepoint.blog.br
  e-mail / gtalk / MSN: fabio.tel...@gmail.com
  Skype: fabio_telles
 
  Timbira - A empresa brasileira de Postgres
  http://www.timbira.com.br
 
  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
 



 --
 Atenciosamente.

 Lucas Viecelli
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup incremental

[Fábio Telles Rodriguez]

Em 14 de julho de 2015 09:02, Cleiton Luiz Domazak cleitondoma...@gmail.com
 escreveu:



 Em 14 de julho de 2015 08:21, Lucas Viecelli lviecelli...@gmail.com
 escreveu:

 Obrigado pelas respostas pessoal.

 Sobre as politicas de backups escritas no seu artigo, achei todas
 fundamentais e estou analisando a forma de implementar elas ou pelo
 menos discutir com meus superiores, que por sinal é um ótimo artigo.

 Sobre backups contra fatos desconhecidos e inesperados, acho que estou
 protegido, mas isso não é uma certeza ainda.

 A minha necessidade nesse momento realmente é Point In Time
 Recovery, verifiquei que existem outras ferramentas que fazem esse
 trabalho além do PgBarman, e existe a forma de fazer isso nativamente,
 utilizando os famosos WAL, agora preciso ver se vale a pena usar uma
 ferramenta ou tentar fazer isso utilizando os recursos do próprio
 postgres.


 Eu utilizo o pgBarman e funciona muito bem, muito fácil de configurar e
 até o momento se mostrou confiável. Além do PITR você pode pensar em um
 servidor replica, que pode ser uma solução muito rápida de restore em
 caso de falhas físicas do seu servidor Master.


Acho o pgBarman uma ferramenta interessante se você  administra vários
servidores Postgres, se tem um só em produção, então o pg_basebackup é mais
do que suficiente para você.

http://www.postgresql.org/docs/9.5/static/app-pgbasebackup.html

-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// http://www.midstorm.org/~telles/s
http://tellesr.wordpress.com/avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

Timbira - A empresa brasileira de Postgres
http://www.timbira.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup incremental

[Lucas Viecelli]

Pessoal vou ler e avaliar todas as situações propostas, obrigado por
compartilhar o conhecimento e a experiencia de vocês, qualquer outra
dúvida eu volto a postar.

Em 14 de julho de 2015 19:07, Fábio Telles Rodriguez
fabio.tel...@gmail.com escreveu:


 Em 14 de julho de 2015 09:02, Cleiton Luiz Domazak
 cleitondoma...@gmail.com escreveu:



 Em 14 de julho de 2015 08:21, Lucas Viecelli lviecelli...@gmail.com
 escreveu:

 Obrigado pelas respostas pessoal.

 Sobre as politicas de backups escritas no seu artigo, achei todas
 fundamentais e estou analisando a forma de implementar elas ou pelo
 menos discutir com meus superiores, que por sinal é um ótimo artigo.

 Sobre backups contra fatos desconhecidos e inesperados, acho que estou
 protegido, mas isso não é uma certeza ainda.

 A minha necessidade nesse momento realmente é Point In Time
 Recovery, verifiquei que existem outras ferramentas que fazem esse
 trabalho além do PgBarman, e existe a forma de fazer isso nativamente,
 utilizando os famosos WAL, agora preciso ver se vale a pena usar uma
 ferramenta ou tentar fazer isso utilizando os recursos do próprio
 postgres.


 Eu utilizo o pgBarman e funciona muito bem, muito fácil de configurar e
 até o momento se mostrou confiável. Além do PITR você pode pensar em um
 servidor replica, que pode ser uma solução muito rápida de restore em caso
 de falhas físicas do seu servidor Master.


 Acho o pgBarman uma ferramenta interessante se você  administra vários
 servidores Postgres, se tem um só em produção, então o pg_basebackup é mais
 do que suficiente para você.

 http://www.postgresql.org/docs/9.5/static/app-pgbasebackup.html

 --
 Atenciosamente,
 Fábio Telles Rodriguez
 blog: http://savepoint.blog.br
 e-mail / gtalk / MSN: fabio.tel...@gmail.com
 Skype: fabio_telles

 Timbira - A empresa brasileira de Postgres
 http://www.timbira.com.br

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente.

Lucas Viecelli
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup incremental

[Glauco Torres]

 O que mais atende as minhas necessidades é o PgBarman[1], queria saber
 sobre o que vocês utilizam para esse tipo de necessidade, se existem
 outras ferramentas.

  Se alguém tem alguns tutoriais para ajudar no estudo e implementação,
 será de grande ajuda.


 1 - http://www.pgbarman.org/
 ___



Boa Tarde,

Usei como fonte de aprendizado um tutorial do Juliano Atanazio [1] e a
própria documentação do Barman [2].


[1] http://pt.slideshare.net/spjuliano/pgbarman-juliano-atanazio
[2] http://docs.pgbarman.org/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup incremental

[Fábio Telles Rodriguez]

Em 13 de julho de 2015 11:44, Lucas Viecelli lviecelli...@gmail.com
escreveu:

 Bom dia.

 Estou estudando formas de automatizar de uma maneira mais confiável os
 backup de uma base de dados postgres-9.4

 As necessidades são:
 -Backups incrementais a cada uma hora.(Existem diversos softwares de
 terceiros que utilizam a base, por isso 1 hora)
 -3 Backups completos durante o dia.
 -Salvar em outra máquina da rede.


Lucas, é melhor você conhecer o conceito de Point In Time Recovery antes de
continuar. Acho que você está pensando numa abordagem estilo Dump. Não faz
sentido fazer um backup a cada uma hora.

Veja o artigo: http://savepoint.blog.br/dump-nao-e-backup/

Entenda o que é uma política de backup. Depois voltamos a conversar. Acho
que vale à pena.




 O que mais atende as minhas necessidades é o PgBarman[1], queria saber
 sobre o que vocês utilizam para esse tipo de necessidade, se existem
 outras ferramentas.

  Se alguém tem alguns tutoriais para ajudar no estudo e implementação,
 será de grande ajuda.

 O sistema operacional é o Fedora, e a base de dados é pequena 20GB.

 1 - http://www.pgbarman.org/
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// http://www.midstorm.org/~telles/s
http://tellesr.wordpress.com/avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

Timbira - A empresa brasileira de Postgres
http://www.timbira.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup- Point in Time Recovery

[Matheus de Oliveira]

On Thu, Feb 12, 2015 at 4:07 PM, Eduardo Rodrigues edua...@ookle.com.br
wrote:

 gostaria de saber se posso  configurar o recurso de backup incremental
 (PITR) em um servidor slave de um ambiente com o streaming replication
 implementado?

 Em meu ambiente utilizo dois servidores PostgreSQL 9.2.2 configurados com
 streaming replication, estou tentando realizar o backup online a partir do
 servidor slave. Quando executo o comando select pg_stop_backup(); é
 apresentado o seguinte erro:


Não é possível executar as funções pg_start_backup/pg_stop_backup num slave
e nem fazer archiving a partir do mesmo.

O que você pode fazer (a partir da 9.2) é usar o pg_basebackup [1] para
realizar o backup base ou usar os métodos descritos em [2]. E quanto ao
arquivamento, você pode simplesmente fazer no master, se quiser fazer pelo
slave você pode usar o pg_receivexlog [3].

[1] http://www.postgresql.org/docs/9.2/static/app-pgbasebackup.html
[2] https://wiki.postgresql.org/wiki/Incrementally_Updated_Backups
[3] http://www.postgresql.org/docs/9.2/static/app-pgreceivexlog.html

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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup- Point in Time Recovery

[Eduardo Rodrigues]

Obrigado pela ajuda Matheus, 

estou implantando o Bácula para realizar o backup do banco de dados,
irei utilizar as dicas que você passou para implantar uma politica de
backup.

Eduardo Rodrigues

On Qui, 2015-02-12 at 16:21 -0200, Matheus de Oliveira wrote:
 
 
 On Thu, Feb 12, 2015 at 4:07 PM, Eduardo Rodrigues
 edua...@ookle.com.br wrote:
 
 gostaria de saber se posso  configurar o recurso de backup
 incremental (PITR) em um servidor slave de um ambiente com o
 streaming replication implementado?
 
 Em meu ambiente utilizo dois servidores PostgreSQL 9.2.2
 configurados com streaming replication, estou tentando
 realizar o backup online a partir do servidor slave. Quando
 executo o comando select pg_stop_backup(); é apresentado o
 seguinte erro:
 
 
 
 Não é possível executar as funções pg_start_backup/pg_stop_backup num
 slave e nem fazer archiving a partir do mesmo.
 
 O que você pode fazer (a partir da 9.2) é usar o pg_basebackup [1]
 para realizar o backup base ou usar os métodos descritos em [2]. E
 quanto ao arquivamento, você pode simplesmente fazer no master, se
 quiser fazer pelo slave você pode usar o pg_receivexlog [3].
 
 
 [1] http://www.postgresql.org/docs/9.2/static/app-pgbasebackup.html
 [2] https://wiki.postgresql.org/wiki/Incrementally_Updated_Backups
 [3] http://www.postgresql.org/docs/9.2/static/app-pgreceivexlog.html
 
 
 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
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup | Restore | PITR

[Fabrízio de Royes Mello]

On 28-10-2014 17:51, Matheus de Oliveira wrote:
 2014-10-28 17:10 GMT-02:00 Danilo Silva danilo.dsg.go...@gmail.com:
 
 Agora me surgiu uma dúvida. Como controlo corretamente os arquivos que
 posso apagar do diretório pg_xlog após a conclusão do pg_stop_backup() ?


 Se o comando especificado no archive_command estiver funcionando, o
 Postgres mesmo irá eliminar os arquivos do pg_xlog.


 Meu xará já explicou, mas só para ser mais enfático:
 
 NUNCA! NUNCA! EM HIPÓTESE ALGUMA! JAMAIS PENSEM EM
 REMOVER/EDITAR/RENOMEAR/WHATEVER QUALQUER ARQUIVO DENTRO DO DIRETÓRIO
 pg_xlog
 
 O pg_xlog é gerenciado pelo próprio PostgreSQL, você só pode
 remover/editar/renomear/whatever os arquivos dentro do diretório onde está
 salvando os logs arquivados (apontado pelo archive_command).
 

Não apenas no pg_xlog, mas também em qualquer arquivo/diretório do
cluster, com exceção dos arquivos de configuração (postgresql.conf e
pg_hba.conf) e no pg_log onde armazena logs de atividade, caso vc tenha
configurado dessa forma.

O resto deve ser INTOCÁVEL, a não ser que vc tenha muita certeza do
que está fazendo... :-)


-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup | Restore | PITR

[Sebastian Webber]

2014-10-28 17:51 GMT-02:00 Matheus de Oliveira matioli.math...@gmail.com:


 NUNCA! NUNCA! EM HIPÓTESE ALGUMA! JAMAIS PENSEM EM
 REMOVER/EDITAR/RENOMEAR/WHATEVER QUALQUER ARQUIVO DENTRO DO DIRETÓRIO
 pg_xlog


Isso é tão verdade, que podia virar uma camiseta! :D

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup | Restore | PITR

[Jean Pereira]

Bom dia,

Sugiro a leitura do livro Instant PostgreSQL Backup and Restore 
How-to, gostei muito do mesmo, e além do que já foi recomendado aqui na 
lista também.



On 10/28/2014 08:44 AM, Fernando Cambiaghi wrote:

Bom dia Pessoal,

Sou novo na lista, tenho acompanhado alguns emails e fico 
impressionado com a dedicação do pessoal em responder a todas as 
questões com o nível incrível de detalhe. Parabéns.


Fiz um curso na Dextra em SP a uns dois anos, e estou trabalhando para 
migrar um banco de dado X para PostgreSQL. ( Estou utilizando 
windows 7 com versão 9.3.5 do PostgreSQL.


O tamanho da minha base de dados é relativamente pequena ( 231 tabelas 
ocupando um total entre 4GB e 5GB ).


Pois bem, a migração do bando está feita ( Homologando ), e agora 
estou me apegando a entender a parte de Backup e Restore, mas estou 
tendo muita dificuldade, mas creio que por falta de entendimento meu.


No meu ambiente atual, faço backup completo do banco de dados todas as 
noites, com o banco online e em uso, e tenho o log de transações para, 
em caso de catástrofe*, posso pegar o último backup completo e aplicar 
o log atual ( Tem todo um processo de transcrever e ler o mesmo para o 
banco ).



Com o PostgreSQL, entendi que para ter um ambiente igual, para em caso 
de catástrofe poder recuperar os dados para o mais atual possível, eu 
devo efetuar um backup completo diariamente ( estou fazendo isso com o 
pg_dump ) e manter os archives ativados [1]. Até aí creio que fiz tudo 
certo.


Para simular uma catástrofe, eu desligo o computador com transações 
ocorrendo no banco, e quando ligo novamente, não consigo nem subir o 
serviço do postgres, aí é que começo a apanhar.


Desinstalo e reinstalo o postgres, mesma versão, volto o backup 
(pg_restore) e sigo as instruções de [1], mas não consigo. Quando digo 
não consigo, é estou fazendo algo errado, não volta os archives.


Gostaria de saber se alguém tem um passo a passo mais detalhado de 
como fazer isso, pois não quero colocar o banco postgres em produção 
sem ter domínio de como restaurar um backup em caso de problemas.


[1] http://www.postgresql.org/docs/9.3/static/continuous-archiving.html

*Qualquer tipo de perda de dados ou do próprio banco de dados.

Perdoem por me alongar tanto, mas queria apresentar minha situação e 
apresentação ao grupo.


Agradeço a todos pela compreensão.

Fernando Luís Cambiaghi
/cambia...@gmail.com mailto:cambia...@gmail.com/



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup | Restore | PITR

[Thiago Haroldo]

Bom dia Fernando.

Sempre que seu banco PostgreSQL der problema, entre no Event Viwer do
windows e verifique o log do banco de dados... Sempre vai ter um log que
vai lhe ajudar a resolver seu problema.




Em 28 de outubro de 2014 08:44, Fernando Cambiaghi cambia...@gmail.com
escreveu:

 Bom dia Pessoal,

 Sou novo na lista, tenho acompanhado alguns emails e fico impressionado
 com a dedicação do pessoal em responder a todas as questões com o nível
 incrível de detalhe. Parabéns.

 Fiz um curso na Dextra em SP a uns dois anos, e estou trabalhando para
 migrar um banco de dado X para PostgreSQL. ( Estou utilizando windows 7
 com versão 9.3.5 do PostgreSQL.

 O tamanho da minha base de dados é relativamente pequena ( 231 tabelas
 ocupando um total entre 4GB e 5GB ).

 Pois bem, a migração do bando está feita ( Homologando ), e agora estou me
 apegando a entender a parte de Backup e Restore, mas estou tendo muita
 dificuldade, mas creio que por falta de entendimento meu.

 No meu ambiente atual, faço backup completo do banco de dados todas as
 noites, com o banco online e em uso, e tenho o log de transações para, em
 caso de catástrofe*, posso pegar o último backup completo e aplicar o log
 atual ( Tem todo um processo de transcrever e ler o mesmo para o banco ).


 Com o PostgreSQL, entendi que para ter um ambiente igual, para em caso de
 catástrofe poder recuperar os dados para o mais atual possível, eu devo
 efetuar um backup completo diariamente ( estou fazendo isso com o pg_dump )
 e manter os archives ativados [1]. Até aí creio que fiz tudo certo.

 Para simular uma catástrofe, eu desligo o computador com transações
 ocorrendo no banco, e quando ligo novamente, não consigo nem subir o
 serviço do postgres, aí é que começo a apanhar.

 Desinstalo e reinstalo o postgres, mesma versão, volto o backup
 (pg_restore) e sigo as instruções de [1], mas não consigo. Quando digo não
 consigo, é estou fazendo algo errado, não volta os archives.

 Gostaria de saber se alguém tem um passo a passo mais detalhado de como
 fazer isso, pois não quero colocar o banco postgres em produção sem ter
 domínio de como restaurar um backup em caso de problemas.

 [1] http://www.postgresql.org/docs/9.3/static/continuous-archiving.html

 *Qualquer tipo de perda de dados ou do próprio banco de dados.

 Perdoem por me alongar tanto, mas queria apresentar minha situação e
 apresentação ao grupo.

 Agradeço a todos pela compreensão.

 Fernando Luís Cambiaghi
 *cambia...@gmail.com cambia...@gmail.com*

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup | Restore | PITR

[Matheus Ricardo Espanhol]

Bom dia Fernando,

Com o PostgreSQL, entendi que para ter um ambiente igual, para em caso de
 catástrofe poder recuperar os dados para o mais atual possível, eu devo
 efetuar um backup completo diariamente ( estou fazendo isso com o pg_dump )
 e manter os archives ativados [1]. Até aí creio que fiz tudo certo.


Acho que o erro está nesse ponto. O backup completo diário com pg_dump não
pode ser usado junto com os archive logs. Para restaurar o banco no estado
mais atual possível, além de utilizar o arquivamento de logs de transação,
é preciso executar o backup base, descrito na seção 24.3.3 do link que você
está seguindo [1].

É recomendado ter as 2 opções de backup (pg_dump e archive). Para restaurar:

pg_dump - pg_restore
archive- backup base + archive logs

[1] http://www.postgresql.org/docs/9.3/static/continuous-archiving.html
[2] http://www.postgresql.org/docs/9.3/static/app-pgbasebackup.html


-- 
Matheus Ricardo Espanhol
---
Dextra Sistemas
http://www.dextra.com.br/postgres
www.pganalytics.io
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup | Restore | PITR

[Fernando Cambiaghi]

Matheus, obrigado pela resposta, eu estava mesmo combinando os tipos de
backup e restore errados. Gostaria de parabenizá-lo aqui no grupo pelo
Webinar sobre PgAnalytics, eu participei e achei muito bom.

Thiago, obrigado pela ajuda, com sua dica o restore funcionou perfeitamente
de forma simples demais.

Jean, vou dar uma olhada neste livro assim que possível, agradeço a atenção.

Agora me surgiu uma dúvida. Como controlo corretamente os arquivos que
posso apagar do diretório pg_xlog após a conclusão do pg_stop_backup() ?

Agradeço muito a colaboração dada por todos.



Fernando Luís Cambiaghi
*cambia...@gmail.com cambia...@gmail.com*

Em 28 de outubro de 2014 09:16, Matheus Ricardo Espanhol 
matheusespan...@gmail.com escreveu:

 Bom dia Fernando,

 Com o PostgreSQL, entendi que para ter um ambiente igual, para em caso de
 catástrofe poder recuperar os dados para o mais atual possível, eu devo
 efetuar um backup completo diariamente ( estou fazendo isso com o pg_dump )
 e manter os archives ativados [1]. Até aí creio que fiz tudo certo.


 Acho que o erro está nesse ponto. O backup completo diário com pg_dump não
 pode ser usado junto com os archive logs. Para restaurar o banco no estado
 mais atual possível, além de utilizar o arquivamento de logs de transação,
 é preciso executar o backup base, descrito na seção 24.3.3 do link que você
 está seguindo [1].

 É recomendado ter as 2 opções de backup (pg_dump e archive). Para
 restaurar:

 pg_dump - pg_restore
 archive- backup base + archive logs

 [1] http://www.postgresql.org/docs/9.3/static/continuous-archiving.html
 [2] http://www.postgresql.org/docs/9.3/static/app-pgbasebackup.html


 --
 Matheus Ricardo Espanhol
 ---
 Dextra Sistemas
 http://www.dextra.com.br/postgres
 www.pganalytics.io

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup | Restore | PITR

[Matheus Ricardo Espanhol]

Em 28 de outubro de 2014 11:17, Fernando Cambiaghi cambia...@gmail.com
escreveu:

 Matheus, obrigado pela resposta, eu estava mesmo combinando os tipos de
 backup e restore errados. Gostaria de parabenizá-lo aqui no grupo pelo
 Webinar sobre PgAnalytics, eu participei e achei muito bom.


Obrigado Fernando,



 Agora me surgiu uma dúvida. Como controlo corretamente os arquivos que
 posso apagar do diretório pg_xlog após a conclusão do pg_stop_backup() ?


Se o comando especificado no archive_command estiver funcionando, o
Postgres mesmo irá eliminar os arquivos do pg_xlog. Mas para eliminar os
arquivos antigos de backup (destino do archive_command) você deve renovar o
backup base antes de remover archive logs anteriores. O pg_archivecleanup
te ajuda com isso:

http://www.postgresql.org/docs/9.3/static/pgarchivecleanup.html


-- 
Matheus Ricardo Espanhol
---
Dextra Sistemas
http://www.dextra.com.br/postgres
www.pganalytics.io
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup | Restore | PITR

[Danilo Silva]

Em 28 de outubro de 2014 13:24, Matheus Ricardo Espanhol 
matheusespan...@gmail.com escreveu:


 Em 28 de outubro de 2014 11:17, Fernando Cambiaghi cambia...@gmail.com
 escreveu:

 Matheus, obrigado pela resposta, eu estava mesmo combinando os tipos de
 backup e restore errados. Gostaria de parabenizá-lo aqui no grupo pelo
 Webinar sobre PgAnalytics, eu participei e achei muito bom.


 Obrigado Fernando,



 Agora me surgiu uma dúvida. Como controlo corretamente os arquivos que
 posso apagar do diretório pg_xlog após a conclusão do pg_stop_backup() ?


 Se o comando especificado no archive_command estiver funcionando, o
 Postgres mesmo irá eliminar os arquivos do pg_xlog. Mas para eliminar os
 arquivos antigos de backup (destino do archive_command) você deve renovar o
 backup base antes de remover archive logs anteriores. O pg_archivecleanup
 te ajuda com isso:

 http://www.postgresql.org/docs/9.3/static/pgarchivecleanup.html


​Matheus, aproveitando o gancho...

Digamos que o meu archive_command esteja setado para o diretório
/archives/, se eu utilizar o pg_archivecleanup nesse diretório​

​como ele saberá quais arquivos devem ser excluídos? O utilitário irá
apagar todos os arquivos anteriores ao último basebackup?

[]s
Danilo​
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup | Restore | PITR

[Matheus de Oliveira]

2014-10-28 17:10 GMT-02:00 Danilo Silva danilo.dsg.go...@gmail.com:

 Agora me surgiu uma dúvida. Como controlo corretamente os arquivos que
 posso apagar do diretório pg_xlog após a conclusão do pg_stop_backup() ?


 Se o comando especificado no archive_command estiver funcionando, o
 Postgres mesmo irá eliminar os arquivos do pg_xlog.


Meu xará já explicou, mas só para ser mais enfático:

NUNCA! NUNCA! EM HIPÓTESE ALGUMA! JAMAIS PENSEM EM
REMOVER/EDITAR/RENOMEAR/WHATEVER QUALQUER ARQUIVO DENTRO DO DIRETÓRIO
pg_xlog

O pg_xlog é gerenciado pelo próprio PostgreSQL, você só pode
remover/editar/renomear/whatever os arquivos dentro do diretório onde está
salvando os logs arquivados (apontado pelo archive_command).





 ​Matheus, aproveitando o gancho...

 Digamos que o meu archive_command esteja setado para o diretório
 /archives/, se eu utilizar o pg_archivecleanup nesse diretório​

 ​como ele saberá quais arquivos devem ser excluídos? O utilitário irá
 apagar todos os arquivos anteriores ao último basebackup?


Não fará, o pg_archivecleanup espera que você passe para ele qual o
segmento que deve permanecer. Há algumas formas de saber, uma delas é
procurar pelo arquivo que tem o final .backup, o número dele indica o
primeiro arquivo necessário para restauração do basebackup de quando ele
foi executado (se quiser mais informações como a data/hora, veja o conteúdo
deste arquivo, ele é textual). A outra opção é pegar o retorno da chamada
do pg_start_backup (por exemplo: SELECT
pg_xlogfile_name(pg_start_backup('label', true)) ). Eu costumo salvar junto
com o backup base essa informação (e outras como a data/hora), daí eu
consigo saber exatamente qual manter.

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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup fisico

[William Felipe Welter]

Em 19/09/2014 22:54, Danilo Silva danilo.dsg.go...@gmail.com escreveu:

 Pessoal,

 Atualmente eu tenho apenas uma database criada, onde foi definida uma
tablespace.

 No caso do backup físico, eu tenho que copiar o $PGDATA + o diretório da
tablespace?
Sim


 Como seria o restore desse backup físico?
Depende:
-se fez este  backup com o banco parado, basta inicializar com o pg_ctl
apontando para o diretório onde esta o pgdata do backup
- se fez o backup a quente (com o banco online), precisar ter configurado o
PITR (habilitar arquivamento do wal, pg_start/stop_backup..). Neste caso
para restaurar é necessário criar o arquivo recovery.conf no diretorio do
pgdata e nele apontar para o diretório onde os wal estão arquivados, por
fim iniciar o banco.

 O pg_basebackup serve também para efetuarmos o backup físico?
Sim, e ele ja inclui as tablespaces.

Se não conhece muito sobre PITR, recomendo dar uma lida na documentação
antes realizar os procedimentos em prod.

 []s
 Danilo

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico a quente

[Matheus de Oliveira]

2013/9/2 Danilo Silva danilo.dsg.go...@gmail.com




 Em 31 de agosto de 2013 08:54, Matheus de Oliveira 
 matioli.math...@gmail.com escreveu:




 2013/8/30 Danilo Silva danilo.dsg.go...@gmail.com


 [...]

  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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico a quente

[Danilo Silva]

Em 31 de agosto de 2013 08:54, Matheus de Oliveira 
matioli.math...@gmail.com escreveu:




 2013/8/30 Danilo Silva danilo.dsg.go...@gmail.com


 [...]

  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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico a quente

[Matheus de Oliveira]

2013/8/30 Danilo Silva danilo.dsg.go...@gmail.com


 [...]

  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%.

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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico a quente

[Danilo Silva]

Em 23 de agosto de 2013 17:24, Danilo Silva
danilo.dsg.go...@gmail.comescreveu:




 Em 23 de agosto de 2013 16:11, Matheus de Oliveira 
 matioli.math...@gmail.com escreveu:



 2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com

 Em 23 de agosto de 2013 13:32, Matheus de Oliveira 
 matioli.math...@gmail.com escreveu:



 2013/8/23 Flavio Henrique Araque Gurgel fla...@4linux.com.br


 Em 23-08-2013 13:01, Matheus de Oliveira escreveu:


 2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com
 mailto:danilo.dsg.gomes@**gmail.com danilo.dsg.go...@gmail.com


 Pessoal,

 Considerando a lacuna entre o pg_start_backup e o pg_stop_backup,
 qual parâmetro do postgresql.conf eu devo aumentar para o postgres
 manter os arquivos de log (pg_xlog) antes de reciclá-los? seria o
 wal_keep_segments?


 IIRC, quando você executa o pg_start_backup, o PostgreSQL irá manter
 os
 logs de transação independente da quantidade, até que seja executado o
 pg_stop_backup, além disso, só irá liberar a chamada do
 pg_stop_backup
 quando todos os logs de transação até sua chamada já tenham sido
 arquivados (por isso o pg_stop_backup dá uma travadinha as vezes).


 Opa, opa!
 Não não.
 O PostgreSQL *não* faz isso.


 Ok. Foi mal... Dessa vez a expressão do IIRC foi falsa... =P

 Não lembrava com relação à arquivamento desabilitado, pois não é um
 cenário comum (ao menos pra mim).


 A pergunta original tem uma resposta verdadeira: o parâmetro
 wal_keep_segments é quem diz quantos segmentos extras devem ser 
 armazenados
 após arquivados pelo archive_command ou reciclados após checkpoint.


 No case de um backup base, não me parece uma boa estratégia confiar no
 wal_keep_segments, seria melhor confiar no arquivamento. Mesmo que seja
 para ativar o arquivamento temporariamente durante o backup.


 Se o PostgreSQL guardasse em pg_xlog todos os logs de transação entre
 pg_start/stop_backup seria praticamente impossível calcular um espaço
 consumido pelo diretório pg_xlog.


 Praticamente? Seria realmente impossível. É claro que pode-se ter uma
 estimativa baseado no tamanho do PGDATA e no histórico.




  De qualquer forma, se você tiver o arquivamento de logs de transação
 ativos, você não tem que se preocupar com isso de qualquer forma, ao
 menos que queira um basebackup sem os archives.


 Esta frase está ok ;)


 Blz. Daí vem a pergunta ao Marcelo. Está fazendo um base backup *sem*
 ter arquivamento habilitado? Qual o motivo?


 O arquivamento não está habilitado (em um servidor teste, somente
 alteramos wal_level = archive para testar a rotina que irá efetuar a
 cópia). Atualmente não existe nenhuma política de backup e/ou dump, devemos
 analisar todo o ambiente, pois quando se tenta efetuar um dump (a base é
 pequena, possui em torno de 40 GB), a aplicação trava, creio que seja por
 conta dos acessos/transações, que são muitos mas ainda não temos um número
 exato.


 xiii mas se diz que já está verificando, ok... =D

 Eu, particularmente, recomendaria você tentar o pg_dump pelo menos em
 horários de menor uso.


  Imagino que, para uma situação emergencial, uma cópia da base
 resolveria temporariamente, mas fico preocupado com essa lacuna entre o
 start/backup, ou será que dado a situação atual, devemos confiar apenas em
 ter os dados até o momento em que se iniciou a cópia?


 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.

 []s
 Danilo

 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 

Re: [pgbr-geral] Backup físico a quente

[Matheus de Oliveira]

2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com

 Pessoal,

 Considerando a lacuna entre o pg_start_backup e o pg_stop_backup, qual
 parâmetro do postgresql.conf eu devo aumentar para o postgres manter os
 arquivos de log (pg_xlog) antes de reciclá-los? seria o wal_keep_segments?


IIRC, quando você executa o pg_start_backup, o PostgreSQL irá manter os
logs de transação independente da quantidade, até que seja executado o
pg_stop_backup, além disso, só irá liberar a chamada do pg_stop_backup
quando todos os logs de transação até sua chamada já tenham sido arquivados
(por isso o pg_stop_backup dá uma travadinha as vezes).

De qualquer forma, se você tiver o arquivamento de logs de transação
ativos, você não tem que se preocupar com isso de qualquer forma, ao menos
que queira um basebackup sem os archives.

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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico a quente

[Flavio Henrique Araque Gurgel]

Em 23-08-2013 13:01, Matheus de Oliveira escreveu:


2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com
mailto:danilo.dsg.go...@gmail.com

Pessoal,

Considerando a lacuna entre o pg_start_backup e o pg_stop_backup,
qual parâmetro do postgresql.conf eu devo aumentar para o postgres
manter os arquivos de log (pg_xlog) antes de reciclá-los? seria o
wal_keep_segments?


IIRC, quando você executa o pg_start_backup, o PostgreSQL irá manter os
logs de transação independente da quantidade, até que seja executado o
pg_stop_backup, além disso, só irá liberar a chamada do pg_stop_backup
quando todos os logs de transação até sua chamada já tenham sido
arquivados (por isso o pg_stop_backup dá uma travadinha as vezes).


Opa, opa!
Não não.
O PostgreSQL *não* faz isso.

A pergunta original tem uma resposta verdadeira: o parâmetro 
wal_keep_segments é quem diz quantos segmentos extras devem ser 
armazenados após arquivados pelo archive_command ou reciclados após 
checkpoint.


Se o PostgreSQL guardasse em pg_xlog todos os logs de transação entre 
pg_start/stop_backup seria praticamente impossível calcular um espaço 
consumido pelo diretório pg_xlog.




De qualquer forma, se você tiver o arquivamento de logs de transação
ativos, você não tem que se preocupar com isso de qualquer forma, ao
menos que queira um basebackup sem os archives.


Esta frase está ok ;)

[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico a quente

[Matheus de Oliveira]

2013/8/23 Flavio Henrique Araque Gurgel fla...@4linux.com.br


 Em 23-08-2013 13:01, Matheus de Oliveira escreveu:


 2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com
 mailto:danilo.dsg.gomes@**gmail.com danilo.dsg.go...@gmail.com


 Pessoal,

 Considerando a lacuna entre o pg_start_backup e o pg_stop_backup,
 qual parâmetro do postgresql.conf eu devo aumentar para o postgres
 manter os arquivos de log (pg_xlog) antes de reciclá-los? seria o
 wal_keep_segments?


 IIRC, quando você executa o pg_start_backup, o PostgreSQL irá manter os
 logs de transação independente da quantidade, até que seja executado o
 pg_stop_backup, além disso, só irá liberar a chamada do pg_stop_backup
 quando todos os logs de transação até sua chamada já tenham sido
 arquivados (por isso o pg_stop_backup dá uma travadinha as vezes).


 Opa, opa!
 Não não.
 O PostgreSQL *não* faz isso.


Ok. Foi mal... Dessa vez a expressão do IIRC foi falsa... =P

Não lembrava com relação à arquivamento desabilitado, pois não é um cenário
comum (ao menos pra mim).


A pergunta original tem uma resposta verdadeira: o parâmetro
 wal_keep_segments é quem diz quantos segmentos extras devem ser armazenados
 após arquivados pelo archive_command ou reciclados após checkpoint.


No case de um backup base, não me parece uma boa estratégia confiar no
wal_keep_segments, seria melhor confiar no arquivamento. Mesmo que seja
para ativar o arquivamento temporariamente durante o backup.


Se o PostgreSQL guardasse em pg_xlog todos os logs de transação entre
 pg_start/stop_backup seria praticamente impossível calcular um espaço
 consumido pelo diretório pg_xlog.


Praticamente? Seria realmente impossível. É claro que pode-se ter uma
estimativa baseado no tamanho do PGDATA e no histórico.




  De qualquer forma, se você tiver o arquivamento de logs de transação
 ativos, você não tem que se preocupar com isso de qualquer forma, ao
 menos que queira um basebackup sem os archives.


 Esta frase está ok ;)


Blz. Daí vem a pergunta ao Marcelo. Está fazendo um base backup *sem* ter
arquivamento habilitado? Qual o motivo?

OBS: A única situação onde haja um bom motivo que consigo pensar agora é
para sincronizar um slave, o que também dá pra aliar ao arquivamento, por
isso pensei no arquivamento temporário.

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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico a quente

[Danilo Silva]

Em 23 de agosto de 2013 13:32, Matheus de Oliveira 
matioli.math...@gmail.com escreveu:



 2013/8/23 Flavio Henrique Araque Gurgel fla...@4linux.com.br


 Em 23-08-2013 13:01, Matheus de Oliveira escreveu:


 2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com
 mailto:danilo.dsg.gomes@**gmail.com danilo.dsg.go...@gmail.com


 Pessoal,

 Considerando a lacuna entre o pg_start_backup e o pg_stop_backup,
 qual parâmetro do postgresql.conf eu devo aumentar para o postgres
 manter os arquivos de log (pg_xlog) antes de reciclá-los? seria o
 wal_keep_segments?


 IIRC, quando você executa o pg_start_backup, o PostgreSQL irá manter os
 logs de transação independente da quantidade, até que seja executado o
 pg_stop_backup, além disso, só irá liberar a chamada do pg_stop_backup
 quando todos os logs de transação até sua chamada já tenham sido
 arquivados (por isso o pg_stop_backup dá uma travadinha as vezes).


 Opa, opa!
 Não não.
 O PostgreSQL *não* faz isso.


 Ok. Foi mal... Dessa vez a expressão do IIRC foi falsa... =P

 Não lembrava com relação à arquivamento desabilitado, pois não é um
 cenário comum (ao menos pra mim).


 A pergunta original tem uma resposta verdadeira: o parâmetro
 wal_keep_segments é quem diz quantos segmentos extras devem ser armazenados
 após arquivados pelo archive_command ou reciclados após checkpoint.


 No case de um backup base, não me parece uma boa estratégia confiar no
 wal_keep_segments, seria melhor confiar no arquivamento. Mesmo que seja
 para ativar o arquivamento temporariamente durante o backup.


 Se o PostgreSQL guardasse em pg_xlog todos os logs de transação entre
 pg_start/stop_backup seria praticamente impossível calcular um espaço
 consumido pelo diretório pg_xlog.


 Praticamente? Seria realmente impossível. É claro que pode-se ter uma
 estimativa baseado no tamanho do PGDATA e no histórico.




  De qualquer forma, se você tiver o arquivamento de logs de transação
 ativos, você não tem que se preocupar com isso de qualquer forma, ao
 menos que queira um basebackup sem os archives.


 Esta frase está ok ;)


 Blz. Daí vem a pergunta ao Marcelo. Está fazendo um base backup *sem* ter
 arquivamento habilitado? Qual o motivo?


O arquivamento não está habilitado (em um servidor teste, somente alteramos
wal_level = archive para testar a rotina que irá efetuar a cópia).
Atualmente não existe nenhuma política de backup e/ou dump, devemos
analisar todo o ambiente, pois quando se tenta efetuar um dump (a base é
pequena, possui em torno de 40 GB), a aplicação trava, creio que seja por
conta dos acessos/transações, que são muitos mas ainda não temos um número
exato.

Imagino que, para uma situação emergencial, uma cópia da base resolveria
temporariamente, mas fico preocupado com essa lacuna entre o start/backup,
ou será que dado a situação atual, devemos confiar apenas em ter os dados
até o momento em que se iniciou a cópia?

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

Re: [pgbr-geral] Backup físico a quente

[Guimarães Faria Corcete DUTRA , Leandro]

2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com:

 O arquivamento não está habilitado (em um servidor teste, somente alteramos
 wal_level = archive para testar a rotina que irá efetuar a cópia).
 Atualmente não existe nenhuma política de backup e/ou dump, devemos analisar
 todo o ambiente, pois quando se tenta efetuar um dump (a base é pequena,
 possui em torno de 40 GB), a aplicação trava, creio que seja por conta dos
 acessos/transações, que são muitos mas ainda não temos um número exato.

Não sei se entendi… estás sem arquivamento *e* sem /dump/ em produção
ou em teste?

Que tal diagnosticar esse problema do /dump/?


 Imagino que, para uma situação emergencial, uma cópia da base resolveria
 temporariamente, mas fico preocupado com essa lacuna entre o start/backup,
 ou será que dado a situação atual, devemos confiar apenas em ter os dados
 até o momento em que se iniciou a cópia?

Não entendi que seria essa lacuna…
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico a quente

[Danilo Silva]

Em 23 de agosto de 2013 14:19, Guimarães Faria Corcete DUTRA, Leandro 
l...@dutras.org escreveu:

 2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com:
 
  O arquivamento não está habilitado (em um servidor teste, somente
 alteramos
  wal_level = archive para testar a rotina que irá efetuar a cópia).
  Atualmente não existe nenhuma política de backup e/ou dump, devemos
 analisar
  todo o ambiente, pois quando se tenta efetuar um dump (a base é pequena,
  possui em torno de 40 GB), a aplicação trava, creio que seja por conta
 dos
  acessos/transações, que são muitos mas ainda não temos um número exato.

 Não sei se entendi… estás sem arquivamento *e* sem /dump/ em produção
 ou em teste?

 Que tal diagnosticar esse problema do /dump/?


Já está na planilha de tarefas.



  Imagino que, para uma situação emergencial, uma cópia da base resolveria
  temporariamente, mas fico preocupado com essa lacuna entre o
 start/backup,
  ou será que dado a situação atual, devemos confiar apenas em ter os dados
  até o momento em que se iniciou a cópia?

 Não entendi que seria essa lacuna…

 Das transações efetuadas durante a cópia, digamos que a cópia leve 30
minutos para ser efetuada, suponho que ficarei com o meu banco
desatualizado por conta desses 30 minutos e das possíveis transações que
possam ter ocorridos.

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

Re: [pgbr-geral] Backup físico a quente

[Guimarães Faria Corcete DUTRA , Leandro]

2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com:
 Das transações efetuadas durante a cópia, digamos que a cópia leve 30
 minutos para ser efetuada, suponho que ficarei com o meu banco desatualizado
 por conta desses 30 minutos e das possíveis transações que possam ter
 ocorridos.

Por isso os registros de transações… certo?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico a quente

[Danilo Silva]

Em 23 de agosto de 2013 14:28, Guimarães Faria Corcete DUTRA, Leandro 
l...@dutras.org escreveu:

 2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com:
  Das transações efetuadas durante a cópia, digamos que a cópia leve 30
  minutos para ser efetuada, suponho que ficarei com o meu banco
 desatualizado
  por conta desses 30 minutos e das possíveis transações que possam ter
  ocorridos.

 Por isso os registros de transações… certo?

 Correto?

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

Re: [pgbr-geral] Backup físico a quente

[Danilo Silva]

Em 23 de agosto de 2013 14:44, Danilo Silva
danilo.dsg.go...@gmail.comescreveu:




 Em 23 de agosto de 2013 14:28, Guimarães Faria Corcete DUTRA, Leandro 
 l...@dutras.org escreveu:

 2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com:
  Das transações efetuadas durante a cópia, digamos que a cópia leve 30
  minutos para ser efetuada, suponho que ficarei com o meu banco
 desatualizado
  por conta desses 30 minutos e das possíveis transações que possam ter
  ocorridos.

 Por isso os registros de transações… certo?

 Correto?

 []s
 Danilo

 Ops. quiz dizer que sim, está correto.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico a quente

[Matheus de Oliveira]

2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com

 Em 23 de agosto de 2013 13:32, Matheus de Oliveira 
 matioli.math...@gmail.com escreveu:



 2013/8/23 Flavio Henrique Araque Gurgel fla...@4linux.com.br


 Em 23-08-2013 13:01, Matheus de Oliveira escreveu:


 2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com
 mailto:danilo.dsg.gomes@**gmail.com danilo.dsg.go...@gmail.com


 Pessoal,

 Considerando a lacuna entre o pg_start_backup e o pg_stop_backup,
 qual parâmetro do postgresql.conf eu devo aumentar para o postgres
 manter os arquivos de log (pg_xlog) antes de reciclá-los? seria o
 wal_keep_segments?


 IIRC, quando você executa o pg_start_backup, o PostgreSQL irá manter os
 logs de transação independente da quantidade, até que seja executado o
 pg_stop_backup, além disso, só irá liberar a chamada do pg_stop_backup
 quando todos os logs de transação até sua chamada já tenham sido
 arquivados (por isso o pg_stop_backup dá uma travadinha as vezes).


 Opa, opa!
 Não não.
 O PostgreSQL *não* faz isso.


 Ok. Foi mal... Dessa vez a expressão do IIRC foi falsa... =P

 Não lembrava com relação à arquivamento desabilitado, pois não é um
 cenário comum (ao menos pra mim).


 A pergunta original tem uma resposta verdadeira: o parâmetro
 wal_keep_segments é quem diz quantos segmentos extras devem ser armazenados
 após arquivados pelo archive_command ou reciclados após checkpoint.


 No case de um backup base, não me parece uma boa estratégia confiar no
 wal_keep_segments, seria melhor confiar no arquivamento. Mesmo que seja
 para ativar o arquivamento temporariamente durante o backup.


 Se o PostgreSQL guardasse em pg_xlog todos os logs de transação entre
 pg_start/stop_backup seria praticamente impossível calcular um espaço
 consumido pelo diretório pg_xlog.


 Praticamente? Seria realmente impossível. É claro que pode-se ter uma
 estimativa baseado no tamanho do PGDATA e no histórico.




  De qualquer forma, se você tiver o arquivamento de logs de transação
 ativos, você não tem que se preocupar com isso de qualquer forma, ao
 menos que queira um basebackup sem os archives.


 Esta frase está ok ;)


 Blz. Daí vem a pergunta ao Marcelo. Está fazendo um base backup *sem* ter
 arquivamento habilitado? Qual o motivo?


 O arquivamento não está habilitado (em um servidor teste, somente
 alteramos wal_level = archive para testar a rotina que irá efetuar a
 cópia). Atualmente não existe nenhuma política de backup e/ou dump, devemos
 analisar todo o ambiente, pois quando se tenta efetuar um dump (a base é
 pequena, possui em torno de 40 GB), a aplicação trava, creio que seja por
 conta dos acessos/transações, que são muitos mas ainda não temos um número
 exato.


xiii mas se diz que já está verificando, ok... =D

Eu, particularmente, recomendaria você tentar o pg_dump pelo menos em
horários de menor uso.


 Imagino que, para uma situação emergencial, uma cópia da base resolveria
 temporariamente, mas fico preocupado com essa lacuna entre o start/backup,
 ou será que dado a situação atual, devemos confiar apenas em ter os dados
 até o momento em que se iniciou a cópia?


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...

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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico a quente

[Danilo Silva]

Em 23 de agosto de 2013 16:11, Matheus de Oliveira 
matioli.math...@gmail.com escreveu:



 2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com

 Em 23 de agosto de 2013 13:32, Matheus de Oliveira 
 matioli.math...@gmail.com escreveu:



 2013/8/23 Flavio Henrique Araque Gurgel fla...@4linux.com.br


 Em 23-08-2013 13:01, Matheus de Oliveira escreveu:


 2013/8/23 Danilo Silva danilo.dsg.go...@gmail.com
 mailto:danilo.dsg.gomes@**gmail.com danilo.dsg.go...@gmail.com


 Pessoal,

 Considerando a lacuna entre o pg_start_backup e o pg_stop_backup,
 qual parâmetro do postgresql.conf eu devo aumentar para o postgres
 manter os arquivos de log (pg_xlog) antes de reciclá-los? seria o
 wal_keep_segments?


 IIRC, quando você executa o pg_start_backup, o PostgreSQL irá manter os
 logs de transação independente da quantidade, até que seja executado o
 pg_stop_backup, além disso, só irá liberar a chamada do
 pg_stop_backup
 quando todos os logs de transação até sua chamada já tenham sido
 arquivados (por isso o pg_stop_backup dá uma travadinha as vezes).


 Opa, opa!
 Não não.
 O PostgreSQL *não* faz isso.


 Ok. Foi mal... Dessa vez a expressão do IIRC foi falsa... =P

 Não lembrava com relação à arquivamento desabilitado, pois não é um
 cenário comum (ao menos pra mim).


 A pergunta original tem uma resposta verdadeira: o parâmetro
 wal_keep_segments é quem diz quantos segmentos extras devem ser armazenados
 após arquivados pelo archive_command ou reciclados após checkpoint.


 No case de um backup base, não me parece uma boa estratégia confiar no
 wal_keep_segments, seria melhor confiar no arquivamento. Mesmo que seja
 para ativar o arquivamento temporariamente durante o backup.


 Se o PostgreSQL guardasse em pg_xlog todos os logs de transação entre
 pg_start/stop_backup seria praticamente impossível calcular um espaço
 consumido pelo diretório pg_xlog.


 Praticamente? Seria realmente impossível. É claro que pode-se ter uma
 estimativa baseado no tamanho do PGDATA e no histórico.




  De qualquer forma, se você tiver o arquivamento de logs de transação
 ativos, você não tem que se preocupar com isso de qualquer forma, ao
 menos que queira um basebackup sem os archives.


 Esta frase está ok ;)


 Blz. Daí vem a pergunta ao Marcelo. Está fazendo um base backup *sem*
 ter arquivamento habilitado? Qual o motivo?


 O arquivamento não está habilitado (em um servidor teste, somente
 alteramos wal_level = archive para testar a rotina que irá efetuar a
 cópia). Atualmente não existe nenhuma política de backup e/ou dump, devemos
 analisar todo o ambiente, pois quando se tenta efetuar um dump (a base é
 pequena, possui em torno de 40 GB), a aplicação trava, creio que seja por
 conta dos acessos/transações, que são muitos mas ainda não temos um número
 exato.


 xiii mas se diz que já está verificando, ok... =D

 Eu, particularmente, recomendaria você tentar o pg_dump pelo menos em
 horários de menor uso.


 Imagino que, para uma situação emergencial, uma cópia da base resolveria
 temporariamente, mas fico preocupado com essa lacuna entre o start/backup,
 ou será que dado a situação atual, devemos confiar apenas em ter os dados
 até o momento em que se iniciou a cópia?


 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.

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

Re: [pgbr-geral] Backup Alessandro...

[Alessandro Lima]

Surgiu outra dúvida:
Fazendo a replicação streaming assincrona em outro servidor, basta a versão
do postgres (master e slave) ser 9.2 ou tem que ser exatamente a mesma
9.2.4 por exemplo ?

Atenciosamente,

Alessandro Lima
email grandegoia...@gmail.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Alessandro...

[Euler Taveira]

On 13-06-2013 16:37, Alessandro Lima wrote:
 Fazendo a replicação streaming assincrona em outro servidor, basta a
 versão do postgres (master e slave) ser 9.2 ou tem que ser exatamente a
 mesma 9.2.4 por exemplo ?
 
Qualquer versão corretiva da 9.2, porém, o aconselhável é *sempre*
deixar o servidor secundário com uma versão corretiva igual ou superior
a do servidor principal (caso alguma correção venha afetar a aplicação
dos logs de transação, o servidor secundário saberá como lidar com ela),
ou seja, se o servidor principal está com a 9.2.2, o servidor secundário
deve estar com 9.2.4 ou pelo menos a 9.2.2 mas evite deixá-lo na 9.2.0.
Então, se vai atualizar uma versão corretiva, primeiro atualize os
servidores secundários e então o servidor principal.


PS da próxima vez utilize um título mais sugestivo.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Alessandro...

[Alessandro Lima]

Muito obrigado pela ajuda, sempre rápida e eficiente.

Desculpe pelo título, esqueci de colocar o assunto quando iniciei este
tópico.

Atenciosamente,

Alessandro Lima
email grandegoia...@gmail.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Alessandro...

[Claudio Bezerra Leopoldino]

Bom dia, Alessandro!

Coloco algumas ideias 

Se você deseja uma replicação síncrona, utilizar um segundo servidor de 
qualidade inferior vai degradar a performance do sistema como um todo.


O hd externo geralmente não apresenta um bom desempenho para operações com 
grande quantidade de dados. Se precisares, utilize ao menos USB 3.0. Mas não 
recomendo. Você pode cogitar uma ferramenta de backup e recovery com compressão 
de dados como: pgbarman (http://www.pgbarman.org/) e pg-rman 
(http://code.google.com/p/pg-rman/).


O backup é muito útil quando se deseja recuperar um estado anterior do banco. E 
como não podemos antever esta necessidade, a replicação não tem como eliminar 
totalmente a necessidade de backup.

Cordialmente,

 
Cláudio Leopoldino
postgresqlbr.blogspot.com/
=



 De: Alessandro Lima grandegoia...@gmail.com
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br 
Enviadas: Quarta-feira, 12 de Junho de 2013 9:10
Assunto: [pgbr-geral] (sem assunto)
 


Bom dia a todos, gostaria de algumas dicas (boas praticas), sobre backup, 
replicação, etc...

obs.: Utilizarei postgres 9.2, debian 7, servidor dell (ainda em fase de 
cotação)

Minha idéia inicial seria:

RAID 1 ( 2 x 600GB SAS 15k - servidor dell t4200)
Replicação (MASTER - servidor dell, SLAVE - servidor usado ibm)

Backup online

Backup em hd externo
Backup remoto nos estados unidos

Dúvidas: 
1- Nunca fiz replicação no postgres, o slave pode ser um computador inferior 
com sata, não interfere na performance do master com sas?
2 - a replicação substitui a necessidade do backup online?
3 - o que é recomendado armazenar em hd externo ou servidor remoto, uma cópia 
da pasta data, um pg_dump, uma cópia do backup online?



Alessandro Lima
email grandegoia...@gmail.com

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Alessandro...

[Douglas Fabiano Specht]

Em 12 de junho de 2013 09:32, Claudio Bezerra Leopoldino 
claudiob...@yahoo.com.br escreveu:


 Bom dia, Alessandro!

 Coloco algumas ideias

 Se você deseja uma replicação síncrona, utilizar um segundo servidor de
 qualidade inferior vai degradar a performance do sistema como um todo.

 O hd externo geralmente não apresenta um bom desempenho para operações com
 grande quantidade de dados. Se precisares, utilize ao menos USB 3.0. Mas
 não recomendo. Você pode cogitar uma ferramenta de backup e recovery com
 compressão de dados como: pgbarman (http://www.pgbarman.org/) e pg-rman (
 http://code.google.com/p/pg-rman/).

 O backup é muito útil quando se deseja recuperar um estado anterior do
 banco. E como não podemos antever esta necessidade, a replicação não tem
 como eliminar totalmente a necessidade de backup.

 Cordialmente,

 Cláudio Leopoldino
 postgresqlbr.blogspot.com/
 =
   --
  *De:* Alessandro Lima grandegoia...@gmail.com
 *Para:* Comunidade PostgreSQL Brasileira 
 pgbr-geral@listas.postgresql.org.br
 *Enviadas:* Quarta-feira, 12 de Junho de 2013 9:10
 *Assunto:* [pgbr-geral] (sem assunto)

 Bom dia a todos, gostaria de algumas dicas (boas praticas), sobre backup,
 replicação, etc...

 obs.: Utilizarei postgres 9.2, debian 7, servidor dell (ainda em fase de
 cotação)

 Minha idéia inicial seria:

 RAID 1 ( 2 x 600GB SAS 15k - servidor dell t4200)
 Replicação (MASTER - servidor dell, SLAVE - servidor usado ibm)
 Backup online
 Backup em hd externo
 Backup remoto nos estados unidos

 Dúvidas:
 1- Nunca fiz replicação no postgres, o slave pode ser um computador
 inferior com sata, não interfere na performance do master com sas?
 2 - a replicação substitui a necessidade do backup online?
 3 - o que é recomendado armazenar em hd externo ou servidor remoto, uma
 cópia da pasta data, um pg_dump, uma cópia do backup online?


 Alessandro Lima
 email grandegoia...@gmail.com

 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


Bom dia Pessoal,
posso estar errado mas a replicação hot_standby, é ela assincrona, mas com
um pequeno delay, ela é quase sincrona, digamos assim.
Ela irá primeiro gravar local no master para depois no slave, nesse caso
para o slave nao precisaria ter uma super maquina, acho que essa forma de
backup no teu caso cairia bem, veja o tutorial [1] abaixo feita pela 4linux.

[1]
http://www.4linux.com.br/noticias/2013/webcast-tutorial-replicacao-banco-dados-postgresql-92.html

-- 

Douglas Fabiano Specht
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Alessandro...

[Alessandro Lima]

 [1]
http://www.4linux.com.br/noticias/2013/webcast-tutorial-replicacao-banco-dados-postgresql-92.html

Gostei muito deste tutorial, pretendo utilizar replicação assincrona,
mas pesquisando sobre replicação fiquei na dúvida sobre alguns métodos que
encontrei: streaming, slony e pgpool-II

são métodos distintos, se forem, qual a diferença principal entre eles?

Atenciosamente,

Alessandro Lima
email grandegoia...@gmail.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Alessandro...

[Flavio Henrique Araque Gurgel]

Em 12-06-2013 13:58, Alessandro Lima escreveu:

  [1]
http://www.4linux.com.br/noticias/2013/webcast-tutorial-replicacao-banco-dados-postgresql-92.html

Gostei muito deste tutorial, pretendo utilizar replicação assincrona,


Obrigado. Estou feliz que as pessoas tem assistido e recomendado este 
tutorial, deu um trabalho legal fazê-lo.



mas pesquisando sobre replicação fiquei na dúvida sobre alguns métodos
que encontrei: streaming, slony e pgpool-II


Streaming é embutido no PostgreSQL, pode ser síncrono ou assíncrono e 
usa a funcionalidade de Write Ahead Log como base da replicação.


Slony é baseado em triggers e é mais granular, você pode escolher o 
que replicar. Com streaming você só pode replicar o cluster todo, 
conforme o tutorial. Slony só tem modo assíncrono.


pgpool-II permite replicação somente síncrona e baseada em comandos, 
funciona por fora e na frente do PostgreSQL. Cada comando de 
modificação de dados recebida pelo pgpool-II é enviado para todos os 
participantes da replicação.


O pgpool-II pode ser usado como ferramenta auxiliar no controle e 
distribuição de dados para outros métodos de replicação como o streaming 
e o slony.


[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Alessandro...

[Douglas Fabiano Specht]

Em 12 de junho de 2013 14:04, Flavio Henrique Araque Gurgel 
fla...@4linux.com.br escreveu:

 Em 12-06-2013 13:58, Alessandro Lima escreveu:

[1]
 http://www.4linux.com.br/**noticias/2013/webcast-**
 tutorial-replicacao-banco-**dados-postgresql-92.htmlhttp://www.4linux.com.br/noticias/2013/webcast-tutorial-replicacao-banco-dados-postgresql-92.html

 Gostei muito deste tutorial, pretendo utilizar replicação assincrona,


 Obrigado. Estou feliz que as pessoas tem assistido e recomendado este
 tutorial, deu um trabalho legal fazê-lo.


  mas pesquisando sobre replicação fiquei na dúvida sobre alguns métodos
 que encontrei: streaming, slony e pgpool-II


 Streaming é embutido no PostgreSQL, pode ser síncrono ou assíncrono e usa
 a funcionalidade de Write Ahead Log como base da replicação.

 Slony é baseado em triggers e é mais granular, você pode escolher o que
 replicar. Com streaming você só pode replicar o cluster todo, conforme o
 tutorial. Slony só tem modo assíncrono.

 pgpool-II permite replicação somente síncrona e baseada em comandos,
 funciona por fora e na frente do PostgreSQL. Cada comando de
 modificação de dados recebida pelo pgpool-II é enviado para todos os
 participantes da replicação.

 O pgpool-II pode ser usado como ferramenta auxiliar no controle e
 distribuição de dados para outros métodos de replicação como o streaming e
 o slony.

 []s

 __**
 Flavio Henrique A. Gurgel
 Líder de Projetos Especiais
 Consultoria, Projetos  Treinamentos 4LINUX
 Tel1: +55-11.2125-4747 ou 2125-4748
 www.4linux.com.br
 email: fla...@4linux.com.br
 __
 FREE SOFTWARE SOLUTIONS

 __**_
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.**org.brpgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.**br/cgi-bin/mailman/listinfo/**pgbr-geralhttps://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



Alessandro,
se vc utilizar o nativo hot_standby, nao precisa de nenhuma ferramenta
auxiliar.
no teu caso como vc disponibiliza 2 maquinas acho que se seguir 100% o
tutorial da 4linux, estará com um backup sempre atualizado e na minha
opinião seria o mais recomendado.
Claro, alem disso, pense em algo tbm fora da tua rede, como em midia
externa, ou backup em data center, google drive, etc..



-- 

Douglas Fabiano Specht
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Alessandro...

[Euler Taveira]

On 12-06-2013 14:08, Douglas Fabiano Specht wrote:
 no teu caso como vc disponibiliza 2 maquinas acho que se seguir 100% o
 tutorial da 4linux, estará com um backup sempre atualizado e na minha
 opinião seria o mais recomendado.

Replicação != Backup. Não confunda as bolas. Apesar da replicação criar
uma cópia dos dados em outro local:

(i) não há a possibilidade de voltar no tempo onde ocorreu uma perda ou
corrupção dos dados;
(ii) se os dados forem corrompidos no servidor principal, provavelmente
eles também serão no servidor secundário.

O PostgreSQL está tentando atacar o problema (ii) [1] com checksums no
9.3 mas ainda é um estágio embrionário.


[1] http://wiki.postgresql.org/wiki/Corruption_Detection_and_Containment


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Alessandro...

[Alessandro Lima]

 Claro, alem disso, pense em algo tbm fora da tua rede, como em midia
externa, ou backup em data center, google drive, etc..

Pretendo fazer este backup em hd externo e também em outro data center, com
continuous archiving ou pg_rman, seriam estas as melhores formas?


Atenciosamente,

Alessandro Lima
email grandegoia...@gmail.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Dickson S. Guedes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Em 29-05-2013 23:58, Émerson Eng. escreveu:
 Fiquei curioso se o psql também faria backup com algo próximo a
 isso: psql -U user -h host -q base ** base.backup

Isto é uma caracteristica do SO. A saída de um comando enviado para a
saída padrão pode ser capturada e redirecionada (no caso com o  )
para um arquivo, por exemplo, o que permitiria voce criar uma função
no banco que, uma vez executada, emularia o que o pg_dump faz.


[]s
- -- 
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
http://github.net/guedes - twitter: @guediz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJRp23jAAoJEBa5zL7BI5C7y8wH/0bv7UtESIIfcZCnqtrJn5Bp
mGIqJVMKGlEpFVO+HOchiyD0HI1Kpo0gAWng9I46qeNGvjCoO5d4AjBifNTCTeRr
lR6RXcw0sie4Ol8Hk1ywfiollnzmuNO1+vdL+18cPZbpB2Bhubw2O1NdGzTSRPiV
ONsHyQGhioK5LoBMv9mwcrVNcGOONpJUTM5pXIqzkhLM5y1CRD2yBru9FHyecQCP
T5ldB1uZjIaDZWCfVexXFOFoaupLqdikTIGQh2I+C5VbgXWVUZ0eYSLZUwUd7m3y
g6Sas+3VyJbnW3g1+BDFVgaQv7OYvAcZMYGY25LZnhbeByAKQS6MAbm21k09o04=
=970u
-END PGP SIGNATURE-
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Juliano Atanazio]

Em 29 de maio de 2013 13:47, Émerson Eng. emersonnar...@gmail.comescreveu:

 Olá,

 Existe um modo de se fazer backup pelo psql com algo como
 psql -U user -h host -q base  base.backup;

 Não posso usar pg_dump[all].


pg_dump --help



 Desde já obrigado.


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Osvaldo Kussama]

Em 29/05/13, Émerson Eng.emersonnar...@gmail.com escreveu:
 Olá,

 Existe um modo de se fazer backup pelo psql com algo como
 psql -U user -h host -q base  base.backup;

 Não posso usar pg_dump[all].



Sem entrar no mérito da razão de você não poder usar o pg_dump[all], e
considerando que você deseja um back-up lógico, a alternativa que
resta é o COPY TO [1] de cada uma das tabelas de seu banco.

Osvaldo

[1] http://www.postgresql.org/docs/current/interactive/sql-copy.html
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Matheus de Oliveira]

2013/5/29 Émerson Eng. emersonnar...@gmail.com

 Olá,

 Existe um modo de se fazer backup pelo psql com algo como
 psql -U user -h host -q base  base.backup;


Sim. Você pode fazer cada COPY e pegar o esquema a partir do catálogo. Vale
a pena esse trampo todo?



 Não posso usar pg_dump[all].


Desculpe, mas vou ter que perguntar: por quê?


-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Bruno Silva]

Ou pode copiar direto a pasta de dados.


Bruno E. A. Silva.
Analista de Sistemas.
Bacharel em Sistemas de Informação
Pós-graduando em Gerência de Projetos
Certified Scrum Master
LPIC-1
SCJP, SE 6
Novell CLA / DCTS ECR
DBA Postgres
---
“A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” -
Sábio Desconhecido
Alguns prestam serviço/consultoria de Qualidade, os outros vendem licença!


2013/5/29 Matheus de Oliveira matioli.math...@gmail.com


 2013/5/29 Émerson Eng. emersonnar...@gmail.com

 Olá,

 Existe um modo de se fazer backup pelo psql com algo como
 psql -U user -h host -q base  base.backup;


 Sim. Você pode fazer cada COPY e pegar o esquema a partir do catálogo.
 Vale a pena esse trampo todo?



 Não posso usar pg_dump[all].


 Desculpe, mas vou ter que perguntar: por quê?


 --
 Matheus de Oliveira
 Analista de Banco de Dados
 Dextra Sistemas - MPS.Br nível F!
 www.dextra.com.br/postgres


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Juliano Atanazio]

Em 29 de maio de 2013 13:47, Émerson Eng. emersonnar...@gmail.comescreveu:

 Olá,

 Boa tarde.


 Existe um modo de se fazer backup pelo psql com algo como

psql -U user -h host -q base  base.backup;


O utilitário psql não é para este fim.
No seu caso, vc quer fazer dump de uma base de dados apenas?
Se assim for pg_dump é o cara:

pg_dump -U user -h host database  arquivo_de_saida.sql

Que também pode ser feito com a opção -C que faz o CREATE DATABASE no
dump:

pg_dump  -U user -h host -C database  arquivo_de_saida.sql



 Não posso usar pg_dump[all].


Por quê não? Se o que vc quer é o dump do cluster, ele vai ser o cara.

[]s



 Desde já obrigado.


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Matheus de Oliveira]

2013/5/29 Bruno Silva bemanuel...@gmail.com

 Ou pode copiar direto a pasta de dados.



Se o cara não pode usar o pg_dump (sabe-se lá porque!), não é possível que
tenha acesso a pasta de dados!!! É?!

At.
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Bruno Silva]

Não sei, ele não deu informações. E não ter possibilidade de uso do pg_dump
não implica no fato de não ter acesso à pasta.

Bruno E. A. Silva.
Analista de Sistemas.
Bacharel em Sistemas de Informação
Pós-graduando em Gerência de Projetos
Certified Scrum Master
LPIC-1
SCJP, SE 6
Novell CLA / DCTS ECR
DBA Postgres
---
“A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” -
Sábio Desconhecido
Alguns prestam serviço/consultoria de Qualidade, os outros vendem licença!


2013/5/29 Matheus de Oliveira matioli.math...@gmail.com




 2013/5/29 Bruno Silva bemanuel...@gmail.com

 Ou pode copiar direto a pasta de dados.



 Se o cara não pode usar o pg_dump (sabe-se lá porque!), não é possível que
 tenha acesso a pasta de dados!!! É?!

 At.
 --
 Matheus de Oliveira
 Analista de Banco de Dados
 Dextra Sistemas - MPS.Br nível F!
 www.dextra.com.br/postgres


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Émerson Eng .]

Não é que não posso usar o pg_dump, só me despertou essa curiosidade pela
interface leitura de arquivos dele usar  para importar.

Obrigado a todos pelas respostas.



--


2013/5/29 Bruno Silva bemanuel...@gmail.com

 Não sei, ele não deu informações. E não ter possibilidade de uso do
 pg_dump não implica no fato de não ter acesso à pasta.

 Bruno E. A. Silva.
 Analista de Sistemas.
 Bacharel em Sistemas de Informação
 Pós-graduando em Gerência de Projetos
 Certified Scrum Master
 LPIC-1
 SCJP, SE 6
 Novell CLA / DCTS ECR
 DBA Postgres
 ---
 “A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” -
 Sábio Desconhecido
 Alguns prestam serviço/consultoria de Qualidade, os outros vendem
 licença!


 2013/5/29 Matheus de Oliveira matioli.math...@gmail.com




 2013/5/29 Bruno Silva bemanuel...@gmail.com

 Ou pode copiar direto a pasta de dados.



 Se o cara não pode usar o pg_dump (sabe-se lá porque!), não é possível
 que tenha acesso a pasta de dados!!! É?!

 At.
 --
 Matheus de Oliveira
 Analista de Banco de Dados
 Dextra Sistemas - MPS.Br nível F!
 www.dextra.com.br/postgres


 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Osvaldo Kussama]

Em 29/05/13, Émerson Eng.emersonnar...@gmail.com escreveu:
 Não é que não posso usar o pg_dump, só me despertou essa curiosidade pela
 interface leitura de arquivos dele usar  para importar.


Eu não consegui entender o que você quiz dizer com a frase acima. De
qualquer maneira aconselho a leitura do manual:
http://www.postgresql.org/docs/current/interactive/app-pgdump.html
http://www.postgresql.org/docs/current/interactive/app-pgrestore.html
http://www.postgresql.org/docs/current/interactive/app-pg-dumpall.html
http://www.postgresql.org/docs/current/interactive/app-psql.html

Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Émerson Eng .]

Eu uso o pg_dump e pg_restore regularmente.
O que eu quiz dizer é que a interface do psql dentre outras coisas permite
restaurar uma base assim:
psql -U user -h host -q base ** base.backup

Fiquei curioso se o psql também faria backup com algo próximo a isso:
psql -U user -h host -q base ** base.backup



--


On Wed, May 29, 2013 at 11:52 PM, Osvaldo Kussama osvaldo.kuss...@gmail.com
 wrote:

 Em 29/05/13, Émerson Eng.emersonnar...@gmail.com escreveu:
  Não é que não posso usar o pg_dump, só me despertou essa curiosidade pela
  interface leitura de arquivos dele usar  para importar.
 

 Eu não consegui entender o que você quiz dizer com a frase acima. De
 qualquer maneira aconselho a leitura do manual:
 http://www.postgresql.org/docs/current/interactive/app-pgdump.html
 http://www.postgresql.org/docs/current/interactive/app-pgrestore.html
 http://www.postgresql.org/docs/current/interactive/app-pg-dumpall.html
 http://www.postgresql.org/docs/current/interactive/app-psql.html

 Osvaldo
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] backup com psql

[Osvaldo Kussama]

Em 29/05/13, Émerson Eng.emersonnar...@gmail.com escreveu:
 Eu uso o pg_dump e pg_restore regularmente.
 O que eu quiz dizer é que a interface do psql dentre outras coisas permite
 restaurar uma base assim:
 psql -U user -h host -q base ** base.backup

 Fiquei curioso se o psql também faria backup com algo próximo a isso:
 psql -U user -h host -q base ** base.backup



Mas
psql -U user -h host -q base  base.backup
é praticamente equivalente a
psql -U user -h host -q base -f base.backup

Do manual:
-f filename
--file=filename

Use the file filename as the source of commands instead of reading
commands interactively. After the file is processed, psql terminates.
This is in many ways equivalent to the meta-command \i.

If filename is - (hyphen), then standard input is read.

Using this option is subtly different from writing psql 
filename. In general, both will do what you expect, but using -f
enables some nice features such as error messages with line numbers.
There is also a slight chance that using this option will reduce the
start-up overhead. On the other hand, the variant using the shell's
input redirection is (in theory) guaranteed to yield exactly the same
output you would have received had you entered everything by hand.

Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup feito pelo cliente

[JotaComm]

Opa,




Em 10 de maio de 2013 09:54, Fabiano fabianocosta...@yahoo.com.brescreveu:

 Pessoal,
 Alguem conhece alguma ferramenta ou forma que o próprio cliente realizar o
 backup de uma aplicação web de forma bem amigável?


A pergunta é: Por que o cliente quer fazer isso? Ele sabe dos riscos?

O backup que você fala é o pg_dump?

Que tal deixar uma tarefa agendada que execute o backup regularmente e
compartilhe este backup em uma área que ele tenha acesso?

Outra opção é usar o pg_admin ou ainda você criar um executável para que
ele simplesmente precise rodar.


 Agradeço sugestões.

 Att,
 Fabiano
 __**_
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.**org.brpgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.**br/cgi-bin/mailman/listinfo/**pgbr-geralhttps://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



Abraços
-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Postgres 8.4.12

[Fábio Gibon]

Em 18 de dezembro de 2012 16:03, Josivan Laskoski josiv...@gmail.comescreveu:


 Boa tarde Galera,

 Estou tentando fazer backup de uma base de um sistema de terceiro, onde a
 versao é 8.4.12, e toda vez que tento fazer esse bkp me gera esse erro:

 pg_dump: server version: 8.4.12; pg_dump version: 8.3.0
 pg_dump: proceeding despite version mismatch
 pg_dump: SQL command failed
 pg_dump: Error message from server: ERRO:  coluna reltriggers não existe
 LINE 1: ...oles WHERE oid = relowner) as rolname, relchecks, reltrigger...
  ^

Usa um pg_dump da 8.4 que deve resolver...


-- 
sds

Fábio
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Postgres 8.4.12

[Flavio Henrique Araque Gurgel]

Estou tentando fazer backup de uma base de um sistema de terceiro, onde a 
versao é 8.4.12, e toda vez que tento fazer esse bkp me gera esse erro: 

 pg_dump: server version: 8.4.12; pg_dump version: 8.3.0 
 pg_dump: proceeding despite version mismatch 
 pg_dump: SQL command failed 
 pg_dump: Error message from server: ERRO: coluna reltriggers não existe 
(...)
 Alguem sabe pq que ocorre esse erro de select? 

Porque você está usando uma versão mais nova do pg_dump para um servidor mais 
antigo.
A versão 8.4 do pg_dump tinha algumas incompatibilidades com o PostgreSQL 8.3

A partir da versão 9.0 do pg_dump ele é version aware e se ajusta. Procure 
usar o pg_dump da versão 8.3 ou 9.0 ou superior (ou seja, no seu caso, evita o 
pg_dump da versão 8.4).

[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Postgres 8.4.12

[Flavio Henrique Araque Gurgel]

 pg_dump: server version: 8.4.12; pg_dump version: 8.3.0 
 pg_dump: proceeding despite version mismatch 
 pg_dump: SQL command failed 
 pg_dump: Error message from server: ERRO: coluna reltriggers não existe 
 LINE 1: ...oles WHERE oid = relowner) as rolname, relchecks, reltrigger... 

 Usa um pg_dump da 8.4 que deve resolver... 

Nossa, é verdade. Eu respondi exatamente o contrário agora há pouco.
Desculpem a todos.

Ele pode usar o pg_dump 8.4 ou superior, não pode usar pg_dump 8.3 ou mais 
velho.

[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Postgres Não Funciona

[Matheus de Oliveira]

2012/11/23 Éverton Bueno Lima everton_bueno_l...@hotmail.com

 Boa tarde a todos,

 ** **

 Estou tentando criar um bat para realizar o backup do postgres uso a
 versão 9.1.

 Estou criar a linha de comando da seguinte forma

 ** **

 pg_dump –h localhost –p 5432 –U postgres –W senha –Fd nome_do_banco –f
 nome_backup

 ** **

 E não esta realizando o backup do sistema, sempre exibe a mensagem
 (pg_dump: muitos argumentos de linha de comando (primeiro é “-Fd”) Tente
 “pg_dump –help” para obter informações adicionais.

 **


O problema me parece ser o -W senha. Não dá pra passar a senha via
parâmetro, o -W serve para forçar o pg_dump à pedir senha no terminal
(ou seja, você terá que digitá-la).

Se realmente você precisa passar a senha você pode usar a variável de
ambiente PGPASSWORD ou usar o arquivo ~/.pgpass.

Exemplo:

$ export PGPASSWORD=senha
$ pg_dump –h localhost –p 5432 –U postgres –Fd nome_do_banco –f nome_backup

Mais uma coisa: tem certesa que quer usar -Fd? Acho meio incomun.


Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados PostgreSQL
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Postgres Não Funciona

[Osvaldo Kussama]

Em 23/11/12, Éverton Bueno Limaeverton_bueno_l...@hotmail.com escreveu:
 Boa tarde a todos,



 Estou tentando criar um bat para realizar o backup do postgres uso a versão
 9.1.

 Estou criar a linha de comando da seguinte forma



 pg_dump –h localhost –p 5432 –U postgres –W senha –Fd nome_do_banco –f
 nome_backup



 E não esta realizando o backup do sistema, sempre exibe a mensagem
 (pg_dump:
 muitos argumentos de linha de comando (primeiro é “-Fd”) Tente “pg_dump
 –help” para obter informações adicionais.



 Mas até agora não conseguir realizar o backup se alguém tiver passada pela
 mesma situação agradeço a ajuda.




Coloque o nome do banco no final do comando [1].

pg_dump –h localhost –p 5432 –U postgres –W senha –Fd –f nome_backup
nome_do_banco

Osvaldo

[1] http://www.postgresql.org/docs/current/interactive/app-pgdump.html
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup Postgres Não Funciona

[Danilo Silva]

Em 23 de novembro de 2012 12:09, Éverton Bueno Lima 
everton_bueno_l...@hotmail.com escreveu:

 Boa tarde a todos,

 ** **

 Estou tentando criar um bat para realizar o backup do postgres uso a
 versão 9.1.

 Estou criar a linha de comando da seguinte forma

 ** **

 pg_dump –h localhost –p 5432 –U postgres –W senha –Fd nome_do_banco –f
 nome_backup

 ** **

 E não esta realizando o backup do sistema, sempre exibe a mensagem
 (pg_dump: muitos argumentos de linha de comando (primeiro é “-Fd”) Tente
 “pg_dump –help” para obter informações adicionais.

 ** **

 Mas até agora não conseguir realizar o backup se alguém tiver passada pela
 mesma situação agradeço a ajuda.

 ** **

 Não lembro de existir o parâmetro -Fd.

Para especificar o banco usa-se somente -d o parâmetro -F usa-se para
especificar o formato juntamente com o modo -Fc ou -Fp.

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

Re: [pgbr-geral] Backup Postgres Não Funciona

[Danilo Silva]

Em 23 de novembro de 2012 12:26, Danilo Silva
danilo.dsg.go...@gmail.comescreveu:



 Em 23 de novembro de 2012 12:09, Éverton Bueno Lima 
 everton_bueno_l...@hotmail.com escreveu:

 Boa tarde a todos,

 ** **

 Estou tentando criar um bat para realizar o backup do postgres uso a
 versão 9.1.

 Estou criar a linha de comando da seguinte forma

 ** **

 pg_dump –h localhost –p 5432 –U postgres –W senha –Fd nome_do_banco –f
 nome_backup

 ** **

 E não esta realizando o backup do sistema, sempre exibe a mensagem
 (pg_dump: muitos argumentos de linha de comando (primeiro é “-Fd”) Tente
 “pg_dump –help” para obter informações adicionais.

 ** **

 Mas até agora não conseguir realizar o backup se alguém tiver passada
 pela mesma situação agradeço a ajuda.

 ** **

 Não lembro de existir o parâmetro -Fd.

 Para especificar o banco usa-se somente -d o parâmetro -F usa-se para
 especificar o formato juntamente com o modo -Fc ou -Fp.

 []s
 Danilo


Corrigindo,

O parâmetro -Fd existe sim, usa-se para especificar o diretório...

Desculpem-me pelo engano.

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

Re: [pgbr-geral] Backup usuarios e grupos

[Osvaldo Kussama]

Em 30/09/12, Rudimarcorsar...@gmail.com escreveu:
  Olá pessoal,

 como faço backup dos usuários e grupos do banco?  Qual é o melhor
 procedimento para restaurar de forma mais rápida? Agradeço.


Opção --globals-only (ou -g) do pg_dumpall.
http://www.postgresql.org/docs/current/interactive/app-pg-dumpall.html

Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico PITR

[Fabrízio de Royes Mello]

Em 30 de setembro de 2012 21:59, Danilo Silva
danilo.dsg.go...@gmail.comescreveu:

 Pessoal,

 Utilizando o método PITR em um possível desastre, eu devo ter a cópia dos
 logs de transações + o backup físico.


Ok.


Quanto ao backup físico, somente se faz necessário efetuar uma cópia, ou
 seja, não é necessário fazer cópias periodicamente, estou certo ou errado?


Se vc estiver aplicando os logs de transação a um servidor em Standby (ou
Hot-Standby em versoes = 9.0) vc faz uma vez o backup base e deixa
aplicando os logs de transação.

Agora se vc estiver apenas realizando backup físico, então vc precisa ter
em mente que a restauração consistirá em restaurar o backup base e aplicar
os logs de transação após a realização do mesmo, então se vc fez um backup
base no inicio do ano e desde lá vem salvando os logs de transação vc tem
dois problemas:

1) O tamanho do seu backup vai ficar imenso
2) O tempo de restauração pode ficar impraticável

Pensando nesses problemas eu adotaria sim uma estratégia de ter um periodo
entre um backup base e outro (diário, semanal, quinzenal, etc), e claro
entre um backup base e outro vc deve salvar os logs de transação durante.

Não sei se fui claro, mas espero ter ajudado.

Att,

-- 
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Blog sobre TI: http://fabriziomello.blogspot.com
 Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico PITR

[Danilo Silva]

Em 30 de setembro de 2012 22:10, Fabrízio de Royes Mello 
fabriziome...@gmail.com escreveu:

corte


 Pensando nesses problemas eu adotaria sim uma estratégia de ter um periodo
 entre um backup base e outro (diário, semanal, quinzenal, etc), e claro
 entre um backup base e outro vc deve salvar os logs de transação durante.


Por exemplo: efetuar o backup base no começo do mês, e desde então cópia
dos logs. Após 15 dias (apenas como sugestão) efetuar novo backup base e
desconsiderar o backup base antigo junto com a cópia dos logs. Digo isso
apenas se eu não quiser voltar no tempo, pois o método PITR é justamente o
contrário.



 Não sei se fui claro, mas espero ter ajudado.


Acho que mais claro que isso impossível, valeu, ajudou e muito.

[]s
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup físico PITR

[Fabrízio de Royes Mello]

Em 30 de setembro de 2012 22:23, Danilo Silva
danilo.dsg.go...@gmail.comescreveu:


 Por exemplo: efetuar o backup base no começo do mês, e desde então cópia
 dos logs. Após 15 dias (apenas como sugestão) efetuar novo backup base e
 desconsiderar o backup base antigo junto com a cópia dos logs. Digo isso
 apenas se eu não quiser voltar no tempo, pois o método PITR é justamente o
 contrário.



Pode ser sim... mas a primeira pergunta que vc tem que responder é no caso
de uma indisponibilidade do seu servidor e vc precisar usar o backup,
quanto tempo vc pode ficar parado esperando o mesmo ser restaurado?... e
isso depende muito do seu volume diário de transações, e para descobrir vc
vai ter que medir testando sua restauração. Já tive vários cenários desse
tipo fazendo backup desde diário até quinzenal e até mensal (esses dois
últimos menos usados)... normalmente eu faço backup base semanal e em
clientes com mais volume faço 2x por semana... mas isso vai depender do seu
cenário e na resposta aquela pergunta.



 Acho que mais claro que isso impossível, valeu, ajudou e muito.


De nada...

Att,

-- 
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Blog sobre TI: http://fabriziomello.blogspot.com
 Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup banco.

[Flavio Henrique Araque Gurgel]

On 26-09-2012 08:09, Pedro B. Alves wrote:
 Pessoal, venho até aqui pedir um pouco da experiencia de nossos colegas.

 Minha situação é a senguinte, tenho um banco de dados onde eu gravo
 imagens em campos Bytea.


 Gostaria, se possível, que me ajudassem a montar a rotina de
 backup/restore desta base.

 PG 8.4

Primeiro leia e entenda:
http://softwarelivre.org/telles/blog/dump-nao-e-backup

Depois a documentação:
http://www.postgresql.org/docs/8.4/static/backup-dump.html
http://www.postgresql.org/docs/8.4/static/continuous-archiving.html

[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup banco.

[Bruno Silva]

2012/9/26 Fábio Telles Rodriguez fabio.tel...@gmail.com:
 2012/9/26 Flavio Henrique Araque Gurgel fla...@4linux.com.br

 On 26-09-2012 08:09, Pedro B. Alves wrote:
  Pessoal, venho até aqui pedir um pouco da experiencia de nossos colegas.
 
  Minha situação é a senguinte, tenho um banco de dados onde eu gravo
  imagens em campos Bytea.


 Se você tem muitas imagens em Bytea na base, o Dump pode se tornar inviável.
 Já vi bases ficarem dias gerando dump e o resultado é um dump maior que a
 base física. Ok, a base tinha milhões de imagens e colocar milhões de
 imagens numa base não é algo inteligente, mas a aplicação não era minha, ok?
  --

Aí o mais indicado não seria a cópia física?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup banco.

[Edson Lidorio]

Olá Fábio Telles,

Qual seria a solução inteligente para o armazenamento de imagens?

Edson

2012/9/26 Bruno Silva bemanuel...@gmail.com

 2012/9/26 Fábio Telles Rodriguez fabio.tel...@gmail.com:
  2012/9/26 Flavio Henrique Araque Gurgel fla...@4linux.com.br
 
  On 26-09-2012 08:09, Pedro B. Alves wrote:
   Pessoal, venho até aqui pedir um pouco da experiencia de nossos
 colegas.
  
   Minha situação é a senguinte, tenho um banco de dados onde eu gravo
   imagens em campos Bytea.
 
 
  Se você tem muitas imagens em Bytea na base, o Dump pode se tornar
 inviável.
  Já vi bases ficarem dias gerando dump e o resultado é um dump maior que a
  base física. Ok, a base tinha milhões de imagens e colocar milhões de
  imagens numa base não é algo inteligente, mas a aplicação não era minha,
 ok?
   --

 Aí o mais indicado não seria a cópia física?
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Backup banco.

[Fabrízio de Royes Mello]

Em 26 de setembro de 2012 11:47, Edson Lidorio edson...@gmail.comescreveu:

 Olá Fábio Telles,

 Qual seria a solução inteligente para o armazenamento de imagens?


Filesystem é uma opção... veja essa apresentação:

http://www.slideshare.net/diogobiazus/arquivos-no-banco

Att,

-- 
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
 Blog sobre TI: http://fabriziomello.blogspot.com
 Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
 Twitter: http://twitter.com/fabriziomello
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral