Cómo migrar una web del hosting compartido a un VPS

Este artículo trata de cómo hacer la mudanza. Si merece la pena mudarse y qué servidor elegir se explica en Cuándo pasar del hosting compartido a un VPS. Aquí suponemos que el VPS ya está comprado y que la web está hecha con WordPress, Bitrix, Laravel u otro motor en PHP con base de datos MySQL. Para otras tecnologías el orden es el mismo; solo cambian los comandos.

Plazos: la mudanza en cuatro etapas

1. Dos días antes: anotar todo lo que funciona en el hosting y bajar el TTL de los registros DNS.
2. Un día antes: preparar el servidor, copiar los archivos y la base de datos y probar la web en la nueva dirección.
3. El día de la mudanza: bloquear la escritura en la web, trasladar los datos recientes y cambiar el DNS.
4. Una o dos semanas después: mantener el hosting activo como alternativa de reserva.

Qué anotar en el hosting

Casi todos los problemas tras una mudanza vienen de algo que en el hosting funcionaba solo y de lo que nadie se acordó. Recorre el panel del hosting y apunta:

• La versión de PHP y las extensiones. Se ven en el panel o por SSH con los comandos php -v y php -m. En el VPS instala la misma versión y deja la actualización de PHP para más adelante, por separado.
• La versión y el tamaño de la base de datos y la codificación de las tablas.
• Las tareas cron: qué se ejecuta y con qué frecuencia. Las rutas de los archivos en el VPS serán otras.
• Las reglas de .htaccess: redirecciones, URL amigables, restricciones de acceso a carpetas.
• El correo: buzones, reenvíos y adónde apuntan los registros MX.
• Los subdominios y todos los registros DNS, incluidos los TXT de verificación de servicios.
• Los servicios externos que conocen la IP de la web. Las pasarelas de pago, el intercambio de datos con 1C, las API de socios y los servicios de correo a menudo solo aceptan peticiones desde direcciones autorizadas. Hay que añadir allí la nueva IP de antemano.

Uno o dos días antes de la mudanza, baja el TTL de los registros A y AAAA del dominio a 300 segundos. Así, el día del cambio la nueva dirección se propagará en minutos y no en un día.

Prepara el servidor

Empieza por la protección básica: actualizaciones, acceso por clave y firewall. Todo esto está reunido en Primeros 10 pasos tras comprar un VPS: seguridad. Después hay dos caminos.

Con panel de control. ISPmanager, FASTPANEL o aaPanel instalan el servidor web, la versión de PHP necesaria y la base de datos en unos clics y ofrecen una interfaz parecida a la del hosting. Planes con ellos: VPS con ISPmanager, VPS con FASTPANEL, VPS con aaPanel.

Sin panel. En Ubuntu y Debian el conjunto mínimo se instala con un solo comando; los paquetes sin número de versión traen el PHP que viene con el sistema:

apt install nginx mariadb-server php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-zip php-intl

Si en el hosting había una versión de PHP más antigua o más nueva que la del sistema, se instala desde repositorios de terceros con paquetes de PHP para Ubuntu y Debian.

Ten en cuenta la diferencia principal con el hosting: nginx no lee .htaccess. Las redirecciones y las URL amigables hay que pasarlas a la configuración de la web. Para WordPress, la regla principal es esta: try_files $uri $uri/ /index.php?$args;. Si hay muchas reglas, es más sencillo poner Apache detrás de nginx: así funcionan la mayoría de los paneles, y .htaccess sigue funcionando.

Traslada los archivos

Si el hosting tiene acceso por SSH, lo más rápido es traer los archivos directamente desde el VPS con rsync:

rsync -avz user@old-host.example:~/public_html/ /var/www/example.com/

Si vuelves a ejecutar el mismo comando, solo copiará lo que haya cambiado; esto será útil el día de la mudanza. Si no hay SSH, hay dos opciones: crear un archivo comprimido en el gestor de archivos del panel y descargarlo al servidor con wget, o traer los archivos por FTP con la utilidad lftp:

lftp -u user old-host.example -e "mirror --parallel=4 public_html /var/www/example.com; quit"

El FTP normal transmite la contraseña en texto plano, así que si el hosting admite SFTP o FTPS, úsalos. Después de copiar, asigna los archivos al usuario del servidor web y pon los permisos habituales:

chown -R www-data:www-data /var/www/example.com
find /var/www/example.com -type d -exec chmod 755 {} +
find /var/www/example.com -type f -exec chmod 644 {} +

Traslada la base de datos

Haz un volcado en el hosting. Por SSH:

mysqldump --single-transaction --default-character-set=utf8mb4 -u user -p dbname | gzip > db.sql.gz

Sin SSH, el volcado se exporta con phpMyAdmin, aunque con bases grandes puede no terminar por el límite de tiempo del hosting; en ese caso pide el volcado al soporte o hazlo por partes. En el VPS crea la base de datos y el usuario y carga el volcado:

mysql -e "CREATE DATABASE site CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'site'@'localhost' IDENTIFIED BY 'contraseña_segura';
GRANT ALL PRIVILEGES ON site.* TO 'site'@'localhost';"
zcat db.sql.gz | mysql site

Un error frecuente al cargar es Unknown collation: 'utf8mb4_0900_ai_ci'. Significa que el volcado se hizo en MySQL 8 y en el VPS está MariaDB, que no conoce esa intercalación. O instalas en el VPS el mismo gestor de base de datos que en el hosting, o cambias en el volcado la intercalación por utf8mb4_unicode_ci.

