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

Muchas gracias,

Ha sido de gran ayuda.

Y sólo por curiosidad, cómo incorporais los datos en la "nueva" BBDD, que
se han insertado el la "antigua" BBDD durante el backup/restauración??? Por
nuestro lado, tenemos la possibilidad de "simular" la entrada de datos que
se han producido desde el inicio del backup, pero tengo ciertas dudas
respecto a algunos serializables considerados llave primaria de algunas
tablas.

No se si me explico.

Gracias.

2012/11/2 Cesar Martin <cmartinp(at)gmail(dot)com>

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

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