Guía completa para la migración de servidores Virtualmin: Solución de Errores Comunes y Límites

Introducción

Migración de un VPS a otro con Virtualmin Gestionar más de 10 dominios de WordPress parece sencillo en teoría: copia de seguridad en el servidor antiguo, restauración en el nuevo y listo. En realidad, es un campo minado de límites ocultos del sistema, restricciones de descriptores de archivos y problemas de espacio en disco que pueden dejarte atascado durante horas.

Recientemente completé una desafiante migración de Virtualmin desde un Debian 12 en Francia a un nuevo VPS Debian 13 en los Países Bajos, moviendo más de 4,4 GB de datos de copia de seguridad a través de más de 10 dominios. Durante este proceso, me encontré con todos los errores importantes a los que se enfrentan los administradores de Virtualmin y los resolví todos. Este artículo documenta los problemas exactos y las soluciones para que no tengas que aprenderlos por las malas.

Ya sea que esté actualizando su proveedor de VPS, escalando horizontalmente o recuperándose de un servidor fallido, esta guía lo guiará a través de los errores del mundo real y sus soluciones.

---

Parte 1: Planificación y preparación previas a la migración

Cómo elegir las especificaciones de su VPS

Antes de tocar nada en su servidor actual, asegúrese de que su nuevo VPS tiene los recursos adecuados. El error más común es suponer que el espacio en disco es lo único que importa, pero no es así.

Especificaciones mínimas para Virtualmin con más de 10 dominios:

• Espacio en disco: 100 GB (no 50 GB: los sitios de WordPress con copias de seguridad crecen rápidamente)
• CPU: 6+ núcleos (8+ núcleos recomendados para 10+ dominios)
• RAM: 8 GB como mínimo (15 GB o más para producción)
• Intercambio: 4 GB (añadidos tras la instalación del sistema operativo si no están preconfigurados)

El nuevo servidor debe tener la misma capacidad de CPU y RAM que el anterior, o incluso más, y más espacio en disco. Virtualmin hace un uso intensivo de la CPU y de la E/S durante las operaciones de restauración.

Lista de comprobación previa a la migración

En su antiguo servidor (48 horas antes de la migración):

1. Reducir el TTL de DNS a 300 segundos (5 minutos) para minimizar los problemas de caché:

virtualmin modify-dns --all-domains --ttl 300

2. Crear una nueva copia de seguridad con el formato recomendado por Virtualmin:

mkdir /backup
virtualmin backup-dominio
  --dest /backup/ \
  --Todos los dominios
  --all-features
  --nuevoformato

3. Verificar la integridad de la copia de seguridad antes de la transferencia:

tar -tzf /backup/backup_*.tar.gz > /dev/null && echo "Copia de seguridad OK" | echo "Copia de seguridad dañada"

4. Anote el tamaño de su base de datos para la planificación:

mysql -e "SELECT tabla_esquema AS 'Base de datos', ROUND(SUM(data_length+index_length)/1024/1024,2) AS 'Size_MB' FROM informacion_esquema.TABLES GROUP BY tabla_esquema;"

5. Comprobación de configuraciones personalizadas que podría no transferirse:
   • Versiones PHP personalizadas
   • Configuración de NGINX modificada
   • Cron jobs en /etc/cron.d/
   • Certificados SSL personalizados

---

Parte 2: El proceso de migración

Paso 1: Transfiera el archivo de copia de seguridad

Utilice SCP con sumas de comprobación para verificar la integridad del archivo:

# En el servidor antiguo, genere la suma de comprobación
sha256sum /backup/backup_*.tar.gz > /backup/backup.sha256

# Transfiere la copia de seguridad y la suma de comprobación
scp /backup/backup_*.tar.gz root@new-server.com:/Files/
scp /backup/backup.sha256 root@new-server.com:/Files/

# En el nuevo servidor, verifique
cd /Archivos/
sha256sum -c copia de seguridad.sha256

Si las sumas de comprobación no coinciden, parar inmediatamente. El archivo se ha dañado durante la transferencia. Vuelva a transferir o utilice rsync con sumas de comprobación:

rsync -avz --checksum /backup/backup_*.tar.gz root@new-server.com:/Files/

Paso 2: Instalar Virtualmin en el nuevo servidor

Utiliza el instalador oficial de Virtualmin:

curl https://software.virtualmin.com/gpl/scripts/virtualmin-install.sh | sh

