Re: PITR Point in Time Recovery en linea administrado

Hola, favor de leer la sección sugerencia.

Flash back es otra cosa. Distinto a lo que te mencione de los ETL
(convertir los delete/update en solo insert ) para poder recuperarse de
estos errores.

El flash back es una opción donde puedes poner leer datos pasados en el
tiempo ( dependiendo de la retención ).

Ejemplo:
10:00 pm alguien hizo un delete de todos los registros y el sistema
tiene registros nuevos desde las 10:00 pm...

La forma de recuperarte es de dos formas ( con Oracle o postgres esta
forma es similar ), clonando la base de datos justo antes del delete. (
Lo ideal es que tengas auditado cuando alguien hace delete/truncate (
que no sea un usuario de aplicación ), para eso vas a tener que jugar
con los ACL y crear grant para poder auditar de forma correcta.

La otra forma ( solo se que Oracle tiene esta opción ), es con
FlashBack, es un área de recuperación online que tiene Oracle del tamaño
( que tu configures ), incluido guarda las tablas que borras, pasado el
tiempo X, se borran los datos. Pero básicamente es para recuperarse de
errores como esos, de esa forma puedes insertar de nuevo los datos o
crear una tabla con los datos antes que los modificaran.
https://docs.oracle.com/cd/B12037_01/appdev.101/b10795/adfns_fl.htm

Pero ojo, sin un audit, no sabes cuando paso eso...

## Sugerencia ##

Por lo que me comentas, los problemas no son del sistema, si no de los
desarrolladores, creo que lo que te hace falta hacer, es:

1. Cerrar acceso de producción a los desarrolladores.
2. Tener un proceso de respaldo lógico para cuando tengas que hacer
limpieza de datos.
3. Auditar de alguna forma delete masivos/update que no sean de la
aplicación.
4. Clonar producción de forma automatica para que los desarrolladores
hagan lo que quieran.
5. Generar un ambiente QA ( probar tu proceso antes de pasarlo a
producción).
6. Usar algo como cucumber o selenium ( para hacer pruebas automaticas
despues de aplicar el proceso en tu QA.
7. Hacer otra cosa con tu tiempo ya que tus problemas deberian desaparecer.

PS: Recuerda, que no hay sistemas a prueba de idiotas, y los idiotas son
super ingeniosos para romper cosas... solo hay formas de contenerlos lo
mejor posible.

On 11/21/2015 8:58 AM, Hellmuth Vargas wrote:
> Hola Horacio Muchas gracias por el comentario
>
> La inquietud surge porque estuve leyendo algo similar en Oracle
>
> https://moisesespinosa.wordpress.com/2011/09/19/flashback-i-introduccion/
>
> y dado que PostgreSQL implementa una replica retrasada pensé ..."y
> porque no tener la posibilidad de ir aplicando los cambios paso a paso
> hasta lograr la instantánea de los datos justo antes de que se hubiesen
> borrado." en un caso hipotético que seria algo mas inmediato, expedito
> que hacerlo por PITR
>
>
>
> El 20 de noviembre de 2015, 2:41 p. m., Horacio
> Miranda<hmiranda(at)gmail(dot)com <mailto:hmiranda(at)gmail(dot)com>> escribió:
>
> Hola, para tu problema ( ignoro si esto es util ), en un cliente (
> Oracle ) teniamos el mismo problema, la forma de solucionarlo fue
> implemetnar Oracle Stream con WTL ( convirtiendo todos los update,
> delete en insert ) para poder volver atras sin recuperar, la base de
> datos era de unos 10 Teras eso si.
>
> Ignoro si en postgresql existe una forma de replicar y modificar lo
> que llega a la replica ( cosa de poder volver atras las transacciones ).
>
> Si no existe sería un feature que valdría la pena trabajar y hacer. :D
>
>
> On 11/21/2015 3:45 AM, Hellmuth Vargas wrote:
>
> Buenos dias Lista
>
>
> Dado que en algunas oportunidades (mas de las que quisiera) se
> borran
> datos de tablas,o incluso las tablas mismas, se actualizan con datos
> errores, etc etc, etc (otro tema es que entren usuario con
> privilegios a
> hacer estas calamidades... ) para subsanar esto hay que restaurar
> backups y con los WAL archivados restaurar los datos alterados, esto
> toma tiempo, mas cuando las bases son grandes y mas cuando no se
> sabe
> exactamente la hora del suceso; para la versión 9.4 existe la
> posibilidad de mantener una replica retasada un X tiempo
> (http://www.depesz.com/2013/12/20/waiting-for-9-4-allow-time-delayed-standbys-and-recovery/)
> que ayuda bastante, pues es una base EN LINEA con la foto de
> nuestra
> base de hace X tiempo, mas si el cambio fue antes de este tiempo, ni
> modos... Entonces la pregunta es:
>
> Que posibilidades hay de mantener una replica en linea retrasada X
> tiempo (casi una semana, por ejemplo) pero que se pudiera
> administrar la
> aplicación de los WAL de forma manual, para permitir operaciones
> como (todas ojala dentro de una transaccion para poder
> devolver el
> cambio en el caso que uno se 'pasara' de la hora del suceso):
>
>
> - Aplicación de cambios hasta un timestamp defnido
> - Aplicación de WAL interactivamente, algo como aplique el
> siguiente WAL
> para que por tanteo se pueda llegar a los datos mas próximos
> antes de la
> calamidad
>
> Y con todas las bondades de las replicas en linea. Muchas
> gracias Lista
> y quedo atento a sus comentarios.
>
>
>
>
>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> EnterpriseDB Certified PostgreSQL 9.3 Associate
>
>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> EnterpriseDB Certified PostgreSQL 9.3 Associate
>

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda