Skip site navigation (1) Skip section navigation (2)

Re: backup incremental de una base de datos

From: Mauricio Rafael Rivas Martinez <mrivas10(at)cantv(dot)com(dot)ve>
To: Juan <smalltalker(dot)marcelo(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, José González <josego(at)simgia(dot)com>, felipe guzman <felipeguzmanv(at)gmail(dot)com>, Guillermo Villanueva <guillermovil(at)gmail(dot)com>, Ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: backup incremental de una base de datos
Date: 2012-06-27 11:59:47
Message-ID: 4FEAF5B3.7090001@cantv.com.ve (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
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>>
>
>


In response to

Responses

pgsql-es-ayuda by date

Next:From: Jose Mercedes Venegas AcevedoDate: 2012-06-27 13:27:18
Subject: Inicio automatico de postgres en windows
Previous:From: felipe guzmanDate: 2012-06-27 11:05:55
Subject: Re: backup incremental de una base de datos

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group