Cómo trasplantar un servidor Linux con WordPress a un ordenador nuevo sin morir en el intento

Introducción: cuando el servidor se apaga y la web desaparece

Un servidor Linux puede funcionar durante años de forma silenciosa hasta que un día deja de hacerlo. La máquina se apaga, reinicia de forma errática, no supera el arranque o simplemente no permanece encendida más de unos segundos. Cuando ese equipo aloja un servidor web real —con Nginx, MariaDB, WordPress, certificados SSL, reglas de router, copias de seguridad y varios discos— el problema deja de ser una reparación informática y se convierte en un incidente de continuidad de negocio.

En ese momento aparecen varias decisiones urgentes: intentar reparar el equipo antiguo, llevarlo a una tienda, comprar piezas sueltas, montar un ordenador nuevo o trasplantar directamente los discos a otra máquina. La opción más rápida no siempre es la más barata, y la más técnica no siempre es la más segura. Este artículo explica un escenario realista: cómo mover una instalación Linux existente con servidor web a un ordenador nuevo, qué puede salir mal y cómo reducir el tiempo de recuperación sin improvisar más de la cuenta.

El problema real no es comprar un ordenador: es recuperar el servicio

Cuando una web está caída, es fácil centrar toda la atención en el hardware: placa base, fuente, CPU, ventiladores, memoria RAM o discos. Sin embargo, el objetivo principal no es tener un ordenador perfecto, sino volver a servir la web cuanto antes. En términos de continuidad de negocio, lo importante es el tiempo total de recuperación: conseguir una máquina funcional, arrancar el sistema antiguo, recuperar red, comprobar servicios, validar puertos, revisar reglas NAT y confirmar que la web responde desde fuera.

Por eso, antes de comprar piezas sueltas conviene hacer una pregunta sencilla: ¿qué opción reduce más incertidumbre? Montar una placa nueva con una fuente, caja, RAM y CPU disponibles puede parecer eficiente, pero introduce muchos puntos de fallo: cables mal conectados, BIOS incompatible, RAM que no entrena, fuente no probada, conectores frontales mal puestos o dudas sobre refrigeración. Comprar un sobremesa estándar ya montado puede ser menos elegante, pero reduce drásticamente el riesgo de no arrancar.

En una emergencia, un ordenador aburrido, estándar, abrible y con puertos SATA disponibles puede ser mejor que una solución perfecta sobre el papel. Lo ideal es una torre o semitorre común, con placa base estándar, fuente ATX normal, gráfica integrada, 32 GB de RAM, SSD propio y espacio para conectar los discos antiguos.

Primer principio: no reinstales Linux si puedes trasplantar el disco

Ante una máquina averiada, mucha gente piensa inmediatamente en reinstalar Ubuntu, configurar Nginx, restaurar bases de datos, copiar ficheros, reconstruir certificados, reconfigurar PHP y restaurar WordPress. Esa opción puede funcionar, pero consume muchas horas y multiplica los errores.

Linux suele tolerar bastante bien un cambio de placa base, CPU y chipset. A diferencia de otros sistemas más dependientes del hardware original, una instalación Linux puede arrancar en una máquina nueva si el disco de sistema está sano y el arranque UEFI/GRUB sigue operativo. Por eso, en un incidente urgente, la estrategia más rápida suele ser intentar primero el trasplante directo del disco de sistema.

El procedimiento recomendado es incremental: conectar solo el disco de sistema, arrancar, comprobar que Linux llega a consola, resolver Secure Boot si aparece, recuperar red y después conectar el disco de datos. Meter todos los discos a la vez, dejar conectado el SSD nuevo con Windows y cambiar muchas cosas en BIOS al mismo tiempo aumenta la confusión.

El error típico: no etiquetar bien los discos

Uno de los fallos más tontos y más caros en tiempo es no saber qué disco contiene el sistema y cuál contiene los datos. En un servidor con un SSD de sistema y otro SSD de datos, ambos pueden parecer similares cuando se desmontan deprisa. Si se conecta primero el disco equivocado, el ordenador puede no arrancar o mostrar errores que parecen más graves de lo que son.

La solución es sencilla: etiquetar físicamente los discos. Una pegatina con “SISTEMA”, “DATOS”, “BACKUP” o “WORDPRESS” puede ahorrar horas durante una emergencia. Además, conviene documentar modelos, capacidades, UUID, puntos de montaje y función de cada unidad.

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINT,MODEL

Este comando permite revisar qué disco es cada uno una vez arrancado el sistema. Pero en plena avería, con el servidor apagándose y la web caída, una etiqueta física visible vale más que cualquier comando.

