Re: backup incremental de una base de datos

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