Después escribe los nuevos datos de acceso a la base en la configuración de la web: en WordPress, wp-config.php; en Bitrix, /bitrix/.settings.php y /bitrix/php_interface/dbconn.php; en Laravel, el archivo .env. El servidor de la base de datos ahora es localhost.

Traslada las tareas cron

Ejecuta las tareas con el usuario de la web, no como root: crontab -u www-data -e. Revisa las rutas: en el hosting la web estaba en algo como /home/user/public_html, en el VPS está en /var/www/example.com, y la ruta de PHP también puede ser distinta (which php). Revisa aparte las tareas que el proveedor ejecutaba por su cuenta: los agentes de Bitrix en cron, el intercambio con 1C y el envío de correos desde la cola.

Prueba la web antes de cambiar el DNS

Los visitantes siguen yendo al hosting, pero tú puedes abrir el nuevo servidor en tu equipo. Asocia el dominio a la IP del servidor en el archivo hosts de tu ordenador (/etc/hosts en Linux y macOS, C:\Windows\System32\drivers\etc\hosts en Windows):

203.0.113.10  example.com www.example.com

Recorre la portada, el catálogo, la ficha de producto, la búsqueda, los formularios, el carrito y el acceso al panel de administración, y sube una imagen. Mientras tanto, vigila el log de errores: tail -f /var/log/nginx/error.log. Para comprobar rápido la respuesta del servidor sin navegador: curl -I --resolve example.com:80:203.0.113.10 http://example.com/.

Problemas típicos en este paso:

• 502 Bad Gateway: nginx no ve PHP-FPM; la ruta del socket en la configuración de la web no coincide con la de la configuración del pool de PHP.
• Pantalla en blanco o error 500: falta una extensión de PHP. El nombre exacto aparecerá en el log de errores.
• No se suben archivos grandes: en nginx el cuerpo de la petición está limitado por defecto a 1 MB (client_max_body_size), y en PHP, por los parámetros upload_max_filesize y post_max_size.
• Los enlaces dan 404: no se han trasladado las reglas de .htaccess.

Certificado TLS

La validación habitual del dominio para un certificado gratuito se hace por HTTP contra la dirección a la que apunta ahora el DNS, es decir, el hosting. Por eso, antes del cambio hay tres caminos:

• Obtener el certificado con validación por DNS: certbot certonly --manual --preferred-challenges dns -d example.com -d www.example.com. certbot te pedirá que añadas un registro TXT. Un certificado así no se renueva solo, así que después de la mudanza emite uno normal.
• Trasladar temporalmente el certificado actual y su clave desde el hosting, si el panel permite exportarlos.
• Cambiar el DNS y emitir el certificado enseguida con el comando certbot --nginx -d example.com -d www.example.com. Durante unos minutos la web dará error por HTTPS; para una web pequeña es aceptable.

Después de emitirlo, comprueba la renovación automática: certbot renew --dry-run.

El día de la mudanza

1. Bloquea la escritura en la web: activa el modo de mantenimiento o, al menos, deja de aceptar pedidos y comentarios. En una tienda son unos minutos.
2. Vuelve a ejecutar el mismo comando rsync: solo trasladará los cambios.
3. Haz un volcado reciente de la base de datos y cárgalo en el VPS sobre el anterior.
4. Cambia el registro A del dominio y de www a la IP del servidor. Si el dominio tiene un registro AAAA con la dirección IPv6 del hosting, sustitúyelo por la IPv6 del servidor o bórralo; si no, parte de los visitantes seguirá llegando al servidor antiguo.
5. Comprueba que los nuevos registros son visibles: dig +short example.com A @8.8.8.8 y dig +short example.com AAAA @8.8.8.8.
6. Vuelve a abrir la web a la escritura, ya en el VPS.

No pierdas el correo

Es el contratiempo más frecuente de una mudanza. Mira adónde apunta el MX: dig +short example.com MX. Si ahí aparece example.com o mail.example.com que lleva a la misma IP que la web, el cambio del registro A enviará el correo al VPS, donde no hay servidor de correo. Antes del cambio, crea para el correo un registro aparte con la IP antigua del hosting e indícalo en el MX o, mejor aún, pasa de antemano el correo del dominio a un servicio de correo aparte.

Si la web envía correos (pedidos, recuperación de contraseña), compruébalos después de la mudanza. Los correos desde una IP nueva sin registro SPF acabarán en spam: o añades la IP del servidor al SPF, o envías los correos por el SMTP de un servicio de correo. Un servidor de correo propio en un VPS es una tarea aparte; los planes para ello están en la selección VPS para un servidor de correo.

Después de la mudanza y vuelta atrás

No des de baja el hosting durante una o dos semanas. En las primeras horas revisa la base de datos antigua: si entre el volcado final y el cambio de DNS alguien llegó a hacer un pedido en el servidor antiguo, trasládalo a mano. Al cabo de un par de días echa un vistazo al log de visitas del hosting: si todavía llega gente, en algún sitio ha quedado la dirección antigua, casi siempre en el registro AAAA o en www.

Volver atrás es sencillo mientras el hosting funcione: pon de nuevo la IP antigua en el DNS y, gracias al TTL corto, los visitantes volverán al hosting en minutos. Cuando todo esté estable, devuelve el TTL a sus valores habituales y configura las copias de seguridad según Copias de seguridad de un VPS: estrategias y herramientas y la monitorización externa. Planes para webs: VPS para una web, VPS para WordPress, VPS para una tienda online, VPS para Bitrix. Para un primer montaje de prueba resulta práctico el pago por horas.