Respaldos remotos con SSH en Linux

Muchas veces como administradores de sistemas nos enfrentamos a uno de los temas de mayor relevancia en torno a la continuidad operativa de nuestros servicios, los respaldos. Es importante mantener actualizados y en optimas condiciones los sistemas. Técnicas como el RAID y la alimentación ininterrumpida nos permiten dormir más tranquilos y pensar menos en catástrofes que puedan dañar los sistemas y por ende dañar configuraciones y archivos que pueden ser importantes para la organización. Por todo lo anterior, es de suma relevancia que en lo posible se tengan sistemas de respaldos remotos y deseablemente en locaciones geográficas distintas.

Como es común en el mundo Unix, existen varias técnicas que nos permiten realizar tareas especificas y esta vez voy a explicar una sencilla manera de realizar la importante misión de hacer respaldos remotos utilizando SSH. Es una técnica bastante bien documentada por la web, pero que a mi juicio no esta bien explicada.

SSH, además de permitir acceder a maquinas remotas y controlar todo para lo que se tenga permiso, es una herramienta que soporta transmisión de datos. Es ésta característica la que vamos a aporvechar para realizar los respaldos remotos.

Asumiendo que se tienen dos equipos corriendo GNU/Linux vamos a implementar un sistema de respaldos para una base de datos en mysql que permita crear una copia de la misma en el servidor local y luego enviar ese respaldo a un host de respaldos remoto vía Internet. Es lo mismo si se requiere para cualquier tipo de archivos, carpetas, etc.

Los pasos a seguir son los siguientes:

1.- Ambos equipos deben tener instalado el servidor SSH. Si es un Linux de la linea Debian lo instalan con “apt-get install ssh” y si es de la linea Red Hat con “yum install openssh”.

2.- Entramos por SSH a la maquina que maneja la información que deseamos respaldar. Vamos a suponer que usaremos el usuario “jose” y el password “jose123″ en ambos equipos.

3.- Una vez dentro del servidor debemos generar un par de llaves SSH que son del tipo privada/publica usando el comando “ssh-keygen”.

jose@localhost # ssh-keygen -t rsa

Hecho lo anterior el sistema arrojará lo siguiente:

Generating public/private rsa key pair. 
Enter file in which to save the key (/home/jose/.ssh/id_rsa): 

Pregunta en que fichero deseamos guardar la llave, simplemente damos ENTER al igual que las siguientes preguntas:

Enter passphrase (empty for no passphrase):
Enter same passphrase again: 

Una vez terminado nos muestra:

Your identification has been saved in /home/scott/.ssh/id_rsa. 
Your public key has been saved in /home/scott/.ssh/id_rsa.pub. 

SSH ha creado 2 llaves, una publica (id_rsa.pub) y otra privada (id_rsa) que han sido guardadas en el directorio /home/jose/.ssh/

4.- Copiamos la llave publica al host remoto que actuará como servidor de respaldos vía SSH. Para ello utilizaremos la herramienta SCP en linea de comandos.

jose@localhost # scp /home/jose/.ssh/id_rsa.pub jose@X.X.X.X:/home/jose/.ssh/authorized_keys2

En donde X.X.X.X es la dirección IP del host remoto, por ejemplo: 192.168.1.2. Pedirá la contraseña del usuario remoto, en este caso la contraseña de jose.

5.- Verificamos que tengamos acceso a la maquina remota con lo que acabamos de hacer.

jose@localhost # ssh jose@X.X.X.X ls

Veremos una lista de archivos del host remoto. De no ocurrir esto o nos pide password, entonces volvemos a empezar desde el punto 3.

6.- Ya generada la conexión entre el servidor local y el host remoto al que enviaremos la información a respaldar es tiempo de generar el script que nos permitirá sacar una copia de la base de datos que necesitamos respaldar, comprimirla y enviarla al host remoto.

Creamos el script:

jose@localhost # vi script.sh

El contenido será:

#!/bin/bash
mysqldump  -u  usuario   -pclave   basededatos  >  /home/jose/mysql-bkps/bd-$(date +%d-%m-%Y).sql
bzip2  /home/jose/mysql-bkps/bd-$(date +%d-%m-%Y).sql
scp /home/jose/mysql-bkps/bd-$(date +%d-%m-%Y).sql   jose@X.X.X.X:/home/jose/mysql-bkps/

En donde mysqldump es la orden para generar un sql de una base de datos en concreto. Notese que -pclave se refiere a que hay que poner la clave pegada a la opción, es decir, -pmiclave.

En ambos equipos debe estar creada la carpeta /home/jose/mysql-bkps o la ruta que prefieran utilizar, esto es solo a modo de ejemplo.

