Re: backup incremental de una base de datos

Juan, en base a todo lo que has planteado y te han contestado me parece
lo siguiente:

1) ya te dijeron por ahi que el camino que quieres tomar para lograr tu
objetivo es futil, estoy de acuerdo.
2) revisa la permisologia de la base de datos y como ya te inidacron
llevala al minimo necesario para que todos y cada uno de los usuarios
(Aplicaciones y personas ) puedan hacer su trabajo. ten presente que la
permisología siempre debe ser individual y para mejor administración
basada en roles.
3) si persisten en tu objetivo entonces te recomiendo lo siguiente, crea
unos trigers que chequen la ejecucion de las sentencias que necesitar
auditar y/o negar sobre las tablas que requieres vigilar, y asi podras
llevar registro de quien ejecuta estas sentencias. Esto te servira con
los DML con los DDL tendrias que revisar mas a fondo.

Gracias

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 26/06/2012 01:39 p.m., Juan escribió:
> Alvaro
>
> entre lineas
>
>
> 2012/6/26 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org
> <mailto:alvherre(at)alvh(dot)no-ip(dot)org>>
>
>
> Excerpts from Juan's message of mar jun 26 13:16:18 -0400 2012:
>
> > 2012/6/26 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org
> <mailto:alvherre(at)alvh(dot)no-ip(dot)org>>
>
> > > PITR es sigla de "point in time recovery", que en concreto
> significa que
> > > uno puede recuperar hasta un determinado punto en el tiempo; o
> sea que
> > > si tienes los WAL desde el pasado hasta más allá del momento
> en que se
> > > hizo el DROP o el TRUNCATE, puedes detener el sistema y
> decirle que
> > > empieze a recuperar hasta justo antes del DROP o TRUNCATE.
> > >
> >
> > Como hago eso?
> > Si ya existe, donde lo leo? porque no me queda claro como,
> entonces estuve
> > pensando como hacerlo yo mismo.
> > Yo suponia que el segundo postgres en stand by todo el tiempo
> recibía los
> > wal
> > del "master db" ,
>
> En el escenario en que yo estoy hablando, no hay un secundario,
> sino un
> área de archivado donde los logs se guardan. Está documentado acá:
>
> 24.3.3. Recovering Using a Continuous Archive Backup
> ...
> If you want to recover to some previous point in time (say, right
> before
> the junior DBA dropped your main transaction table), just specify the
> required stopping point in recovery.conf. You can specify the stop
> point, known as the "recovery target", either by date/time, named
> restore point or by completion of a specific transaction ID.
> http://www.postgresql.org/docs/9.1/static/continuous-archiving.html
>
>
> Creo que si el problema del cual te quieres proteger es alguien que
> comete un error, la solución es no dejar que nadie se meta al servidor
> de producción, sólo las aplicaciones; que las aplicaciones tengan
> permisos mínimos, de manera que puedan hacer poco daño en caso de que
> haya algún bug; y usar mecanismos seguros de manera que no haya
> hoyos de
> inyección de SQL, para evitar los maliciosos (que nunca faltan).
>
> Tratar de parchar el sistema para impedir que alguien que se cuele
> en tu
> servidor haga daño me parece esfuerzo gastado en la dirección errónea.
> Por ej. digamos que proteges el DROP TABLE y el TRUNCATE pero alguien
> hace un DELETE de toda la tabla ... O alguien crea un trigger ON
> INSERT
> que invoca TRUNCATE.
>
> > entonces lo que necesitaba era "negarle" los logs que
> > tienen
> > el DROP o TRUNCATE etc,, pero parece por lo que decis que no es asi.
>
> Bueno, no. No existe un mecanismo para decirle a un standby que se
> detenga. Tampoco existe (que yo sepa) un mecanismo para inspeccionar
> cada registro antes de ejecutarlo, que hipotéticamente serviría para
> detener la recuperación cuando encuentre algo que no le guste (por ej.
> el DROP o TRUNCATE que señalas).
>
>
> Alvaro, lei el PITR pero pensé que era en caliente o se otra base de
> datos esta
> leyendo los logs/WALLS que le tira la base que esta procesando
> transacciones
> esta es la base que llamo en stand by , pero parece que no, que solo
> archivo los logs
> y luego los aplico según corresponde.
> Para aplicar el tema de detener o detectar estas sentencias de
> DROP/TRUNCATE etc
> pensé que leyendo el log de la base maestra podría detectar cuando
> llegan estas instrucciones
> frenar la copia y la db en stand by no debería tener estas
> instrucciones dañinas.
> salu2
> jmdc
>
> --
> Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org
> <mailto:alvherre(at)alvh(dot)no-ip(dot)org>>
>
>