Secure Boot: el primer obstáculo al arrancar en hardware nuevo

Al mover un disco Linux a un ordenador moderno puede aparecer un error relacionado con Secure Boot, shim o SBAT. No significa necesariamente que el disco esté roto. Significa que el firmware UEFI de la máquina nueva está aplicando políticas de seguridad que no aceptan el cargador de arranque instalado en el disco antiguo.

Un mensaje típico puede ser similar a:

Verifying shim SBAT data failed: Security Policy Violation
Something has gone seriously wrong: SBAT self-check failed

En una recuperación urgente, la solución práctica suele ser entrar en BIOS/UEFI y desactivar Secure Boot temporalmente. Después se guarda la configuración y se intenta arrancar de nuevo desde el SSD Linux. Si el sistema arranca, el problema no era WordPress, ni la base de datos, ni el disco: era la política de arranque seguro del nuevo equipo.

La red: donde se pierde más tiempo del que parece

Una vez Linux arranca, el siguiente obstáculo suele ser la red. El servidor antiguo tenía una o varias tarjetas Ethernet, direcciones MAC concretas, reservas DHCP en el router y reglas NAT asociadas a una IP interna. Al cambiar de máquina, cambia la interfaz de red, cambia el nombre del dispositivo, cambia la MAC y puede romperse la reserva DHCP.

En Linux moderno podemos ver las interfaces con:

ip a

Los nombres pueden ser distintos: eno1, enp3s0, enx..., eth0 o similares. Lo importante es identificar cuál tiene enlace físico y cuál recibe IPv4.

También conviene inspeccionar NetworkManager:

nmcli device status

Si aparece una interfaz como unmanaged, NetworkManager no la está gestionando. Si aparece como connecting (getting IP configuration), intenta obtener IP por DHCP. Si aparece como connected, ya hay conexión activa. No son matices menores: cada estado apunta a un problema distinto.

DHCP, MAC y router: el enemigo invisible

En muchos servidores domésticos o de pequeña oficina se utiliza DHCP con reserva de IP. El servidor no tiene una IP fija configurada en Linux, sino que el router le asigna siempre la misma dirección en función de su MAC. Esto es cómodo hasta que se cambia la tarjeta de red.

Si el servidor antiguo tenía la IP 192.168.1.170 asociada a una MAC concreta, el ordenador nuevo no recibirá necesariamente esa misma IP. Habrá que actualizar la reserva DHCP del router para la nueva MAC. Si se usa un adaptador USB-Ethernet de emergencia, también tendrá su propia MAC.

Un detalle importante: algunos routers de operador pueden comportarse de forma errática tras cambiar reservas DHCP. Pueden mantener leases antiguos, tardar en aplicar cambios o no entregar IP hasta reiniciar. En una emergencia, reiniciar el router después de cambiar reservas DHCP puede ahorrar mucho tiempo.

Adaptador USB-Ethernet: el plan B que puede salvar la noche

Si la tarjeta integrada enlaza pero no recibe tráfico, no responde al router o no obtiene DHCP, un adaptador USB-Ethernet puede ser una solución de contingencia muy eficaz. No es elegante, pero puede devolver conectividad en minutos.

Al conectarlo, Linux suele crear una interfaz con nombre parecido a:

enx00606ed5a4c7

Después se comprueba si recibe IP:

ip a
nmcli device status
ping -c 3 8.8.8.8

Si el adaptador USB obtiene una IP como 192.168.1.100 y responde a Internet, ya tenemos un camino funcional. En ese momento no conviene seguir depurando la tarjeta integrada. Primero se levanta el servicio web; después se investiga la causa con calma.

No basta con tener IP: hay que revisar las reglas NAT

Una web alojada en casa o en una oficina depende normalmente de reglas de redirección de puertos en el router. Si el router reenvía los puertos 80 y 443 a 192.168.1.170, pero el servidor nuevo está en 192.168.1.100, desde Internet la web seguirá caída aunque Nginx funcione perfectamente.

Hay dos formas rápidas de resolverlo:

La primera es cambiar las reglas NAT para que apunten a la nueva IP. La segunda es hacer que el servidor recupere la IP interna esperada por el router. En una recuperación urgente, suele ser mejor tocar lo mínimo: si las reglas antiguas apuntaban a 192.168.1.170, lo más directo es lograr que el servidor vuelva a tener esa IP.

Cuando hay varias interfaces, puede ocurrir que una tenga 192.168.1.100 y otra 192.168.1.170. Lo importante es que la IP destino de las reglas NAT esté realmente activa en el servidor y que Nginx escuche en 0.0.0.0:80 y 0.0.0.0:443.

Comprobar servicios: Nginx, base de datos y puertos

