Linux Respaldo, Cron y Restauracion de PostgreSQL 9.x.

Uno de las tareas de todo administrador de sistemas y sobre todo los que emprenden ese camino, los respaldo son uno de los tantas tareas que en ninguna empresa ponen atencion, solo nosotros sabemos lo critico de estas funciones.

Un respaldo nunca se sabe cuando van a necesitarse, pero es preferible  programarlos y revisar que se lleven a cabo, nunca debe uno confiarse que siempre corren, la mayoria ya tiene funciones que envian correos cuando estos se llevan a cabo.

Pero aqui vamos a ver como se llevan los respaldos con las funciones internas de PostgreSQL y unos trucos para no tener que poner la clave en los  batch de respaldo.

Para iniciar, postgres cuenta con una herramienta llamada 'pg_dump', esta una de las funciones que se usan para obtener los respaldos de la BD.

Esta funcion yo la uso en un batch que lo ejecuto durante la madrugada para no interferir con las funciones durante las horas laborales, sin embargo ahi que saber ejecutarlo cuando sea necesario, por ejemplo cuandot tienes un servidor de desarrollo y tienes que actualizar la BD para que la(o)s programadores puedan tener la info lo mas actualizada posible y poder hacer mejores pruebas durante el desarrollo de sus aplicaciones o reportes.

Pero vamos a ensuciarnos la mano, yo obtengo los respaldos de esta manera, vamos respaldar la bd de nombre: bucardo.

Fig. 1 Base de Datos.

La figura muestra una de las BD que vamos a respaldar, entonces ejecutamos este comando, solo calculen cuanto espacio deben tener disponible donde vayan a guardar el respaldo no vaya ser que se queden sin espacio.

Antes de ejecutar el comando, yo creo un folder llamado 'respaldo' dentro de '/opt' ahi meto mi respaldo.

cd /opt
mkdir respaldo
cd respaldo

Fig. 2 pg_dump en operacion.

Que significa los parametros:

-E Collate, si ven la figura 1 ahi viene esa columna.

-U usuario que ejecuta la tarea, debe tener la bandera 'SUPERUSER', en este caso postgres es el adecuado.

-F Formato del archivo a generar, en este caso tipo 'p', archivo de texto o llamado plano con puras instrucciones SQL estandar.

-b Incluir campos tipo blow o sea grandes, nosotros usamos imagenes dentro de la base de datos tipo blow.

-f nombre del archivo a genera, o sea es el archivo principal a respaldar.

por ultimo le proporcionamos el nombre de la base de datos que vamos a respaldar.

Aqui ya tenemos nuestro respaldo, podemos enviarlselo a nuestro sistema de respaldo de red como bacula en mi caso.

Aqui lo hemos hecho a mano, pero como vamos a meterlo a un batch para que se ejecute a las 2AM todos los dias?

Antes de llevar esto a cabo, debemos hacer unos ajustes a nuestro sistema, por que? Como le vamos a dar el password al batch? Dentro del mismo batch? Es inseguro.

Para ello PostgreSQL tiene una manera un poco mas segura para esto, se genera un archivo dentro de la raiz de usuario que ejecutara el batch, en mi caso es root, el archivo contiene ciertos campos y ahi dentro le escribimos el password del usuario 'postgres' para cada BD que vamos a respaldar.

Ese archivo se llama '.pgpass', si notan ese archivo inicia con '.' lo que significa que esta escondido y un simple 'ls' o 'dir' no veras este archivo, con un 'ls -la' ya podras verlo como muestra la siguiente figura:

Fig. 3. Archivo .pgpass.

Creamos el archivo con el comando 'touch' y agregamos estos campos:

Fig. 4. Contenido de archivo '.pgpass'.

Si observan existen 5 columnas:

IP-del-equipo:PuertoDePSQL:BasedeDatos:Usuario:ClavedelUsuario

Como estamos llevando esto en el mismo servidor, con 'localhost' es suficiente. Salvan el archivo y le dan los permisos 0600 para que solo el usuario 'root' pueda accesarlo y verlo.

chmod 0600 .pgpass

Ya con esto que pasara?

