Migración

TNS Panel migra de servidor a servidor. Se instala en un servidor nuevo y limpio y se importa desde el panel anterior, que sigue atendiendo a los clientes mientras tanto. Cada cuenta se verifica en el servidor nuevo y el corte se realiza con un cambio de DNS. Si algo sale mal, se apunta el DNS nuevamente al servidor anterior, donde no se modificó nada.

La migración está en Migración en la interfaz de administración y en los comandos panel migra-*. Es una función exclusiva del administrador.

Modos de migración

Paneles de origen con lector dedicado: CWP / CWP Pro, cPanel / WHM, Plesk, DirectAdmin, HestiaCP, CyberPanel y aaPanel (CyberPanel y aaPanel sólo por SSH). Para cualquier otro panel por SSH existe un lector genérico que reconstruye las cuentas a partir del propio sistema. Los paneles cerrados, como Ferozo, se migran con el modo de cuenta única.

1. Inspeccionar sin modificar nada

panel migra-inventario -host viejo.example.com -panel cwp -usuario root

El comando lee el servidor anterior y lista cuentas, sitios, bases de datos, casillas, alias y cuentas FTP. No escribe nada, ni allá ni acá. El primer contacto no acepta la clave del servidor sin verificarla: muestra su huella SSH y se niega a continuar hasta que se repita el comando con -huella SHA256:..., luego de compararla con la real (en el servidor anterior: ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub). No existe forma de omitir esta comprobación.

Todo lo leído del servidor anterior se trata como entrada no confiable. El inventario informa también lo que no pudo leer, de modo que un cero nunca se presente como «no tiene». Por SSH no se copian hashes de contraseñas: las casillas y cuentas FTP se recrean y sus titulares fijan contraseñas nuevas. Los hashes sólo viajan en archivos de backup.

2. Importar una cuenta

# desde el servidor anterior
panel migra-cuenta -host viejo.example.com -panel cwp -cuenta acme [-renombrar acme2]

# desde un archivo de backup (fuera de /tmp, por ejemplo /root/backups/)
panel migra-archivo -archivo /root/backups/acme.tar.gz

Se crean el cliente, su plan y revendedor cuando el panel de origen los declara, los sitios y alias, se copia el home, se crean las bases y sus usuarios y se cargan los volcados cuando el backup los trae (archivos de cPanel y CWP Pro; en los demás, el contenido de las bases debe cargarse por otro medio). Los volcados se importan con una identidad temporal limitada, nunca con derechos administrativos, porque un volcado importado es SQL arbitrario. Si un intento previo se interrumpió, se agrega -continuar; con -sin-archivos se arma sólo la estructura.

Correo. Antes de crear cualquier dominio de correo, el panel consulta al DNS real dónde vive el correo de ese dominio. Si el MX apunta fuera de este servidor (Google Workspace, Microsoft 365 u otro proveedor), no se crean casillas locales: hacerlo haría que este nodo tratara el dominio como local y entregara en casillas vacías el correo de otros clientes que debía salir hacia afuera. El informe indica el MX real y cuántas casillas quedaron sin crear. Si la respuesta no puede determinarse, se la considera «no segura». Los mensajes existentes se copian por IMAP desde Correo (también en una segunda pasada justo antes del corte, que sólo trae lo llegado desde la primera); la casilla de destino debe ser nueva y estar vacía.

3. Verificar antes de cortar el DNS

panel migra-verificar -host viejo.example.com -panel cwp -cuenta acme -destino acme

o Migración → Verificar. Es de sólo lectura en ambos lados. Para cada cuenta comprueba, contra el inventario original:

• que cada sitio responda en este nodo (se solicita la página con el encabezado Host correcto, porque el DNS todavía apunta al servidor anterior);
• que cada base de datos exista y tenga la misma cantidad de tablas (un volcado cargado a medias tiene el nombre correcto pero tablas de menos);
• que las casillas y alias estén presentes.

Cada elemento tiene tres resultados posibles: correcto, falta o no se pudo verificar (por ejemplo, por tiempo agotado). Un problema de red nunca se informa como «falta» ni como «correcto». También se listan los elementos que existen acá y no en el origen.

Migración → Descubrir muestra dónde vive realmente el DNS de un dominio (servidores de nombres y quién los opera, MX, SPF/DMARC y, cuando está disponible, el registrador), consultado a un resolvedor público y no a este nodo, para decidir si conviene mover la zona o sólo cambiar registros en otro lado.

4. Cortar

1. Completar la última pasada de IMAP y volver a sincronizar las bases escritas desde la copia.
2. Cambiar los servidores de nombres en el registrador (o los registros A/MX si el DNS está en otro lado).
3. Mantener el servidor anterior encendido hasta que el tráfico se haya movido.
4. Para volver atrás, se apunta nuevamente el DNS al servidor anterior.

Después de migrar, deben revisarse los certificados (el dominio tiene que apuntar primero a este nodo) y la lista de pendientes del informe: contraseñas a restablecer, bases sin volcado y nombres modificados. Esa lista es la parte que debe leerse antes de cortar el DNS.

Migración desde una cuenta, sin acceso al servidor

Migración → Cuenta incorpora a un cliente usando sólo lo que el propio cliente puede entregar: sus credenciales FTP/SFTP para los archivos, un acceso IMAP por casilla, el DNS leído del DNS real y su exportación .sql. El informe aclara que no hay datos de plan, revendedor ni cuotas, porque no hay servidor de donde leerlos.

Importar la configuración de CSF

Seguridad → Firewall → Importar CSF lee csf.conf y las listas de permitidos y denegados, de modo que el ajuste acumulado del firewall anterior no se pierda.

Servicio de migración

La migración también se ofrece como servicio pago, ejecutado por el equipo del proveedor: USD 20 por servidor, sin límite de cuentas. Los precios vigentes figuran en Precios.