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ó <[email protected]> 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 <[email protected]> > >> 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ó <[email protected]>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] >>> [email protected]<[email protected]> >>> >>> 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 >> [email protected] >> >> > > > -- > *Ruben Fitó * > Software Engineer > [image: Ubiquat Technologies, SL] [email protected]<[email protected]> > > 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 [email protected]