Bien trate de accesar con el usuario 'root' la consola de postgres, claro si su archivo 'pg_hba.conf' de PostgreSQL tiene como seguridad el hash 'md5'.

En mi caso soy paranoico asi que yo uso md5, por tanto que sucedera ahora?

Pues muy facil, cuando ejecutamos 'psql postgres postgres' el sistema ya no solicitara la clave del usuario postgres :-), que implica esto?

Pues casi nada, nuestro batch solo requiere que exportemos este archivo en nuestro batch para que no requirea la invervencion humana.

Batch

Ahora si, vamos a crear nuestro batch y quedaria asi:

Fig. 5 Batch de Respaldo.

Ahi lo tienen, como ven? Ahora ese batch y el 'pgpass', lo pueden editar y meter todas las base de datos que tengan en PostgreSQL y hacer los mismo con el batch para abarcar todas sus BD's, pero eso se los dejo a su creatividad.

Ya solo salvan su archivo, lo dan su bit de ejecucion:

chmod +x mibatch.sh

Cron

Ahora sigue trabajar con cron, el cual quedaria asi:

Fig. 6. Configuracion de cron para nuestro batch de respaldo.

Asi quedaria nuestro batch, a las 2AM todos los dias se ejecutara, ya solo le digo a bacula que vaya y tome ese archivo cuando pase a recoger los archivos a respaldar, pero esa es otra historia(bacula).

Restauracion

Nos dicen que requerimos sacar un respaldo de la base de datos de la base de datos de nombre 'bucardo', esto es mas sencillo de lo que parece. 1ro que nada ocupamos el archivo de nuestro respaldo que vamos a utilizar para la restauracion, de ahi vamos a ejecutar ciertos comandos en la consola de PostgreSQL, cuales?

1) Accesar la consola de PostgreSQL.

2) Borrar la bd que vamos a restaurar.

3) Crear de nuevo la bd para quede en blanco.

4) Ejecutar el comando de restauracion.

Simples y rapidos pasos.

Paso 1) Entrar a la consola de PostgreSQL:

Fig. 6 Consola de PostgreSQL.

2) Borrar la bd que vamos a restaurar.

En mi ejemplo vamos a restaurar la bd de nombre 'mibd', como su contenido ya no es necesario, pero se preguntaran y tiene tablas? Pues vamos conectadonos a esa bd y listando sus tablas:

Fig 7. Conectadonos a el bd a borrar.

En la consola ejecutamos el comando '\dp;' y nos arrojara todas las tablas de la bd 'mibd' como muestra la siguiente figura.

Fig 8. Listado de tablas.

Ya nos mostro la fig. 8 que nuestra bd tiene 


drop database mibd;

OpenERP 7 Como Acortar Tiempo de Sesion.

Tenemos ya tiempo trabajando con OpenERP 7 hoy conocido como Odoo, estuvimos teniendo dificultades con el servidor, no siempre pero a veces nos reportaban de repente que ya los usuarios no podian accesar al sistema por que enviaba un mensaje relacionado a saturaciones de sesiones.

El servidor seguia operando con los usuarios ya firmados pero ya no dejaba firmarse a nadie. Lo unico era reiniciar el servicio tanto de PostgreSQL como Odoo.

No era algo que sucediera muy a menudo, pero decidimos revisar el caso, la configuracion de Odoo que se localiza en /etc, no tienen ningun parametro donde se le indique el numero de sesiones disponibles, solo parametros de manejo de memoria.

Lo cual no sirve para este problema, investigando un poco nos enteramos que Odoo 7 , desconozco si las versiones mas recientes les suceda lo mismo.

En Odoo 7 la sesion de un usuario es de 7 dias o.0.. asi es, si te firmas en el GUI, puedes dejar tu sesion durante 7 dias y no ahi problema, puedes llegar al siguiente dia y seguir trabajando sin tener que volverte a firmar por varios dias.

Pero esta felicidad que le puede causar a un servidor? Pues saturacion de conexiones, aunque muchos dicen que hoy en dia existen servidores con mucho hw, memoria, esto no indica que en algun punto el abuso de las sesiones vaya a causar problemas como los que pasamos.

