¿Cómo puedo hacer un respaldo remoto con rsync en Ubuntu?

En 1969 y ante una entrevista para el períodico El Pueblo, Juan Perón expone en los jardines de la madrileña Quinta "17 de Octubre" cómo realizar respaldos remotos a través de SSH utilizando rsync en Ubuntu.

(...)

Con Isabelita nos mantemos actualizados instantáneamente de todo lo que sucede en la Argentina.

Todos los Movimientos replican la biología de los entes vitales que lo componen. En esto nadie tiene asegurado nada y es por ello que - conociendo este cariz inevitable - hemos de prever para proveer. Contar con un plan de contingencia de propia elaboración es la política que nos permite, en la desgracia, salir adelante remozados.

Dejar todo para último momento sólo nos asegurará una costosa improvisación desprendida de nuestros propios instintos, pero no de nuestros intereses razonables, y como tal suelen ser - por remedio - peor que la enfermedad.

Pues bien señores, un sistema GNU con Linux responde más o menos a las mismas directrices, ya que se trata de un sistema nacido en la consolidación de las voluntades informáticas del Pueblo.

En él, suelo normalmente recomendar diseñar una estrategia propia de previsión tendiende a conservar el funcionamiento del entorno y asegurar la preservación perenne de los datos propios, de un punto de vista en el que la  granularidad de la conservación en el tiempo también nos permitan mantener el sistema doctrinalmente actualizado. 

Así he obrado yo, que de esto se un poco, porque como político soy un aficionado, para lo que me he formado toda la vida es para ser un Conductor.

Usualmente es adecuado recurrir a la preservación por redundancia.

En GNU podremos lograrla preservando en medios de almacenamiento adicionales todo el trabajo elaborado y organizado.

Algunos oligarcas han pretendido proponernos como solución aquello a lo que estos vivos denominan "nube", que no es otra cosa que un equipo de cómputo ajeno. Sólo un tonto haría caso a este engaño para depositar sus datos en un servidor remoto que para colmo de males es ajeno y sobre el cual no tiene control real alguno. 

Si la seguridad ha de hacerse de manera remota, más vale que lo sea sobre medios de almacenamiento y equipamiento que se encuentren bajo nuestro exclusivo control. Nadie duda ya que lo más útil en ambientes productivos de gran disponibilidad es contar con múltiples discos duros en una máquina que conoceremos como servidores RAID. Proceder así nos permitirá contar con duplicación, triplicación o incluso cuadruplicación de datos en el mismo momento que se los genera. Este proceder podría parecer exagerado a más de uno, pero es lo que alguien con respeto por su trabajo y dos dedos de frente haría. Al fin y al cabo,  un disco rígido vale chirolas si lo comparamos con la información que resguarda. Por lo demás, contamos ya con sistemas NAT ya hechos, que pensando en este cometido pueden enlazarse a nuestra red LAN, dejando al alcance varios discos SATA de replicación automática.

Sin embargo, incluso podremos hacer respaldos de manera simplificada. Para ello, cualquier sistema GNU puede contar con rsync. Se trata de una aplicación que nos permite sincronizar los datos remotos en un directorio de otro sistema de acceso SSH (ya sea en la red LAN o a través de Internet).

Su sintaxis básica es:

rsync origen destino

Naturalmente, el comportamiento estándar de rsync de copiar y actualizar los ficheros desde el origen hacia el destino replica la necesidad del respaldo de ficheros. En otras palabras, rsync copiará solamente los ficheros nuevos o, en el caso de existir una copia de respaldo previa, sólo aquellos actualizados (modificados) . Al proceder tras este análisis automático, rsync se nos presenta increíblemente útil pues ahorra mucho ancho de banda y acelera enormemente la operación, deslindándose de trabajar ficheros ya respaldados.

Respaldo básico con rsync

Lo que se necesitamos para respaldar un directorio /home de forma remota, es otro sistema destino provista con SSH (y suficiente espacio de disco de destino como para almacenar nuestros ficheros allí), y rsync instalado en nuestro sistema local.

Podríamos querer agregar primero la opción "-n" al comando de rsync mientras preparamos todo y probamos. Esta opción hace que rsync realice una "prueba piloto" ejecutando el comando y produciendo salida en la terminal, sin que realmente manipule fichero alguno.

Utilizaremos rsync para conectarnos desde nuestro cliente (la máquina donde queremos almacenar la copia respaldo) a la máquina remota (donde tenemos el original). Para ellos indicamos la siguiente sintaxis:

