Re: backup incremental de una base de datos

*Guillermo Villanueva*:
Eso de poner tu password de postgres en texto plano no es muy recomendable.
Si vas a acceder localmente osea localhost para hacer el backup, entras al
archivo /etc/postgresql/8.4/main/pg_hba.conf.
Donde dice:
*# Database administrative login by UNIX sockets
local all postgres ident
*
Le cambias *
**local all postgres trust*

Y luego lo guardas, e reinicias postgres.

OBS:
Lo que estarías haciendo es al hacer el backup con el usuario en localhost,
no te pedirá el password. Osea que si alguien no autorizado a tu sistema no
podrá ver el password porque no esta escrito en ningún archivo de texto
plano.

Son detalles de seguridad que tenemos que atender, especialmente si es un
server en producción.
Saludos, jose

El 27 de junio de 2012 14:39, Guillermo Villanueva
<guillermovil(at)gmail(dot)com>escribió:

> ??????
>
>
> El 27 de junio de 2012 13:59, Mauricio Rafael Rivas Martinez <
> mrivas10(at)cantv(dot)com(dot)ve> escribió:
>
> 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>
>>
>>>
>>> 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>
>>>
>>
>>
>>
>>
>