PostgreSQL su configuracion de fabrica permite 100 conexiones simultaneas, el maneja muy bien sus sesiones, una conexion a Odoo abre cerca de 3 sesiones, la mayoria de la gente lo que hace es en su navegador tener hasta 10 sesiones del GUI para poder llevar a cabo su trabajo.

Nos toco ver hasta 878 conexiones al puerto 8069 de Odoo, solo imaginense cuanto memoria debe usar el servidor para satisfacer este demanda?

Teniamos que estar revisando las conexiones a PostgreSQL para ver si habia sesiones con mas de 15 minutos y tronarlas si estaban IDLE o sea sin hacer nada, pero era una labor medio tediosa, hicimos un batch y a veces al matar las sesiones afectabamos ciertas tareas y el servidor a veces acaba en modo 'Recovery' lo cual no era buen ya que dejaba de dar servicio por varios minutos mientras se reparaba.

Tenia que a ver una manera de cerrar sesiones de Odoo, mucha gente dejaba su lugar por horas y esto para nosotros era un desperdicio en realidad, mal gasto de recursos.

Dandole vueltas en google, en un maillist relacionado con Odoo una usuario menciono que existia un parametro donde uno maneja el tiempo que deseamos dure una sesion en Odoo. Yo tiempo atras pregunte en el foro oficial de Odoo, pero en verdad ahi nunca he obtenido respuesta de ayuda :-\.

Pues busque un archivo de nombre: http.py, el cual se localiza en 'web/addons/web', dentro de ese archivo buscamos esta linea:

def session_gc(session_store):
    if random.random() < 0.001:
        # we keep session one week
        last_week = time.time() - 60*60*24*7
        for fname in os.listdir(session_store.path):
            path = os.path.join(session_store.path, fname)
            try:
                if os.path.getmtime(path) < last_week:
                    os.unlink(path)
            except OSError:
                pass

La linea:

last_week = time.time() - 60*60*24*7

El comentario lo dice todo, 'we keep session one week', 1 semana wow...

Entonces tomamos la decision de cortar esa comodidad y dejarla en 1 hora la sesion, si en una hora el usuario no hace nada en su equipo, Odoo cortara su conexion cuando regrese y quiera operan el GUI, el sistema le arrojara un mensaje como este:

Figura 1: Aviso de Sesion Terminada.

Esto le indicara a el usuario que debe volver a firmarse, afecta la operacion a sera menos productivo el usuario? No.

Entonces a partir de ese momento fueron avisados un dia antes para que no se asombraran y estuvieran alertas a esos mensajes para que no digan que no informamos antes de hacer cambios globales en el sistema.

Pero se me paso decirles como quedo mi linea verdad, asi termino:

last_week = time.time() - 3600

El tiempo se mide en segundos, hemos cortado la sesion de 7 dias a 1 hora.

Despues de esto, claro que muchos usuarios que no leen sus correos empezaron a hablarnos por ese 'error', ya solo les aclaramos y adios llamadas de susto.

Hemos estado monitoreando el sistema y hemos notado un numero de sesiones mas estable, ya no tantas conexiones abiertas y ademas de ello ya pocas conexiones IDLE de PostgreSQL lo cual es bueno, otro detalle que hemos tenido que cortar sesiones pero todo bajo control y esto nos a disminuido los 'Recovery Mode' a 0.

Esto es bueno ya que 1 minuto sin sistema es gente ociosa y corajes inecesarios, usuario feliz y contento, operacion fluida.

Hasta qui les dejo esta detalle con Odoo 7, ojala a alguien le sirva, ya que mucho tiempo estuve buscando este dato, hasta pronto.

Mi Camino en el Mundo Informatico Continua...

Que tal, por ahi tenia un blog que deje se alimentar por nuevos proyectos que se me atravesaron, por ello decidi iniciar uno nuevo.

Los retos continuan y seguimos aprendiendo cosas nuevas y siguen apareciendo mas, asi que mas vale plasmarlas para que a alguien mas si le sirven que bueno si no ni modo :-).

Mi mundo laboral como empleado y ahora como empresario sigue alrededor del mundo de Linux, Windows, Unix, Help Desk como empleado, en el empresarial ya tenemos un WISP que es para llevar Internet a donde no hay.

Asi que va de nuevo...att: Pedro El Perico Moreno.