Re: backup incremental de una base de datos

Mauricio ,Gente

Despues de leer el PITR, me quede pensando como implementar uno de los
requerimientos que seria
poder detectar acciones destructivas como por ej para ser drastico, drop
schema blah o truncate table x.
y se me ocurrieron dos cosas. una poner el logstatement ='all' luego hacer
tail del log con grep y algunas expresiones
regulares capturando estas sentencias (drop, truncate ..etc).
pero lo que todavia no tengpo claro es que accion tomar y como, se me
ocurrio leyendo el PITR que el comando store,storecommand
o algo asi que es parte del PITR podria ser un script bash llmamando al cp.
(cp) y si detecto uno de estos comandos de
destruccion, copiarle otro script del mismo nombre pero que por dentro a)
no copie b) copie a otro direcrtorio que no sea
donde esta el otro motor postgres en modo hold o como se llame.
que les parece?
ideas criticas etc seran biem recibidas
salu2
jmdc

2012/6/26 José González <josego(at)simgia(dot)com>

> Mauricio:
> Si, estoy implementando los PITR. Estoy haciendo pruebas para ver si las
> manejo bien. XD
>
> Haciendo varias pruebas, me hace el restore y funciona, pero en el log me
> sale lo siguiente:
>
> 2012-06-25 19:44:26 PYT LOG: el sistema de bases de datos fue
> interrumpido; ?ltima vez en funcionamiento en 2012-06-25 15:43:44 PYT
> 2012-06-25 19:44:26 PYT LOG: el paquete de inicio est? incompleto
> 2012-06-25 19:44:26 PYT LOG: comenzando proceso de recuperaci?n
> 2012-06-25 19:44:26 PYT LOG: restore_command = 'cp
> /var/backups/postgresql_WAL/%f "%p"'
> 2012-06-25 19:44:26 PYT LOG: recovery_target_time = '2012-06-25
> 16:20:55.332973-04'
> cp: no se puede efectuar `stat' sobre
> <</var/backups/postgresql_WAL/00000001.history>>: No existe el fichero o el
> directorio
> 2012-06-25 19:44:26 PYT LOG: se ha recuperado el archivo
> <<000000010000000000000006.00000020.backup>>
> 2012-06-25 19:44:26 PYT LOG: se ha recuperado el archivo
> <<000000010000000000000006>>
> 2012-06-25 19:44:26 PYT LOG: recuperaci?n autom?tica en curso
> 2012-06-25 19:44:27 PYT FATAL: el sistema de base de datos est?
> inici?ndose
> 2012-06-25 19:44:27 PYT LOG: el redo comienza en 0/6000068, la
> consistencia se alcanzar? en 0/6000088
> 2012-06-25 19:44:27 PYT LOG: el estado de recuperaci?n consistente ha
> sido alcanzado
> 2012-06-25 19:44:27 PYT LOG: se ha recuperado el archivo
> <<000000010000000000000007>>
> 2012-06-25 19:44:27 PYT FATAL: el sistema de base de datos est?
> inici?ndose
> cp: no se puede efectuar `stat' sobre
> <</var/backups/postgresql_WAL/000000010000000000000008>>: No existe el
> fichero o el directorio
> 2012-06-25 19:44:27 PYT LOG: la direcci?n de p?gina 0/3000000 en el
> archivo de registro 0, segmento 8, posici?n 0 es inesperada
> 2012-06-25 19:44:27 PYT LOG: redo listo en 0/7060C88
> 2012-06-25 19:44:27 PYT LOG: ?ltima transacci?n completada al tiempo de
> registro 2012-06-25 16:20:04.963049-04
> 2012-06-25 19:44:27 PYT LOG: se ha recuperado el archivo
> <<000000010000000000000007>>
> 2012-06-25 19:44:27 PYT LOG: se ha recuperado el archivo
> <<00000002.history>>
> 2012-06-25 19:44:27 PYT LOG: se ha recuperado el archivo
> <<00000003.history>>
> 2012-06-25 19:44:27 PYT LOG: se ha recuperado el archivo
> <<00000004.history>>
> 2012-06-25 19:44:27 PYT LOG: se ha recuperado el archivo
> <<00000005.history>>
> cp: no se puede efectuar `stat' sobre
> <</var/backups/postgresql_WAL/00000006.history>>: No existe el fichero o el
> directorio
> 2012-06-25 19:44:27 PYT LOG: seleccionado nuevo ID de timeline: 6
> cp: no se puede efectuar `stat' sobre
> <</var/backups/postgresql_WAL/00000001.history>>: No existe el fichero o el
> directorio
> 2012-06-25 19:44:28 PYT FATAL: el sistema de base de datos est?
> inici?ndose
> 2012-06-25 19:44:28 PYT FATAL: el sistema de base de datos est?
> inici?ndose
> 2012-06-25 19:44:28 PYT LOG: recuperaci?n completa
> 2012-06-25 19:44:29 PYT FATAL: el sistema de base de datos est?
> inici?ndose
> 2012-06-25 19:44:29 PYT FATAL: el sistema de base de datos est?
> inici?ndose
> 2012-06-25 19:44:30 PYT LOG: el sistema de bases de datos est? listo para
> aceptar conexiones
> 2012-06-25 19:44:30 PYT LOG: lanzador de autovacuum iniciado
>
>
> Una de las cosas uqe me salen arriba puede perjudicar al restore..
>
> muchas gracias a todos.
>
> saludos, jose
>
> El 26 de junio de 2012 08:38, felipe guzman <felipeguzmanv(at)gmail(dot)com>escribió:
>
> Guillermo:
>>
>>
>> Como es eso :
>>
>>
>> no hay tablas incrementales, el backup es selectivo en cuanto
>>> a las tablas que resguardo, como se que algunas no sufren cambios
>>> durante un largo periodo no las guardo, (se puede programar el pg_dump
>>> para que se ejecute periodicamente y exceptue todo lo que quieras).
>>>
>>
>> Algun ejemplo esta interesante!
>>
>> Saludos
>>
>>
>> El 26 de junio de 2012 08:11, Mauricio Rafael Rivas Martinez <
>> mrivas10(at)cantv(dot)com(dot)ve> escribió:
>>
>> Buen Dia
>>>
>>> Jose, te recomiendo investigues y acciones de la siguiente forma:
>>>
>>> 1) Trabaja con PITR
>>> 2) Haz backup del data directory con rsync y podras hacerlo incrementales
>>> 3) Clasifica tus bases de datos y separalas para que las bases de datos
>>> dentro de un clusters tengan relación entre ellas y las tareas de restore y
>>> recuperación las afecten a todas por igual, incluso las bd's muy criticas
>>> déjalas solas en un cluster.
>>>
>>>
>>> Mauricio Rivas
>>> Consultor
>>> Proyecto Optimización, Migración y Soporte Interno de Base de Datos
>>> Oracle a Tecnologías Libres (OMS BD ORCL - TIL)
>>> Gerencia de Programa Soluciones de TI
>>> Gerencia General de Proyectos Mayores
>>> Gerencia General de Tecnología y Operaciones
>>> Tel:
>>> Cel: +58-412-392-7447
>>> Email: mrivas10(at)cantv(dot)com(dot)ve
>>>
>>> El 25/06/2012 03:35 p.m., Guillermo Villanueva escribió:
>>>
>>>> No José, no hay tablas incrementales, el backup es selectivo en cuanto
>>>> a las tablas que resguardo, como se que algunas no sufren cambios
>>>> durante un largo periodo no las guardo, (se puede programar el pg_dump
>>>> para que se ejecute periodicamente y exceptue todo lo que quieras).
>>>> Así mi backup diario no es tan grande.
>>>> PITR no me resultaba práctico porque es un backup de todo el motor de
>>>> BD, no podés seleccionar que base de datos resguardar.
>>>>
>>>> Guillermo Villanueva
>>>>
>>>>
>>>>
>>>> El día 24 de junio de 2012 04:55, José González <josego(at)simgia(dot)com>
>>>> escribió:
>>>>
>>>>> pero las tablas son incrementales?. si es así tendrías un ejemplo o
>>>>> algún
>>>>> link o script.
>>>>> gracias, saludos, jose
>>>>>
>>>>> El 23 de junio de 2012 22:54, Guillermo Villanueva <
>>>>> guillermovil(at)gmail(dot)com>
>>>>> escribió:
>>>>>
>>>>> Utilizo diariamente pg_dump exceptuando tablas gigantes que se
>>>>>> modifican
>>>>>> muy poco. Mensualmente hago un backup completo.
>>>>>>
>>>>>>
>>>>>> El 23 de junio de 2012 23:35, José González <josego(at)simgia(dot)com>
>>>>>> escribió:
>>>>>>
>>>>>>> si ya conozco el articulo, pero me parece que es mucho para lo que
>>>>>>> necesito. No habría otra forma?? Con el pg_dump le hago los backups
>>>>>>> completos, pero una vez al mes. Como lo haces tu para el pg_dump? o
>>>>>>> también
>>>>>>> solo completos?
>>>>>>>
>>>>>>>
>>>>>>> desde ya muchas gracias
>>>>>>> Saludos, José
>>>>>>>
>>>>>>> El 23 de junio de 2012 21:33, Guillermo Villanueva
>>>>>>> <guillermovil(at)gmail(dot)com> escribió:
>>>>>>>
>>>>>>> José para hacer backup incremental podés utilizar el concepto:
>>>>>>>> PITR, te
>>>>>>>> recomiendo la lectura de este artículo
>>>>>>>> http://www.postgresql.org.es/**node/238<http://www.postgresql.org.es/node/238>
>>>>>>>> yo lo usé un tiempo , pero despues terminé haciendo backup selectivo
>>>>>>>> utilizando pg_dump programados, lo cual me resultó mas simple.
>>>>>>>> Guillermo Villanueva
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> El 23 de junio de 2012 17:42, José González <josego(at)simgia(dot)com>
>>>>>>>> escribió:
>>>>>>>>
>>>>>>>> Hola a todos:
>>>>>>>>> Estoy queriendo hacer un backup incremental de una base de datos
>>>>>>>>> especifica. Me podrían orientar un poco. Muchas gracias
>>>>>>>>> saludos, jose
>>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>> Enviado a la lista de correo pgsql-es-ayuda (
>>>> pgsql-es-ayuda(at)postgresql(dot)org**)
>>>> Para cambiar tu suscripción:
>>>> http://www.postgresql.org/**mailpref/pgsql-es-ayuda<http://www.postgresql.org/mailpref/pgsql-es-ayuda>
>>>>
>>>>
>>>
>>> -
>>> Enviado a la lista de correo pgsql-es-ayuda (
>>> pgsql-es-ayuda(at)postgresql(dot)org**)
>>> Para cambiar tu suscripción:
>>> http://www.postgresql.org/**mailpref/pgsql-es-ayuda<http://www.postgresql.org/mailpref/pgsql-es-ayuda>
>>>
>>
>>
>>
>> --
>> Felipe Guzman Vargas
>> Analista Programador Computacional
>> 09- 54047753
>>
>
>