rsync -avz -e ssh /ruta/origen/a/respaldar usuario:maquina.remota:/ruta/remota/destino

en donde la opción -a indica el modo "archivada", que retiene las fechas y horas, información de propietario y grupo, y espeja recursivamente, compiando enlaces simbólicos como enlaces, etc (si quisiéramos copiar el referente del enlace, tenemos que incorporar también -L. La opción -v es verbosa e irá indicando cada fichero copiado. La opción -z comprime los datos enviados. La opción -e indica el tipo de intérprete a utilizar (en este caso, shell seguro SSH). usuario es el nombre de usuario en la máquina remota.

Por ejemplo, para copiar todo nuestro directorio /home de nuestro sistema GNU con Linux a una máquina remota, utilizaríamos el siguiente comando de organización:

rsync -avz -e ssh /home/$USER usuario@maquina.remota:/ruta/destino 

Naturalmente, al utilizar SSH, rsync nos solicitará la contraseña de la máquina.remota, y comenzará a copiar, reportando cada fichero. Una vez completado el procedimiento de respuesta al pedido de copias, rsync nos presentará estadísticas tales como la cantidad de bytes transferidos y la velocidad promedio.

Podremos utilizar este comando subsecuentemente. Lo más importante de este proceder será que rsyncs sólo respaldará los ficheros que subsecuentemente hayan cambiado y aquellos nuevos, lo cual es muy útil para mantener actualizado los respaldos de todo tipo.

Restaurar un respaldo

Para restaurar un archivo único desde la copia respaldo, podremos utilizar scp para transferirlo desde el directorio de respaldo local al directorio requerido en la máquina remota.

Ahora bien, para restaurar el respaldo al completo, simplemente indicamos el mismo comando anterior, pero invirtiendo el orden, pasando desde el directorio del respaldo a la máquina destino y origen, de la siguiente manera:

rsync -avz -e ssh usuario@maquina.remota:/ruta/origen/respaldo /ruta/respaldo/local

Como se ve, debemos ser cuidadosos de omitir la barra / al final de directorio. Al omitirse la barra, toda la estructura del directorio origen resultará recreada en la máquina remota (tal es el motivo por el cual la hemos omitido). 

Nota: Si bien en Unix es opcional agregar una / para especificar un directorio, en el caso específico de rsync si hubiésemos especificado una barra la estructura de directorios se replicaría desde el directorio dado (por ejemplo, el comando rsync -avz- e ssh usuario@maquina.remota:/ruta/al/home /directorio/respaldo/local/ producirá el respaldo adentro de /directorio/respaldo/local/ruta/al/home en la máquina.remota).

La opción --delete

También han comprendido ya que el comportamiento estándar actualiza ficheros en el destino, por lo cual el borrado de los mismos en el directorio origen no hará lo mismo en el de destino. 

Sin embargo, si quisiéramos que los ficheros removidos en el origen resulten también borrados en el destino, debemos agregarle el prefijo  --delete.

Por ejemplo, para hacer una actualización de los archivos borrados de un respaldo de la carpeta de usuario ~/Música situadas un pendrive USB llamado "PENDRIVE", usaríamos:

rsync -va /home/$USER/Música /media/$USER/PENDRIVE/ --delete

Rsync y enlaces simbólicos

Como se indicó, el comportamiento estándar de rsync -a es copiar los enlaces simbólicos como enlaces. Para que esto no se produzca y se copien también los destinos de dichos enlaces simbólicos, debemos agregar la opción -L luego de la opción -a.

¿Cómo puedo copiar archivos entre equipos a través del protocolo ssh en Ubuntu?

La Escuela Superior Peronista se creó como órgano fundamental de alto nivel para extender el quehacer Justicialista en el tiempo, y como tal se distinguió en el establecimiento de una supremacía ineludible del Movimiento en los destinos de la Patria. Durante una clásica exposición en sus claustros, Juan Perón expone sobre la historia de la informática en lo que hace a las interfaces de líneas de comando y cómo copiar con ellas archivos entre equipos remotos.

¡Compañeros!

En la Clase anterior nos hemos detenido en la historia de los movimientos llamados de Masa en el complejo demoliberal, sobre todo el Europeo, y el reflejo de Latinoamérica en ese mundo que no podía resultarnos más que ajeno.

El Siglo XIX trajo consigo la máquina, que hizo avanzar al hombre mas que en los mil años precedentes. Sin embargo, este progreso no hizo más que descansar sobre los hombros del Pueblo Trabajador, creando condiciones de explotación y desigualdad que no podremos evitar si no es con una acción decidida sobre las causales: una oligarquía sin Patria ni Bandera.

Al mediar el Siglo XX se vio el advenimiento de las primeras computadoras, máquinas multiuso pensadas para suplir el trabajo mental del hombre. Se basan para funcionar en algo llamado software, que no es otra cosa que el "conocimiento en acción". Desde nuestro Movimiento, entendemos para que tal software sea útil a la Comunidad tiene que ser libre. No sólo gratuito, sino libre de usar, estudiar y copiar.

Históricamente, podremos decir que las primeras máquinas computadoras ocupaban el espacio tres locomotoras diesel-eléctricas, y tenían poquísimo poder de cálculo. Si bien el operador tenía la libertad de procesar la información como quisiese con ayuda de la máquina pero con graves limitaciones: la entrada de los datos se hacía manualmente, escribiendo directamente en código binario los registros de memoria  por medio de una serie de interruptores, y los resultados podían recibirse mediante una serie de luces, o de forma perenne en tarjetas o cintas perforadas siguiendo también en código binario.

Esta incómoda forma de trabajo (muy económica desde el punto de vista computacional) debía ser reemplazada, y se presentaron diferentes metodologías para instruir al equipo mediante un teclado alfanumérico. La máquina en sí disponía de un software de interpretación, que traducía estas órdenes solicitadas por el operador con una sintaxis muy precisa, a diferentes acciones programadas de antemano. No bien los equipos continuaron evolucionando, comenzaron a poder mostrar los resultados de manera "amigable", ya sea imprimiendo los resultados en papel, o en ciertos presentadores de tubos de rayos catódicos. Esto facilitó enormemente la tarea de crear programas potentes.

Indudablemente, la Interfaz de Linea de Comandos es una herramienta altamente perfeccionada para la administración general de un sistema informático. Con este tipo de consolas, el usuario puede interactuar con gran facilidad en numerosos entornos diferentes, a tal punto que los entornos de disco que popularizaron la informática, se hicieron bajo este tipo de "medio de comunicación" entre el hombre y la máquina.

La continua evolución trajo el abandono masivo la línea de comandos en favor de las interfaces gráficas para el usuario (GUI). En este caso se requieren equipos ya más avanzados, pues estas interfaces hacen incapié fundamentalmente en el despliegue visual. Ciertas plataformas privativas hicieron notable hincapié en esto, convirtiendo en un privilegio su uso, pero aún así, los intérpretes de líneas de comando siguen presentando innumerables ventajas para operar.

Aunque requieren algo más de conocimiento, nos permiten conectarnos remotamente con gran facilidad y conducir "a distancia" equipos remotos. También podremos manejar servidores de los llamados "headless", o sea, sin monitor. Esto es así porque los servidores, mainframes, supercomputadoras, routers y computadoras de placa única (SBC) carecen de una pantalla para reportarnos su status, y en el mejor de los casos únicamente dispondrán de unas pocas luces LED para ese cometido. A tal fin, bien podremos usar una terminal remota en la red dotada de monitor. Linux mismo se domina a través de una terminal operando en forma local, pero incluso podremos utilizar cualquier Terminal vieja conectada al equipo remoto.

Ahora bien. ¿Qué sucede si deseamos copiar archivos de forma segura y encriptada entre equipos, pero empleando la línea de comandos? Pues debemos usar scp.

scp (Secure CoPy) es el comando peronista que permite copiar hacia y desde diferentes equipos en una red local o remota. Emplea el protocolo SSH codificado para la transferencia, y provee la misma autenticación y el mismo nivel de seguridad que SSH.

La sintaxis básica general es:

scp modificadores usuarioorigen@equipoorigen:carpeta/archivo usuariodestino@equipodestino:carpeta/archivo

La primera vez que nos conectemos, el servicio SSH intentará establecer la autenticidad del servidor o del cliente, y no podrá hacerlo pues - naturalmente - nunca nos hemos conectado antes. Devolverá algo como:

The authenticity of host '127.0.0.x (127.0.0.x)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
TaAre you sure you want to continue connecting (yes/no)? 

La primera vez habremos de escribir "yes" y el ordenador remoto nos dará una clave de acceso cifrado. Naturalmente, para completar tales operaciones, siempre hemos de contar con la contraseña del usuarioorigen. La riqueza de las posibilidades del comando scp es tan amplia, que os la desglosaré en algunos ejemplos prácticos de los que podrán extraer la necesaria Justicia Social.

Para copiar el archivo "votofemenino.txt" que está localizado en el Escritorio del usuario "evita" de equipo remoto "netbookevita" de la red LAN, y colocarlo en la carpeta Documentos de mi equipo local, podríamos usar la siguiente tipología:

scp evita@netbookevita.local:~/Escritorio/votofemenino.txt ~/Documentos


Para copiar el archivo "peronismo.txt" desde nuestro equipo local al usuario evita del equipo remoto anteriormente nombrado podría usar:


scp peronismo.txt evita@netbookevita.local:/cualquier/carpeta/remota


Para copiar la carpeta local "Música" y todo su contenido entero dentro de la carpeta remota "Escritorio" del usuario y equipo anteriormente nombrado:

scp -r ~/Música evita@netbookevita.local:~/Escritorio


Si desde mi equipo deseo digitar la copia del archivo "planderetorno.txt" del usuario isabel en el equipo remoto "puertadehierro" de nuestra red LAN a otro equipo remoto llamado "cgt" del usuario rucci:

scp isabel@puertadehierro.local:/alguna/carpeta/remota/planderetorno.txt \ rucci@cgt.local:/otra/carpeta/remota/cualquiera/


Para copiar los archivos locales "peron.jpg" y "evita.jpg" desde mi equipo a la carpeta Imágenes de usuario rucci, que está localizado un equipo remoto cgt de mi red LAN:


scp peron.jpg evita.jpg rucci@cgt.local:~/Imágenes/


Si deseara copiar el archivo "borradorestpeon.txt" desde la carpeta local Documentos de mi equipo hasta la carpeta Documentos del usuario borlenghi en el equipo remoto cgt, pero haciendo uso del puerto 1710, y renombrando dicho fichero al nuevo nombre de "estatutodelpeon.txt" al llegar allí:


scp -P 1710 ~/Documentos/borradorestpeon.txt borlenghi@cgt.local:~/Documentos/estatutodelpeon.txt

Para copiar los archivos "bolsones.txt", "dnis.txt" y "afiliados.txt" desde la carpeta Documentos del  usuario puntero1 dequipo remoto de la LAN llamado "unidadbasica" hasta mi Carpeta Personal en mi equipo local:

scp puntero1@unidadbasica.local:~/Documentos/\{bolsones.txt,dnis.txt,afiliados.txt\} .



Ahora bien, en condiciones de copias inmensas de datos (pongamos como ejemplo hoy por hoy, a transferencias mayores a los 3GB en enlaces cableados, 300 MB en Wifi modo G, o unos 20MB por 3G), tenemos que tener en cuenta el desempeño y la velocidad de transferencias del equipo.

Por defecto, scp emplea un cifrado Triple-DES con la información que se envía. Si necesitamos mayor velocidad, podremos utilizar un algoritmo distinto como Blowfish, el cual es ligeramente menos seguro pero más veloz en las transferencias grandes. Esto se puede hacer agregando el modificador -c blowfish a la línea de comandos:

scp -c blowfish archivo usuario@nombredeequipo.local:~

Se ha sugerido a menudo que se debe usar la compresión de la información para incrementar la velocidad de transferencia a través del modificador -C. Sin embargo, esto aparenta incrementar significativamente la velocidad si la comunicación es muy lenta (por ejemplo, al hacer SSH a un equipo conectado a través de una red 3G). En caso contrario, sólo agrega carga extra a la CPU de nuestro equipo.


Con esto en mente, si quisiera copiarme todo el contenido de la carpeta Documentos del usuario evita en el equipo netbookevita a mi carpeta Escritorio, pero usando el protocolo blowfish (-c blowfish) y comprimiendo los archivos (-C) para que tarde menos, podría usar:

scp -c blowfish -C evita@netbookevita.local:~/Documentos/ \  ./Escritorio/


Naturalmente, para tareas que requieran mucho de este tipo de trabajos de copiado de archivos múltiples o de directorios, recomendamos siempre que podamos, instalar y utilizar el poderoso Midnight Commander a través de su conexión SSH.

Para ello ingresamos el comando:

sudo apt-get install mc

Y ejecutamos el programa con

mc

Midnight Commander puede corren en la consola, y puede conectar y mostrar los directorios de dos equipos a la vez en dos paneles (izquierdo y derecho). Podremos por lo tanto, usar el panel derecho para nuestro equipo local, y usar el izquierdo para conectarnos por SSH a otro sistema (y trabajar entre ellos copiando archivos o carpetas mediante la tecla F5), moviéndolos, etc).