Re: backup incremental de una base de datos

Alvaro

graacias por contestar , te pregunto entre lineas.

2012/6/26 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

>
> Excerpts from Juan's message of mar jun 26 10:54:46 -0400 2012:
> > Mauricio ,Gente
> >
> >
> > Despues de leer el PITR, me quede pensando como implementar uno de los
> > requerimientos que seria
> > poder detectar acciones destructivas como por ej para ser drastico, drop
> > schema blah o truncate table x.
> > y se me ocurrieron dos cosas. una poner el logstatement ='all' luego
> hacer
> > tail del log con grep y algunas expresiones
> > regulares capturando estas sentencias (drop, truncate ..etc).
> > pero lo que todavia no tengpo claro es que accion tomar y como, se me
> > ocurrio leyendo el PITR que el comando store,storecommand
> > o algo asi que es parte del PITR podria ser un script bash llmamando al
> cp.
> > (cp) y si detecto uno de estos comandos de
> > destruccion, copiarle otro script del mismo nombre pero que por dentro a)
> > no copie b) copie a otro direcrtorio que no sea
> > donde esta el otro motor postgres en modo hold o como se llame.
> > que les parece?
>
> Eso ya existe.
>
> 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" , 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.
saludos
jmdc

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