Cuando la red ya funciona, no hay que asumir nombres de servicios. Un servidor WordPress puede usar MariaDB o MySQL, Nginx o Apache, PHP-FPM con distintas versiones y configuraciones antiguas. Lo correcto es inspeccionar.

systemctl --type=service | grep -Ei 'nginx|apache|httpd|mysql|mariadb'

Si los servicios aparecen activos, el siguiente paso es comprobar puertos:

ss -tulpn | grep -E '(:80|:443|:3306)'

Una salida correcta debería mostrar Nginx escuchando en 80 y 443, y la base de datos escuchando localmente o en el puerto esperado. Después se prueba desde el propio servidor:

curl -I http://localhost

Una respuesta 301 Moved Permanently hacia HTTPS puede ser perfectamente normal si el servidor fuerza SSL. Lo importante es que Nginx responda.

Verificaciones mínimas antes de declarar la web recuperada

Antes de dar el incidente por cerrado, conviene comprobar al menos cinco cosas:

• Que el servidor tiene la IP interna esperada.
• Que las reglas NAT del router apuntan a esa IP.
• Que Nginx está activo y escucha en 80/443.
• Que la base de datos está activa.
• Que el dominio responde desde fuera de la red local.

Comandos útiles:

ip a
ip route
systemctl status nginx
systemctl status mariadb
ss -tulpn | grep -E '(:80|:443|:3306)'
curl -I http://localhost
df -h

También hay que comprobar los discos montados. Si el servidor separaba sistema y datos, una web puede arrancar parcialmente pero fallar si el disco de datos no está montado donde WordPress espera.

Qué hacer después de recuperar el servicio

Cuando la web vuelve a servir contenido, la tentación es apagar el cerebro y cerrar el portátil. Pero conviene invertir unos minutos en dejar el entorno menos frágil.

Lo recomendable es documentar:

• Qué disco es sistema y qué disco es datos.
• Qué MAC corresponde a cada interfaz.
• Qué IP interna usa el servidor.
• Qué reglas NAT existen en el router.
• Qué servicios deben estar activos.
• Qué adaptador de red funcionó como contingencia.

También es buena idea ejecutar:

lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINT,MODEL

y guardar la salida en un fichero de documentación del servidor. Una simple nota interna puede ahorrar horas en el siguiente incidente.

Lecciones aprendidas

Este tipo de recuperación enseña varias lecciones prácticas. La primera es que el fallo original no siempre es el único problema. Puede empezar con una placa averiada, seguir con Secure Boot, continuar con DHCP, pasar por una reserva MAC incorrecta y terminar en una regla NAT que apunta a otra IP.

La segunda es que hay que diferenciar entre reparar y recuperar. Reparar significa entender y corregir la causa profunda. Recuperar significa volver a dar servicio. En una caída real, primero se recupera y después se repara.

La tercera es que los routers de operador pueden hacer perder mucho tiempo. Si se han cambiado MACs, reservas DHCP o reglas de puertos, reiniciar el router puede ser una medida simple y eficaz.

La cuarta es que un adaptador USB-Ethernet puede ser una herramienta de emergencia muy valiosa. No sustituye a una red bien configurada, pero puede sacar un servidor del bloqueo cuando la NIC integrada, el router o la negociación Ethernet se comportan de forma extraña.

Y la quinta, quizá la más importante: los discos deben estar etiquetados. En una emergencia, saber qué unidad contiene el sistema y cuál contiene los datos puede marcar la diferencia entre una recuperación de una hora y una noche entera de confusión.

Conclusión: trasplantar Linux puede funcionar, pero exige método

Trasplantar una instalación Linux con servidor web a una máquina nueva puede ser una solución rápida y eficaz cuando el hardware original falla. No siempre hace falta reinstalar, restaurar copias o reconstruir toda la pila. Si el disco está sano, Linux puede arrancar en hardware diferente y conservar Nginx, MariaDB, WordPress, certificados, configuraciones y tareas programadas.

Pero el éxito depende del método. Hay que arrancar de forma incremental, resolver Secure Boot si aparece, identificar interfaces de red, actualizar reservas DHCP, revisar NAT, comprobar servicios y validar desde fuera. El mayor riesgo no es técnico, sino operativo: cambiar demasiadas cosas a la vez y no saber cuál ha roto qué.

La recuperación ideal no es la más bonita, sino la que devuelve la web al público con seguridad razonable. Después habrá tiempo para limpiar configuración, retirar adaptadores provisionales, documentar el sistema y planificar una migración más ordenada. En plena caída, el objetivo es uno: que la web vuelva a responder.

Preguntas frecuentes