Usar VDR y scp para realizar copias de seguridad automatizadas de servidores remotos

Asumiendo el riesgo de que el tema no interese a nadie, dado que mi ignorancia en estos temas me ha obligado a invertir unos "ratitos" de tiempo para resolver un tema que se me ocurrió tras el lanzamiento por parte de Posix de la VPN, y que es más un capricho que una necesidad, os pongo el procedimiento para poder usar el VDR como "Agente Backup" y hacer una copia de seguridad de los datos de un determinado directorio de un servidor remoto, al disco duro conectado en nuestro giga.

Que un equipo de TDT se pueda usar para estos menesteres, particularmente me parece un tema, como mínimo, curioso y más cuando todo se consigue con conexiones seguras del tipo ssh, scp (disculpad mi vocabulario, pero al no ser ni informático ni un profundo conocedor de estos temas, puedo cambiar nombres con relativa facilidad).

El primer paso para lograr una tarea automatizada y poder hacer la copia de seguridad en nuestro disco, es conseguir que la comunicación con el servidor remoto no pida contraseña, de esta manera, con un simple script, se puede lanzar todo de forma automática para dejarlo ejecutándose y despreocuparse del tema. Para conseguir que no nos pida la contraseña hay que generar un par de ficheros de claves, uno con las privadas que se quedarán en nuestro giga y otro con las públicas que las copiaremos en los servidores a los que queramos conectar. Ambos ficheros sirven para autentificar la conexión entre nuestro giga y los servidores (a modo de contraseña automática).

El procedimiento para dejar preparado tanto el servidor como nuesto giga es el siguiente:

1.- Tenemos que generar el fichero de clave privada (que incluirá también la clave pública). La instrucción a ejecutar, mediante telnet desde nuestro giga es:

Código:

dropbearkey -s 4096 -f /root/.ssh/id_rsa_4096

El fichero que generamos se llama id_rsa_4096 y se habrá creado en el directorio /root/.ssh/
Este fichero tarda unos 5 minutos en generarse. Si queremos que la generación sea más rápida, podemos eliminar la parte "-s 4096" de la órden, aunque el nivel de seguridad será más bajo (por defecto 1024 bits -creo-) aunque probablemente sea suficiente.

2.- Generar el fichero con la clave pública que se copiará en el directorio .ssh del usuario al que se conecte del servidor remoto.

Código:

dropbearkey -y -f /root/.ssh/id_rsa_4096 | grep "^ssh-rsa " >> /root/.ssh/authorized_keys_4096

Este fichero se habrá creado en el mismo directorio que el anterior.

3.- Cambiamos los permisos del fichero.

Código:

chmod 600 /root/.ssh/authorized_keys_4096

4.- Copiamos la clave pública al servidor remoto, al .ssh del usuario.

Código:

scp -P puertod_ssh_servidor_remoto /root/.ssh/authorized_keys_4096 usuario_servidor_remoto@ip_servidor_remoto:.ssh/authorized_keys

Lo único que hacemos con esta órden es copiar en el directorio .ssh del usuario del servidor remoto, el fichero que permitirá identificar a nuestro giga cuando se conecte.

puertod_ssh_servidor_remoto --> Es el puerto de escucha del servidor remoto. Habrá que ponerlo si es diferente al que tiene por defecto, que es el 22.
usuario_servidor_remoto--> El nombre de usuario que utilizamos para conectarnos al servidor remoto.
ip_servidor_remoto--> La dirección ip del servidor remoto.

5.- Hacemos una conexión prueba, indicando el fichero de clave privada en la instrucción de conexión para que el servidor remoto no pida contraseña.
La primera conexión nos pedirá si queremos confiar en el servidor al que se conecta y habrá que aceptar (automáticamente nos aparecerá en /root/.ssh/ un fichero llamado known_hosts), aunque es probable que esta solicitud ya nos haya aparecido al ejecutar la instrucción del punto 4. La orden es:

Código:

ssh -p puertod_ssh_servidor_remoto usuario_servidor_remoto@ip_servidor_remoto -i /root/.ssh/id_rsa_4096

