El tema de los respaldos (también llamados backups) resulta preocupante para quienes el activo más preciado de su empresa es la información, pero ¿qué nivel de importancia le damos cuando confeccionamos el presupuesto de inversión tecnológica? Sabemos lo urgente/importante que es mantener los respaldos en sitios seguros y, en algunas ocasiones, hacerlos incluso redundantes. Pero si contamos con baja inversión tecnológica, no queda otra que trabajar con lo que tengamos a nuestro alcance.

Si queremos disponer de un buen respaldo, de tal forma que si ocurre un desastre podamos recuperar nuestros datos más recientes, debemos hacernos a la idea de que necesitaremos un servidor remoto con amplio espacio de almacenamiento. Éste puede estar formado por algunos discos de gran capacidad, por ejemplo. Pues bien, en GNU/Linux disponemos de más de una forma de diseñar nuestro respaldo, tantas, que nos podemos permitir soluciones a medida.

Sabemos de la existencia de RSYNC, TAR y GZIP, algunos de los programas con los que podemos realizar respaldos. Pues para esta ocasión planteamos una solución de nuestro inventario básico de conocimientos: TAR+SSHPASS.

Vamos a asumir que tenemos nuestro servidor de producción y, como en la mayoría de los casos, nuestro respaldo, en el mismo centro de datos, con históricos de 10 años que nunca han fallado cuando los necesitamos, pero ¿y si ocurre un desastre en nuestro mismo centro de datos? La única solución sería volver a nacer y considerar, esta vez, tener los respaldos en otro lugar. Pero en esta ocasión, la de ese primer hipotético desastre, estaríamos listos…

Para implementar esta solución casera basta con instalar SSHPASS y hacer uso de TAR para generar nuestro respaldo. El comando a ejecutar es muy sencillo:

tar cfz - /Directorio/A/Respaldar/ | sshpass -p 'ClaveDelServidorRemoto' ssh usuario@IP "cat > /Directorio/En/El/Servidor/Remoto/NombreDelREspaldo.tar.gz"

Descripción del Comando:

tar cfz : Creamos el archivo comprimido de los archivos que hay en el directorio que especificamos.
sshpass -p : Pasamos la clave en texto plano del servidor remoto.
ssh usuario@IP : El nombre de usuario y la IP del servidor remoto.
cat > : Escribe la salida en el archivo ubicado en el servidor remoto.

Si en el sitio donde almacenamos nuestros respaldos existe libre acceso por cualquier motivo, debiéramos pensar en encriptar el respaldo, para evitar que, por ejemplo, alguien se haga con nuestros valiosos datos y queden expuestos libremente o, incluso, puedan ser vendidos en el mercado negro de la publicidad digital.

Para encriptar nuestros archivos podemos hacer uso del siguiente comando:

openssl enc -des -aes-256-cbc -in NombreDelREspaldo.tar.gz -pass pass:ContraseñaParaElArchivo -out NombreDelREspaldoCifrado.tar.gz

Creo que es un momento perfecto (bueno, un poco antes hubiera estado mejor =) para esta publicación, así celebramos el 31 de Marzo, ¡Día Internacional del Respaldo!

0 0 votos
Article Rating
Artículo anteriorFLAC: La toma fotográfica (V)
Artículo siguienteA cada cual lo suyo
Foto del avatar
Bloguero de tiempo incompleto, no creo en la seguridad de información, es mas una distorsión mental, que una realidad. Hay solo dos opciones en la vida[0,1]. La peor desicion, no tomarla, pro-debian y anti-microsoft, no es racismo, es solo un tema de css.
Subscribe
Notificarme de
guest

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

7 Comments
más antiguo
más nuevo más votado
Reacciones en línea
Ver todos los comentarios
Marcelo

Gracias por el artículo.

Gaspar Fernández

Transmitir tan alegremente un backup por la red puede tener problemas. Si por algún casual hay un corte, tendríamos que empezar de nuevo la copia. Bueno, yo me he tirado dos años haciendo así la copia de mi servidor, al vuelo y transmitiendo por ssh, pero es verdad que algún que otro día no la he recibido completa. Lo bueno es que de esta forma, no gastamos disco duro en la máquina en la que hacemos la copia de seguridad porque puede ser limitado. Otro detalle, lo suyo es utilizar pares de claves SSH en lugar de clave a secas. Si no hay más remedio, vale, pero casi siempre, hay remedio. Una cosita más, y ya me callo 🙂 Es muy útil generar un md5 o un shaX del archivo antes de transmitirlo y luego en el servidor de destino y compararlos, más que nada para asegurarnos de que todo… Leer más »

lu pa

Que tal utilizar rsync y claves ssh-id para no tener q poner clave en texto plano?
Rsync permitiría retomar en caso de corte.