Re: backup incremental de una base de datos

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

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>