Importante: Instale la misma versión del sistema operativo (o casi): esto importa más de lo que la gente cree. Yo migré de Debian 12 a Debian 13 (no es recomendable, pero es factible). Mantenga la misma versión principal si es posible.

Paso 3: Configuración del sistema previa a la restauración

Aquí es donde fallan la mayoría de las migraciones. Antes de tocar la restauración, corrige estos tres límites críticos:

Solución 1: Aumentar los descriptores de archivos abiertos

Esta es la #1 Causa de los errores “No queda espacio en el dispositivo” durante la restauración., incluso cuando el espacio en disco es abundante.

# Comprobar límite de corriente
ulimit -n
# Probablemente muestre 1024 (demasiado bajo para Virtualmin)

# Aumentar para la sesión actual
ulimit -n 65536

# Verificar
ulimit -n
# Debería mostrar: 65536

# Hacer permanente
cat >> /etc/seguridad/límites.conf << EOF
* soft nofile 65536
* hard nofile 65536
root soft nofile 65536
root hard nofile 65536
EOF

¿Por qué 65536? Cada archivo abierto, socket, tubería y conexión de base de datos consume un descriptor de archivo. Con más de 10 sitios WordPress, servidores de correo, trabajadores NGINX, y conexiones MySQL, usted fácilmente excede 1024. OVH y otros proveedores establecen este valor por defecto conservador para la seguridad - que está destinado a ser aumentado por aplicación.

Arreglo 2: Ampliar /tmp (tmpfs)

Durante la restauración, Virtualmin crea volcados de MySQL en /tmp/. Por defecto, /tmp es un tmpfs (disco RAM) limitado a ~50% de RAM total. Con 11GB de RAM, /tmp tiene un máximo de ~5.8GB. Pero Virtualmin puede generar fácilmente 5-6GB de archivos temporales durante la restauración.

# Comprueba el tamaño actual de /tmp
df -h /tmp

# Redimensiona dinámicamente sin desmontar
mount -o remount,size=8G /tmp

# Verificar
df -h /tmp

# Hacer permanente
echo "tmpfs /tmp tmpfs size=8G,mode=1777 0 0" >> /etc/fstab

Solución 3: Añadir espacio de intercambio

Si la restauración consume toda la RAM, el sistema deja de responder. 4GB swap proporciona un buffer de seguridad:

# Crear archivo swap de 4GB
fallocate -l 4G /archivo swap
chmod 600 /archivo swap
mkswap /archivo swap
swapon /archivo swap

# Hacer permanente
echo '/ficheroswap none swap sw 0 0' >> /etc/fstab

# Verificar
swapon --show

---

Parte 3: El proceso de restauración y los errores más comunes

Error 1: “Comprobando el contenido de la copia de seguridad ..” Se bloquea durante más de 20 minutos

Qué aspecto tiene:

Comprobación del contenido de la copia de seguridad ..

[atascado durante 15-30 minutos sin progreso]

Causa raíz: Esto no es un cuelgue, es legítimamente lento. Virtualmin tar -tzf lee todo el archivo comprimido de 4,4 GB, verifica todas las cabeceras de los archivos y comprueba la integridad del tar. En CPUs antiguas (como Haswell), esto puede llevar más de 20 minutos para una copia de seguridad de 4 GB.

Solución:

1. Que no cunda el pánico. Compruebe si el alquitrán se está ejecutando realmente:

ps aux | grep tar
iostat -x 1 # Comprobar la actividad del disco

2. Utilizar la restauración CLI en lugar de la interfaz web (evita el tiempo de espera de verificación):

pantalla -S restore
virtualmin restore-domain \
  --source /Archivos/backup_*.tar.gz \
  --all-domains
  --all-features
  --reuid

En --reuid ajusta automáticamente los identificadores de usuario/grupo, algo fundamental cuando se realizan restauraciones en distintos sistemas.

Error 2: “/bin/tar: No se puede escribir: No queda espacio en el dispositivo”

Qué aspecto tiene:

/bin/tar: ./seo.grahammiranda.com_mail_users: No se puede escribir: No queda espacio en el dispositivo
/bin/tar: ./esim.grahammiranda.com_virtualmin_ssl_key: No se puede escribir: No queda espacio en el dispositivo

[docenas más de estos errores]

/bin/tar: Exiting with failure status due to previous errors

La parte confusa: Tienes 75 GB libres, pero dice “No queda espacio en el dispositivo”.”

Causas fundamentales (por orden de probabilidad):