A partir de este momento ya podemos crear un pequeño script ejecutable desde el giga, bien por telnet, con el explorador de archivos o mediante una tarea del programador de tareas.

El script puede llamarse "copia_seguridad.sh" y tener esta forma:

Código:

#!/bin/ash

export HOME=/root

date > /media/vdr1/copia_seguridad_servidor/ultima_copia.log

scp -P puertod_ssh_servidor_remoto  -i /root/.ssh/id_rsa_4096 usuario_servidor_remoto@ip_servidor_remoto:/directorio_del_servidor_remoto/* /media vdr1/copia_seguridad_servidor/

date >> /media/vdr1/copia_seguridad_servidor/ultima_copia.log

exit 0

El script hace que el giga se conecte al servidor remoto y descarge sobre nuestra carpeta de grabaciones en el directorio "copia_seguridad_servidor" todo el contenido del directorio "directorio_del_servidor_remoto" del servidor al que nos conectamos. Y todo ello sin pedir contraseña ni ninguna otra validación.

El fichero /media/vdr1/copia_seguridad_servidor/ultima_copia.log nos indicará el inicio y el final de la copia, por lo que sabremos el tiempo que tarda en realizarse la misma.

Para ejecutar el script únicamente tendremos que conectar por telnet, situarnos en el directorio donde hayamos guardado el mismo y ejecutar:

Código:

ash copia_seguridad.sh &

El símbolo "&" del final de la orden de ejecución es para que se ejecute en segundo plano, por lo que podremos cerrar nuestra ventana de telnet y apagar nuestro ordenador estando seguros de que se está realizando la copia.

Como he comentado antes, se puede ejecutar desde el filebrowser o desde el programador de tareas.

Por cierto he estado ojeando con "top" los consumos de la copia sobre
el procesador y me han parecido más bien bajos (en torno al 10%).

Un saludo,
jb


TODO ESTO YA SOBRA, ESTÁ RESUELTO LO DEJO PARA VER EL ERROR QUE APARECE SIN EL "export" del script
*****************************************************************************************
Hay problemas con el programador de tareas y con el filebrowser. Parece como si la conexión no se realizase como root y volviese a pedir validación para guardar los datos del servidor en el fichero known_hosts y por lo tanto la conexión ya no prosigue. Esto no ocurre ejecutando el script por telnet así que no se que puede pasar ni como resolverlo.

Como había puesto el error que ocurre ejecutando desde el filebrowser en otro hilo, lo aprovecho y lo cuelgo aquí por si a alguien se le ocurre alguna idea para resolverlo y así poder dejar la copia configurada automáticamente desde el programador de tareas.

Código:

/usr/sbin/dbclient:Warning:failed creating //.ssh:Read-only file system
Host 'elservidor' is not in the trusted hosts file
fingerprint......... números en hexadecimal
Do you want to continue connecting? (y/n)
elservidor:puertoscp exited: Didn't validate host key

****************************************************************************************

jb, ¿por que no copias todo esto en el wiki como una pagina nueva cuando tengas un ratillo?

Tu problema parece que pueda ser un tema de permisos has probado aunque solo sea para probar a ponerle mas permisos a los ficheros y directorios de las claves?

Tambien prueba a dentro del fichero copia_seguridad.sh poner al principio del todo un "cd" para que vaya al directorio de trabajo correcto, vamos al mismo en el que estes cuando lo lanzas con telnet y te funciona.

Seguro que es una de estas dos cosas, incluso yo probaria primero lo del "cd".

Lo probaré y ya diré lo que sucede, gracias zjuanma.

Lo de la wiki, pensaba que no sería de utilidad para nadie por eso lo he puesto como un post. Pero ya lo pondré.

Edito: He dado permisos 777 al directorio .ssh y ficheros y sigue fallando con el mismo error. En cuanto a lo del cd no entiendo muy bien a que te refieres por que al ejecutar el script con el explorador de archivos lo que se hace es ir al directorio del script y ejecutarlo y cuando lo hago por telnet hago lo mismo, ir al directorio y ejecutarlo. ¿O te refieres a que al inicio ponga un cd /root/.ssh/ para ir al directorio donde están los archivos del ssh?

Salu2.

cuando entras con root por telnet, que haces:

cd /ruta_donde_tienes_el_script
./script

si haces eso y te funciona, dentro del script pon

1.
cd /ruta_donde_tienes_el_script

2. si no te funciona pon
cd /root

zjuanma escribió:cuando entras con root por telnet, que haces:

cd /ruta_donde_tienes_el_script
./script

si haces eso y te funciona, dentro del script pon

1.
cd /ruta_donde_tienes_el_script

2. si no te funciona pon
cd /root

Lo que indicas es lo que hago. He probado los dos puntos, pero el resultado es el mismo. Parece como si fuese otro usuario el que lo ejecuta en lugar de root (desde el filebrowser) y como si intentase crear un nuevo known_hosts en el home/.ssh de ese usuario pero no pudiese por estar protegido contra escritura el sistema de archivos (incluso para root).

Pues para comprobar que es cierto que parece usar otro usuario.

Mete en el script una linea del tipo

Código:

whoami > /tmp/usuario_ejecucion_script.log

Para ver con que usuario se ejecuta realmente.

zjuanma escribió:Pues para comprobar que es cierto que parece usar otro usuario.

Mete en el script una linea del tipo

Código:

whoami > /tmp/usuario_ejecucion_script.log

Para ver con que usuario se ejecuta realmente.

Pues no lo entiendo, lo he ejecutado y el usuario es root. ¿Donde puede ir a buscar el known_hosts entonces?

Yo creo que no tenemos variables de entorno.

Prueba a poner algo del tipo:

export HOME=/root

Por eso intenta crearlo en //.ssh/... y dice que es un read only file system.

¿Cómo lanzas la ejecución?

Posix escribió:
¿Cómo lanzas la ejecución?

Con el filebrowser me situo sobre el archivo del script y le doy a "Ejecutar".
El filebrowser ejecuta "ash f$", donde f$ contiene el nombre del archivo y la ruta completa.

Esta tarde probaré el "export" . Gracias.

Posix escribió:Yo creo que no tenemos variables de entorno.

Prueba a poner algo del tipo:

export HOME=/root

Por eso intenta crearlo en //.ssh/... y dice que es un read only file system.

¿Cómo lanzas la ejecución?

"Ahí las dao". Ya funciona con el filebrowser y con el programador de tareas (espero que no finalice la tarea antes de acabar la copia).

De momento lo dejo funcionando, a ver si dentro de una hora tengo la copia completa.

Muchísimas gracias por vuestras ideas.

Por cierto, he intentado colgar el manual en la wiki, pero me dice algo sobre que hay símbolos que no puedo utilizar y después de que le había dado formatos y todo no lo he podido grabar. A ver cuando lo puedo colgar bien, aunque si hay símbolos que no me admite quizás tenga que poner alguna línea como imagen... ya veré.

Salu2

Bueno, ha terminado ya la ejecución de la tarea programada y todo perfecto, ya hace automáticamente las copias de seguridad.
Así estoy de contento:


A ver cuando saco un ratillo para ponerlo en la wiki.
Salu2

Bueno, ya está la página en la Wiki.

http://www.assembla.com/wiki/show/VDR-M7x0/Backups_autom%C3%A1ticos_con_scp

Si hay algo que modificar y mejorar, como siempre, estáis invitados a ello.

Salu2.

Llego de vacaciones, y me encuentro con este regalo... Un trabajo genial jb... gracias por compartirlo. :aplau2:

A este paso, vamos a convertir nuestro VDR en un NAS , servidor FTP, servidor Web, ... y lo que se nos ocurra.

Por cierto jb, sería interesante poder revisar la carga del gigaset cuando está realizando la copia, lo comento ya que puede suponer un problema si coincide con alguna grabación.

pjllaneras escribió:Llego de vacaciones, y me encuentro con este regalo... Un trabajo genial jb... gracias por compartirlo. :aplau2:

A este paso, vamos a convertir nuestro VDR en un NAS , servidor FTP, servidor Web, ... y lo que se nos ocurra.

Por cierto jb, sería interesante poder revisar la carga del gigaset cuando está realizando la copia, lo comento ya que puede suponer un problema si coincide con alguna grabación.

Ayer mientras comía estaba realizando la copia de seguridad y estaba reproduciendo una serie. Con los dos procesos a la vez no dio ningún problema.

De todos modos hice un pequeño seguimiento con "top" y vi que estaba el uso de procesador en torno al 10%. Pero lo miré durante unos segundos, si que es cierto que habría que ver que pasa cuando se está grabando.

Consumos visualizados con top desde telnet donde se puede comprobar que durante el inicio de la comunicación, durante un minuto aproximadamente consume un 50% de CPU pero tras ese minuto se estabiliza por debajo del 10% (que es lo que reproducen los vídeos).
Por cierto se están realizando dos grabaciones simultáneamente (al mismo tiempo que la copia), que se han reproducido correctamente.

En este primer vídeo se puede ver el consumo de scp en una de las líneas:


En este segundo vídeo se puede ver el consumo de dbclient, que también se ejecuta con scp:


No se si servirá para algo.

Tienes una carga media enorme, tienes el giga a tope :-)

zjuanma escribió:Tienes una carga media enorme, tienes el giga a tope :-)

Pero con dos grabaciones a la vez (sin pixelar) y el scp. ¿eso significa que lo puede llevar o mejor dejar el scp para cuando no esté grabando nada?

¿me puedo cargar (de fundir :miedo: ) el giga?

Gracias por los datos jb... así parece que el giga puede soportar la grabación simultánea con la copia de seguridad remota.

jb escribió:¿me puedo cargar (de fundir :miedo: ) el giga?

Por lo que he leido, el giga no tiene el mejor sistema de refrigeración y tiene tendencia a calentarse, lei hace tiempo que una solución era montarle un ventilador/dispador sobre el procesador.

Yo por mi parte no he tenido problemas de estos, aunque tampoco lo he sometido a un estrés como este durante mucho tiempo.

Como me tenía un poco preocupado el tema de la CPU y el scp os pongo
otro par de vídeos que a mi entender, demuestran que consume menos
recursos scp que la realización de dos grabaciones simultáneas:

Ejecutándose únicamente scp estos son los consumos de CPU:


Realizando dos grabaciones a la vez y sin scp:


Como la ejecución de scp se hace de madrugada sin que haya ninguna grabación, supongo que no me tengo que preocupar por posible maltrato al giga ¿no?.

Salu2,
jb

Pues parece que si no coinciden dos grabaciones al mismo tiempo que con la copia no se estresa demasiado... lo veo perfectamente viable y seguro (para la CPU).

Fantástico trabajo de investigación... gracias por compartirlo jb, es una opción muy interesante para nuestro giga.

Cuando se activa la tarea del scp que tengo programada por la noche, se enciende el giga, ejecuta la copia, y cuando termina en lugar de apagarse automáticamente el tío se queda encendido hasta que pasa el tiempo que hay configurado para que se apague cuando no ha habido uso del vdr, que son 120 minutos en mi caso.

¿Puedo incluir alguna orden al final del script que me apague el giga si no está haciendo ninguna grabación en ese momento?

No quiero usar shutdownvdr por que entonces me lo apaga incluso cuando esté grabando.

El caso es que si ejecuto la tarea manualmente, el otro día cuando terminó, estaba viendo la tele, y me apagó el giga. No se por que no lo apaga cuando se ejecuta de madrugada y se queda encendido las dos horas después de termnar.

¿Alguna idea con esa orden para el final del script? El exit 0 que he puesto al final del script lo tengo por similitud con otros que he visto por que de hecho no se ni para que sirve.

el plugin scheduler no funciona bien en ese punto, a mi o me lo apaga siempre o no me lo apaga. Pero no he encontrado todavia dar con la opcion adecuada.

Me da en la nariz que si está encendido el giga al ejecutar una tarea, cuando termina, lo apaga (siempre que no haya que hacer alguna grabación o tarea dentro del tiempo indicado en la configuración para que lo mantenga encendido), y si está apagado y tiene que encenderlo, cuando termina la tarea, no lo apaga.