Por mí y por todos mis compañeros

Algo tan sencillo y aparentemente inocuo como un punto de montaje puede convertirse en una letal arma de destrucción de paciencia/tiempo.

Hay una especie de regla no escrita que sigo desde hace bastante tiempo en las instalaciones de los servidores pertenecientes a OVH: centralizar todos los datos de servicios en /home. Los DocumentRoot de apache/nginx van en /home/www, las bases de datos en /home/mysql, etc...

¿Por qué?, porque hace algún tiempo, en las instalaciones por defecto, la partición con mayor tamaño era esa, así que lo pedía a gritos. Y hasta el momento no he cambiado porque todos los scripts de deploy, provisionamiento y demás están prepardos para ello. Vagancia.

Estos últimos días he tenido un problema que nunca me había pasado antes con un servidor. En este caso, inicialmente no había separación de particiones y todo estaba montado en /, pero ante la falta de espacio se contrató un disco a mayores con la idea de montarlo en /home de forma separada y mover el grueso de la información ahí dentro:

$ mkfs.ext4 /dev/sdb1
$ mkdir /home2
$ mount /dev/sdb1 /home2
$ rsync -az /home/ /home2/
$ umount /home2
$ mount /dev/sdb1 /home

Creamos la partición del nuevo dispositivo, la montamos como /home2, sincronizamos datos, desmontamos /home2 y la montamos de nuevo como /home. Hasta aquí todo correcto ¿no?. Pues no. Si el antiguo /home no se borra queda ahí consumiendo espacio y - lo más gracioso - como posteriormente montamos /dev/sdb1 como /home, queda oculto.

Así que, cuando vayas a mirar por qué sigue quedándose / sin espacio habiendo descargado todo "lo gordo" te podrá pasar como a mí y perder 3 horas de research con du, df, scripts en bash, lsof y demás. O quizás seas un poco más avispado y te des cuenta. Solución:

$ mv /home /home_old
$ mount /dev/sdb1 /home
$ echo "Comprueba que todo funciona, varias veces, y posteriormente:"
$ rm -rf /home_old

Moraleja: nunca juegues al escondite con tus sistemas. Y menos si eres tú el que pone unas normas que luego no recuerdas.