Re: backup incremental de una base de datos

??????

El 27 de junio de 2012 13:59, Mauricio Rafael Rivas Martinez <
mrivas10(at)cantv(dot)com(dot)ve> escribió:

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