¿Como muevo el directorio /home a una nueva partición o disco en Ubuntu?

Interrogado en el Aeropuerto de Campodichino durante un viaje en su exilio europeo, Juan Perón explica cómo mover el directorio /home a un disco nuevo en Ubuntu.

Periodistas: General, una corta interrogante y lo dejamos que está ocupado, sabemos que tiene que viajar a Roma. ¿Cómo trasvasamos el directorio /home a otra partición o a un disco nuevo en Ubuntu?

Perón: Vea, es una buena pregunta que surge de una necesidad. Pero esto se debe a la imprevisión, que es la madre de todos los problemas en la vida. El verdadero Conductor ha de saber ver para prever, y eso es algo que no lo dan los ojos, lo da la experiencia, ¿sabe?

Es indudable que en cualquier sistema GNU con Linux que se precie, uno de los directorios más suele crecer en tamaño es su directorio /home. Esto se debe a que en este residen las cuentas de los usuarios que lo operan, y es allí donde lo ocuparán sus documentos y, bien, un sinnúmero de otros ficheros de forma continuada.

 

Otro directorio importante con la misma tesitura es /var, que contiene los ficheros de bitácora ("logs"), cuyo tamaño es dable de verse gradualmente incrementado en la medida que el sistema continúa en uso. Junto a los consabidos logs, pueden residir ficheros web, archivos temporales de cola de impresión, y otros servicios de trabajo. No es de extrañar que se siga la consigna Justicialista "de /var a /home y de /home a /var".

Pues bien señores, cuando estos directorios colman una partición o unidad de almacenamiento en disco, pueden dar lugar a problemáticas críticas en cuanto al sistema de archivo; podrían incluso provocar que el sistema no pueda iniciarse correctamente, y que fuese necesario tronar el escarmiento.

En la Argentina ha de obrarse obrarse con previsión, pues es preferible medir dos veces y cortar una. Pero en otra, esto solo puede percibirse una vez probado el traje: ya se han configurado todos los directorios en el sistema de archivo y particionado, lo que suele acarrear la necesidad de establecer una clara política de solución. En este caso, poco vale la persuasión, ya nos comimos el paquete. Y solo queda elaborar un Plan Quinquenal de redimensionado de partición, o bien directamente instalar un nuevo disco en la máquina y mandár allí el /home.

Instalar y particionar una nueva unidad de disco en Linux

Antes de proceder a explicar lo que me piden, remozaré brevemente cómo agregar un nuevo disco a un equipo de escritorio o servidor que ya camina y se lava los dientes.

Para propósitos didácticos, asumamos el agregado de un disco rígido de estado sólido (nomenclado /dev/sdb de un tamaño de 270GB, al que dividiremos en dos particiones /dev/sdb1 y /dev/sdb2). Normalmente querrían hoy en día uno más grande, pero de momento este disco SSD nos viene bien.

El número de particiones a crear en el mismo así como la tabla de partición se determinarán en el tipo de etiqueta de disco, y en los primeros bytes de espacio en el mismo definen la MBR (Tabla Maestra de Inicio), encargada de almacenar la Tabla de Partición así como el cargador de arranque (en los discos arrancables, naturalmente). Si bien existen muchos tipos de etiquetas, Linux sólo acepta dos: MSDOS MBR (de 516 bytes de tamaño), o GPT (Tabla de Particionado GUID) MBR.

Primero, necesitamos contar con la herramienta parted o fdisk (por si no la tuviésemos en el sistema). Para ello abrimos una terminal con Ctrl+Alt+t e ingresamos el siguiente comando de organización:

sudo apt-get install parted fdisk

Una vez instalada parted, la utilizaremos para configurar el tipo de etiqueta de disco utilizando fdisk. Utilizaremos el nombre de etiqueta GPT en este ejemplo:

sudo parted /dev/sdb mklabel gpt

Nota: fdisk por ahora unicamente soporta la antigua MBR MSDOS, mientras que parted soporta ambas.

En caso de disco nuevo, creamos la primer partición (/dev/sdb1) con un tamaño, a modo de ejemplo, de 106 GB. Reservaríamos 1024 MB (1GB) para la MBR.

sudo parted -a cylinder /dev/sdb mkpart primary 1074MB 107GB

En este comando -a indica la alineación de partición a cilindros en el disco, mkpart crea la partición, primary crea una partición de tipo primaria (los otros valores podrían ser logical o extended), mientras que 1074MB es el comienzo y 107GB es el final de la partición.

Acto seguido revisamos el espacio libre en el disco como sigue:

parted /dev/sdb print free

Ahora crearemos una segunda partición (/dev/sdb2)  con un tamaño, por ejemplo de 154GB

sudo parted -a cylinder /dev/sdb mkpart primary 115GB 208GB