Solo queda salir del editor y guardar con “:wq”.

7.- Finalmente se requiere que este respaldo se realice a todos los días a las 00:00, para ello utilizaremos crontab que es el programador de tareas con el que trabajan los sistemas Unix. Esto lo haremos en el servidor, no en el host de respaldos.

Para entrar en la edición de cron ejecutamos lo siguiente:

jose@localhost # crontab -e

Luego, en el editor de cron ponemos:

0 0 * * * /home/jose/script.sh

Hace que todos los días ejecute el script.sh que creamos anteriormente exactamente a las 00:00.

Con todo esto ya tenemos un sistema de respaldos automatizado que genera una copia de la base de datos deseada y la envía a un servidor de respaldos todos los días, de manera sencilla y segura.

Follow @javiergaray

 

 

 

 

 

 

COMENTAR

 

 

servidor dns: bind config tips

(En construcción). Seguramente muchos sysadmin habrán tenido más de algún problema con servidores DNS (me incluyo). Uno de los temas que requiere mayor atención en la organización son los servicios de resolución de nombres (DNS).

Un DNS puede ser utilizado por toda una red para resolver sus peticiones IP y acceder a la red y si este no funciona correctamente habrá muchos problemas. Es el encargado de saber a quien debe envíar la petición cuando se consulta un nombre de dominio del tipo nombre.com, nombre.net, nombre.cl, etc., y entregar una IP válida para accesder al servicio solicitado. En definitiva, “descubre la IP detras del dominio”.

Seguramente no estas aquí para leer como implementar un servidor DNS ya que éste articulo está creado pensando en resolver problemas y dar algunos consejos y que seguramente sufrirá modificaciones en el futuro, ya que como en todo, nada es perfecto y puede mejorar.

Probar estado del servidor

Si no estas seguro de que tu servidor este funcionando correctamente o si lo acabas de implementar, te recomiendo que utilices la herramienta doctorDNS, la cual te indica si tu servidor tiene problemas en alguno de los puntos señalados por el programa. Accede a http://www.nic.cl/doctorDNS/ para ver de que se trata. Debes introducir el nombre de dominio perteneciente a tu organización.

Soporte TCP

Siempre es bueno que tu servidor DNS este protegido por un firewall, por razones de seguridad ningun equipo debe estar expuesto a la red sin una correcta configuración de seguridad. El problema viene cuando tienes que dar permisos a los puertos. El servidor DNS de Linux (BIND) utiliza el puerto 53 UDP para resolver consultas, pero cuando la respuesta del DNS es mayor de 512 bytes BIND utiliza el puerto 53 TCP y por lo tanto es necesario que el servidor tenga los puertos 53 UDP y TCP abiertos para un correcto funcionamiento.

En iptables es muy sencillo configurar la apertura de puertos. Asumir que el firewall esta configurado previamente y que partimos del punto en el que esta todo cerrado, para abrir entonces se requiere de la siguientes lineas en tu configuración de iptables:

Primero la politica INPUT:

-A INPUT -p tcp -m state  - -state NEW -m tcp –dport 53 -j ACCEPT

-A INPUT -p udp -m state  - -state NEW -m udp –dport 53 -j ACCEPT

Luego la OUTPUT:

-A OUTPUT -p tcp -m state  - -state NEW -m tcp –dport 53 -j ACCEPT

-A OUTPUT -p udp -m state  - -state NEW -m udp –dport 53 -j ACCEPT

Puedes agregar cuanta politica de restricción requieras en tu caso, por ejemplo  que el servidor solo resuelva para un cierto segmento de direcciones IP o que solo resuelva para algún host en especifico. Esto ya depende de tus requerimientos y existe mucha documentación sobre iptables para todas las necesidades.

Lame Servers

Una de las cosas que más me llamó la atención cuando revisaba los logs de mis DNS era que estos se estaban llenando de mensajes alucivos a los “lame servers”. Un lame server es un servidor que es consultado como servidor DNS de una cierta zona o dominio en internet y que no tiene autoridad sobre dicha zona o dominio, en otras palabras, el servidor consultado no puede resolver la petición generada por el servidor local. No es un problema del servidor nuestro, sino de una mala configuración en el servidor DNS remoto.

A muchos de nosotros no nos gusta leer logs extensos y menos lidiar con información de este tipo, por lo tanto si este es tu caso se puede solucionar simplemente añadiendo unas lineas al archivo de configuración de BIND (named.conf) para que no escriba los errores relacionados a “lame server”. Lo que debes agregar es:

logging  {

category lame-servers { null; };

};

Continuará…