1. Límite de descriptores de archivos alcanzado (más común)
   • Síntoma: Los errores aparecen a los 5-10 minutos de la restauración, no al principio.
   • Arréglalo: ulimit -n 65536 (cubierto arriba)
2. /tmp se llena (segundo más común)
   • Síntoma: Los errores mencionan MySQL o archivos temporales
   • Compruébalo: df -h /tmp durante el restablecimiento-ver como se llena a 100%
   • Arréglalo: mount -o remount,size=8G /tmp (cubierto arriba)
3. Se agota el espacio real en disco (menos común pero posible)
   • Compruébalo: df -h / muestra <5GB libres
   • Solución:

# Limpiar restauración fallida
rm -rf /home/*
rm -rf /var/lib/virtualmin/*
rm -rf /tmp/*
rm -rf /extract_test/

# Si la copia de seguridad está todavía en /Archivos, considere moverla
mv /Archivos/backup_*.tar.gz /mnt/ # Muévela a otra partición si está disponible

4. Agotamiento del nodo (poco frecuente)
   • Compruébalo: df -i / espectáculos >90% iUsed
   • Causa: Sistema de ficheros creado con muy pocos inodos
   • Solución: Reformatear el sistema de archivos con más inodos (destructivo)

Enfoque diagnóstico durante la restauración:

Abra un segundo terminal y controle en tiempo real:

watch -n 2 'df -h / && echo "---" && df -h /tmp && echo "---" && du -sh /tmp/* 2>/dev/null | sort -rh | head -5'

Esto muestra exactamente cuándo y dónde llegaste al límite.

Error 3: NGINX no arranca tras la restauración

Mensaje de error:

nginx[34392]: [emerg] 34392#34392: open() "/etc/nginx/snippets/block-manager.conf" failed (2: No such file or directory)
nginx: archivo de configuración /etc/nginx/nginx.conf prueba falló

Causa raíz: La restauración ha fallado parcialmente o algunos archivos no se han transferido correctamente. Las configuraciones de NGINX hacen referencia a archivos que no existen.

Solución:

1. Crea el archivo que falta:

mkdir -p /etc/nginx/snippets
toque /etc/nginx/snippets/block-manager.conf

2. Pruebe la configuración de NGINX:

nginx -t

3. Inicie NGINX:

systemctl start nginx
systemctl status nginx

Si el archivo necesita contenido real, compruebe su antiguo servidor:

scp old-server.com:/etc/nginx/snippets/block-manager.conf /etc/nginx/snippets/

---

Parte 4: Soluciones avanzadas y optimización

Restauración de un dominio cada vez (método más seguro)

Si la restauración completa sigue fallando a pesar de las correcciones, restaure selectivamente:

# Limpiar intentos fallidos anteriores
rm -rf /home/*
rm -rf /var/lib/virtualmin/*

# Restaura primero sólo el dominio principal
virtualmin restore-domain \
  --source /Archivos/backup_*.tar.gz \
  --domain grahammiranda.com \
  --all-features
  --reuid

Esto aísla los dominios que tienen problemas. Si uno se restaura correctamente, el patrón funciona para los demás.

Consideraciones sobre la migración de Debian 12 a Debian 13

He migrado de Debian 12 a Debian 13. Aunque en general es compatible, tenga cuidado con:

1. Diferencias de versión de PHP: Debian 12 podría tener PHP 8.1, Debian 13 tiene 8.3
   • Compruébalo: php -v en ambos servidores
   • Asunto: Raros problemas de compatibilidad con extensiones PHP antiguas
   • Arréglalo: Forzar versión antigua de PHP: virtualmin modify-web --dominio ejemplo.com --php-version 8.1
2. Sintaxis de configuración de NGINX/Apache: Suele ser compatible, pero compruébalo tras la restauración
   • Prueba: nginx -t y apache2ctl configtest
3. Compatibilidad MySQL/MariaDB: Generalmente compatible con el futuro
   • Compruébalo: mysql --versión en ambos servidores
   • Diferencias en el formato de los volcados: Raro, pero las nuevas Debian podrían tener modos SQL más estrictos
4. Compatibilidad con certificados SSL: No hay problemas entre versiones de Debian, pero verifíquelo:

certbot certificados # Comprobar Let's Encrypt certificados

---

Parte 5: Verificación posterior a la migración

Comprobaciones críticas antes de la puesta en marcha

Una vez finalizada la restauración, compruebe que todo funciona:

# 1. Listar todos los dominios restaurados
virtualmin list-domains

# 2. Pruebe la conectividad web
curl -I https://yourdomain.com

# 3. Compruebe la funcionalidad del correo
mysql -u root -p'contraseña' -e "SELECT usuario FROM mysql.usuario;"

# 4. Verificar DNS
dig sudominio.com @localhost

# 5. Compruebe el módulo Virtualmin
virtualmin prueba-dominio --dominio sudominio.com

# 6. Supervise los registros en busca de errores
journalctl -f
tail -f /var/log/nginx/error.log

Actualizar registros DNS

Una vez que todos los dominios se restauren correctamente:

1. Actualizar los servidores de nombres del registrador para apuntar al nuevo servidor
2. Monitor TTL cuenta atrás (debería ser de 5 minutos con TTL reducido)
3. Prueba desde varios lugares:

nslookup sudominio.com
dig sudominio.com +corto

4. Devuelve el TTL de DNS a la normalidad después de 24-48 horas:

virtualmin modify-dns --all-domains --ttl 3600

---

Parte 6: Referencia de los límites del sistema

Para futuras referencias, aquí están todos los límites del sistema comprobados durante esta migración:

# Límites de usuario/proceso
ulimit -a # Todos los límites
ulimit -n # Archivos abiertos
ulimit -u # Procesos máximos
ulimit -v # Memoria virtual

# Límites de todo el sistema
cat /proc/sys/fs/file-max # Ficheros abiertos en todo el sistema
cat /proc/sys/kernel/pid_max # Número máximo de ID de proceso
cat /proc/sys/vm/max_map_count # Límite de mapas de memoria

# Uso actual de recursos
df -h # Espacio en disco
df -i # Uso de inodos
free -h # RAM y swap
ps aux | wc -l # Procesos en ejecución
lsof | wc -l # Descriptores de archivo abiertos

# Específicos del sistema de archivos
mount | grep /dev/sda1 # Opciones de montaje
quota -s # Cuotas de disco
tune2fs -l /dev/sda1 # Propiedades del sistema de archivos

---

Principales conclusiones

1. OVH (y la mayoría de los proveedores) establecen valores por defecto conservadores. Debe aumentar los límites de los descriptores de archivo antes de restaurar las copias de seguridad de Virtualmin.
2. Los límites del sistema son el verdadero enemigo, no el espacio en disco. Incluso con 75 GB gratuitos, aparecerá el mensaje “No queda espacio en el dispositivo” si /tmp está lleno o se han agotado los descriptores de archivo.
3. Aumentar /tmp antes de la restauración. Virtualmin crea 5-6GB de archivos temporales durante la restauración de la copia de seguridad. La asignación por defecto de tmpfs no es suficiente.
4. Utilice la restauración CLI, no la interfaz web. La interfaz web tiene problemas de tiempo de espera en copias de seguridad grandes. La restauración por línea de comandos es más fiable y muestra el progreso real.
5. La migración de Debian 12 a Debian 13 funciona, pero la misma versión es más segura. Las diferencias menores de versión rara vez causan problemas, pero manténgase dentro de la misma versión principal si es posible.
6. Verifique la integridad de la copia de seguridad antes de transferirla. Utilice sumas de comprobación SHA256 para asegurarse de que el archivo de copia de seguridad no se corrompió durante la transferencia.
7. La planificación previa a la migración ahorra horas. Reducir el TTL de DNS, comprobar el tamaño de las bases de datos y preparar el servidor de destino evita la mayoría de los problemas.

---

Conclusión

La migración de Virtualmin no es difícil, sólo es complicada. La mayoría de los fallos no se deben a Virtualmin en sí, sino a los límites ocultos del sistema establecidos por los proveedores de alojamiento. Comprendiendo estas limitaciones y aplicando las correcciones documentadas aquí, puedes migrar más de 10 sitios WordPress entre servidores de forma fiable.

Los errores específicos que encontré (límites del descriptor de archivo, /tmp agotamiento, falta de fragmentos de NGINX) son reproducibles y comunes. Si se encuentra con alguno de ellos, vuelva a esta guía y encontrará la solución exacta.

Buena suerte con la migración. Que sus copias de seguridad se restauren rápidamente y que sus dominios estén en línea sin problemas.

---

Biografía del autor

Esta guía documenta una migración real de Virtualmin completada en febrero de 2026, migrando más de 10 dominios de producción de un VPS Debian 12 (Francia) a un VPS Debian 13 (Países Bajos). Las soluciones han sido probadas y verificadas sobre el terreno.