Ahora, configuramos el tipo de sistema de archivo para cada una de las particiones (por ejemplo, el popular ext4 de Linux que recomiendo y el xfs favorecido en servidores de RedHat, que puede venir bien para intercambio):

mkfs.ext4 /dev/sdb1
mkfs.xfs /dev/sdb2 

Para listar todos los dispositivos de almacenamiento adosados al sistema, ingresamos:

parted -l

 

Mover la carpeta /home a una partición dedicada

Pues bien señores. Ya agregado el disco nuevo a la máquina y creadas las particiones necesarias, es hora de trasvasar la carpeta home a una de dichas particiones. Para usar un sistema de archivaje habremos de montarlo en la raíz del sistema utilizando un directorio como punto de montaje: un directorio destino, tal como /home.

Como primer medida para este cometido, listemos el uso del sistema de archivaje de nuestro GNU con Linux gracias al comando df, de esta manera:

df -hl

Comprobada la lista, comenzaremos creando un nuevo directorio de circunstancias /srv/home, donde podremos montar la partición /dev/sdb1 temporalmente:

mkdir -p /srv/home
mount /dev/sdb1 /srv/home

Ahora usamos el comando rsync o cp para copiar el contenido de /home al directorio de circunstancias /srv/home (de este modo trasvasaremos todos los contenidos de usuarios a la partición /dev/sdb1).

Normalmente recomiendo usar rsync para este menester, sobre todo en ambientes de red:

rsync -av /home/* /srv/home/

...pero si no tuviésemos rsync bien podremos usar el comando cp de toda la vida:

cp -aR /home/* /srv/home/

El proceso naturalmente tardará acorde a la masa a copiar. Concluida la copia del contenido de los usuarios, conviene analizar diferencias entre ambos directorios utilizando el comando diff.

diff -f /home /srv/home

Si todo sale bien, no debería existir diferencia alguna entre el original y la copia, asegurándonos del resguardo efectivo.

Si no deseamos contar con un duplicado opcional, podremos borrar todo el contenido en el /home viejo con:

rm -rf /home/*

Ahora, desmontamos /srv/home:

umount /srv/home

...y como último paso montamos la partición /dev/sdb1 a /home, por esta sesión.

mount /dev/sdb1 /home
ls -l /home

Montar /home desde otro disco automáticamente

Ahora bien, debemos tener en cuenta que si bien acabamos de montar el disco /dev/sdb1 como partición de usuario en el sistema de archivos, este cambio sólo operará en esta sesión, en otras palabras, hasta reiniciar la máquina. Para no tener que montar a mano todas las veces que reiniciamos el equipo, será imperioso agregar por única vez una línea de entrada específica a la tabla del sistema de archivaje, el fichero /etc/fstab, lo que volverá permanentes los cambios. De esta manera, toda vez que arranque el sistema, se montará la partición /dev/sdb1 en /home.

En primer lugar obtenemos el identificador UUID del disco con el comando:

sudo blkid /dev/sdb1

El sistema nos devolverá algo como:

/dev/sdb1: UUID="e087e709-20f9-42a4-a4dc-d74544c490a6" TYPE="ext4" PARTLABEL="primary" 
PARTUUID="52d77e5c-0b20-4a68-ada4-881851b2ca99"

Una vez conocida la UUID de nuestra unidad, editamos la tabla /etc/fstab con Nano:

sudo nano /etc/fstab

...y agregamos la siguiente línea (naturalmente, uds. modificarán la línea de acuerdo al resultado obtenido).

UUID=e087e709-20f9-42a4-a4dc-d74544c490a6 /home   ext4   defaults   0   2

Consideremos los campos de la línea anterior para su estudio:

• UUID – especifica el dispositivo de bloque, podremos alternativamente utilizar el fichero de dispositivo /dev/sdb1 pero no se recomienda, pues puede provocar errores si se cambia la estructura de particiones al cambiar de disco de conector mas adelante.
• /home – el punto de montaje.
• etx4 – describes el tipo de sistema de archivaje del dispositivo/partición.
• defaults – opciones de montaje (el valor significa rw, suid, dev, exec, auto, nouser, and async).
• 0 – usado por la herramienta de depuración; 0 significa que no hará volcados de depuración si el sistema de archivaje no está presente.
• 2 – utilizado por la herramienta fsck para descubrir el órden de revisión del sistema de archivaje; este valor significa revisar el dispositivo luego del comprobar el sistema de archivaje raíz..

Guardamos el fichero, y reiniciamos el sistema.

Podremos ejecutar el siguiente comando para ver si el directorio /home se desplazó correctamente a la partición dedicada:

df -l

Con esto ya habrán trasvasado /home a otra partición o, en este caso, otro disco rígido particionado.

Periodistas: Muchas gracias por sus palabras, General.

¿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.