Migrando servidores. De MBR a GPT (y otras cosas en el proceso)

Saludos. Decíamos ayer...

Bueno, ayer no; que hace demasiado que no colaboro porque el trabajo de mantenimiento no da demasiadas novedades.

Ahora bien. Me he visto en la tesitura de migrar un servidor de máquina -no me preguntéis cómo se he conseguido, si os lo dijera tendría que mataros-. La nueva máquina no es ninguna maravilla de procesador pero sí que tiene un módulo interesante para los problemas de espacio -Microserver-, 16 GB de RAM -para el trabajo que va a hacer sobra la mitad- y dos discos duros de 4 TB rotatorios -no llegaba el presupuesto para SSD-. Incialmente, fantástico.

El nuevo juguete del centro.

Se suponía que venía con una maqueta de base, pero claro, no coincidía con la distribución de particiones que tenía y nadie se hacía cargo de la migración de los datos y usuarios que tenía, así que opté por clonar mi servidor -que está en Ubuntu 14.04, empezó en Ubuntu 12.04 y heredaba documentación y usuarios de una OpenSUSE 11.4... Tiene documentación acumulada desde 2008 aproximadamente.

Y llegamos al primer problema... Dos discos duros de 4 TB. Como venía de donde venía -y suerte que con la 12,04 ya me arriesgué a saltar a los 64 bits-, la tabla de particiones estaba en MBR. ¿Problema? No acepta discos de mas de 2 TB. Perdía la mitad de los discos.

Tras varias peleas y recordar documentaciones que había perdido en el Monte De la Documentación Perdida-Pero-Que-Está (dícese: Sé que hice esto antes, ¿pero cómo?) he pautado el que creo el mejor proceso para migrar en esas situaciones y no tener que estar revisando y reconfigurando todos los servicios que puedes haber montado. Os la ofrezco y me decís qué os parece:

1. - Clonamos el servidor original con clonezilla. Sin compresión, disco a disco dado que es más rápido. Si no es factible por el tamaño de los discos, pues comprimimos.
2. - En ese disco sin comprimir, con tabla MBR, le aplicamos el comando gdisk -w /dev/sd... (a, b, c; el disco que sea). La única función de ese comando es convertir a velocidad de vértigo una tabla MBR en una GPT (aunque si no ponéis el -a podréis ver el resto de opciones).
3. - Asumiendo que tenéis particiones lógicas, la Partición Extendida ahora habrá desaparecido y todas las demás serán particiones primarias. Habrá que recuperar la marca de boot (a la cual ahora se le añade automáticamente la marca esp) a donde tengamos el boot (en mi caso, partición 3)
4. - Aunque no usemos UEFI ni Secure Boot, con GPT ha de existir una partición de al menos 1 MB con la marca grub_bios. La generamos -al final del disco, por ejemplo- con el sistema de ficheros que os venga en gana, NO ES OPTATIVO, SI NO SE CREA GRUB NO ES CAPAZ DE INSTALARSE EN GPT.
5. - Empezamos a mover y ampliar particiones para aprovechar el nuevo disco. A nuestro gusto. Como es GPT, va bien seguir lo que dice el manual de definición del formato y dejar 128 MB entre partición y partición. No supone mucho espacio y mejora el rendimiento.
6. - Una vez acabado, hay que rearmar el GRUB desde el modo live. Podéis hacerlo a mano o, si tenéis acceso a la red, instalar en la live el programa boot-repair, que permite reinstalar rápidamente el GRUB. Recordad -si es un caso como el que estoy citando- eliminar las referencias a UEFI, Secure Boot y cosas feas parecidas. Suele ir rápido.
7. - Para asegurarme, tras el primer arranque ya en el sistema real lo primero que hago es un update-grub2 desde root y reiniciar. Sí, soy un paranoico.
8. - Os encontrareis con que no tenéis acceso a la red. Es uno de los problemas de Clonezilla, que mantiene las persistencias de las placas y las que detecta de nuevas las añade. De normal haría una asignación y ya está, pero en este caso eso pudiera ser peligroso porque igual algún servicio busca la etiqueta eth0 y si ahora es la eth2, ese servicio no funcionará.
9. -¿Solución? Editáis el fichero /etc/udev/rules.d/70-persistent-net.rules, comentáis las placas que estarán como eth0 y eth1 (las de la máquina anterior) y modificáis las de eth2 y eth3 como 0 y 1. Con un reinicio el sistema reconocerá las placas correctamente, activará las configuraciones adecuadas  -que han sido clonadas- y todo listo.

Muestra de cómo el sistema asigna los interfaces de red

Voilà. Nos vamos al cliente más cercano a comprobar que los usuarios pueden entrar y se acabó el problema. A partir de ese momento podemos aprovechar toda la potencia y espacio del servidor nuevo sin haber perdido un ápice de la información o servicios activados.

Aunque parezca sencillo, hay que tener paciencia. Las clonaciones de 500 GB no son una broma y tardan, tanto en clonar como en restaurar, hay que tener paciencia.

Por otro lado, no se os ocurra retirar el servidor viejo al menos en una semana; si hay cualquier cosa rara, se vuelve a enchufar y aquí no ha pasado nada. Si después de un mes no hay reclamaciones ya puedes empezar a plantearte usar ese servidor para otras funciones... Algo se me ocurrirá.

¿Que os ha parecido? Venga, hasta otro rato.

Tweet