Re: [pgsql-es-ayuda] Backup en producción.

Mi BBDD tiene 300GB y varios triggers que rellenan tablas. Lo he
restaurando con dump a un servidor y no ha habido ningún problema a pesar
de que esta insertando datos constantemente.
Eso si, lógicamente, si no cortas el acceso a la BBDD cuando saques el
DUMP, ese dump no va a tener todos los cambios... Normalmente es mejor
cortar el acceso a al BBDD, que perder datos, pero cada caso es distinto.
En cualquier caso, saca el backup en formato binario (-Fc) y restauralo
utilizando la opción --disable-triggers.

Un saludo.

El 2 de noviembre de 2012 11:20, Ruben Fitó <r(dot)fito(at)ubiquat(dot)com> escribió:

> Gracias por responder,
>
> La nueva máquina tendrá la versión 9.1, por lo tanto necesitamos restaurar
> por backup/restore. Según he estado leyendo pg_dump hace el backup de una
> "foto" de la BBDD en el momento que inicia el proceso. Eso me tranquiliza,
> pero como soy un desconfiado, jeje, me gustaria saber si existe algun
> caso(que no sea problema de sistemas) en que el backup contuviera
> inconsistencia de datos.
>
> Mil Gracias.
>
> 2012/11/2 Cesar Martin <cmartinp(at)gmail(dot)com>
>
>> Hola,
>>
>> Si lo vas a pasar a otra maquina, pero vas a mantener la versión de
>> postgres y al menos el mismo tipo de OS sin tener en cuanta la versión, tal
>> vez te salga mas rentable hacer un rsync de la carpeta "data" a la maquina
>> nueva que con una conexión GB debería tardar muy poco.
>> Una vez realizado el primer rsync, lanzas un segundo y un tercero, que
>> veras que van tardando cada vez menos. Cuando el tiempo de copiado, sea muy
>> pequeño, paras la primera BD, haces el ultimo rsync y arrancas la nueva
>> BBDD, levantando la misma IP, etc.
>> Esa forma es la que menos tiempo de interrupción del servicio requiere,
>> al menos que yo sepa.
>>
>> Un saludo.
>>
>> El 2 de noviembre de 2012 09:47, Ruben Fitó <r(dot)fito(at)ubiquat(dot)com>escribió:
>>
>> Hola a todos,
>>>
>>> Tengo una duda respecto al proceso de backup de postgres.
>>>
>>> Tenemos una BBDD 8.3 que se encuentra en producción i siempre estan
>>> entrando transacciones contínuamente. Estas TX, actualizan ciertos campos
>>> de otras tablas con triggers.
>>>
>>> Actualmente, el backup que realizamos és con pg_dumb, por lo tanto nos
>>> genera un "*.sql".
>>>
>>> Ahora hay necesiadad de traspasar la BBDD a otra màquina mas potente.
>>>
>>> La duda que tengo és que, si durante el proceso de backup con pg_dump
>>> (35 min aprox) entran nuevas TX(i lanzan estos triggers) existirà un
>>> problema con la integridad de los datos??, o postgresql crea un "punto de
>>> backup" que hace caso omiso de las nuevas TX???
>>>
>>> Hay alguna diferencia con el problema si lo hacemos en binario,
>>> pg_dump -F c???
>>>
>>> Gracias.
>>>
>>>
>>>
>>>
>>> --
>>> *Ruben Fitó *
>>> Software Engineer
>>> [image: Ubiquat Technologies, SL] r(dot)fito(at)ubiquat(dot)com<j(dot)catarineu(at)ubiquat(dot)com>
>>>
>>> www.ubiquat.com
>>> Tota la informació continguda en aquest document i arxius adjunts és
>>> CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per
>>> error, si us plau elimini'l i posi's en contacte amb l'emissor.
>>>
>>> All information contained in this document and any attachments are
>>> CONFIDENTIAL and protected under trade secret laws. If you receive this
>>> message by mistake, please delete it and notify it immediately to the
>>> sender.
>>>
>>>
>>
>>
>> --
>> César Martín Pérez
>> cmartinp(at)gmail(dot)com
>>
>>
>
>
> --
> *Ruben Fitó *
> Software Engineer
> [image: Ubiquat Technologies, SL] r(dot)fito(at)ubiquat(dot)com<j(dot)catarineu(at)ubiquat(dot)com>
>
> www.ubiquat.com
> Tota la informació continguda en aquest document i arxius adjunts és
> CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per
> error, si us plau elimini'l i posi's en contacte amb l'emissor.
>
> All information contained in this document and any attachments are
> CONFIDENTIAL and protected under trade secret laws. If you receive this
> message by mistake, please delete it and notify it immediately to the
> sender.
>
>

--
César Martín Pérez
cmartinp(at)gmail(dot)com