Guia completo de migração do Virtualmin: erros e limites

Introdução

Migrar de um VPS para outro com Virtualmin 10+ domínios WordPress rodando parece simples na teoria—backup no servidor antigo, restauração no novo, pronto. Na realidade, é um campo minado de limites ocultos do sistema, restrições de descritores de arquivos e problemas de espaço em disco que podem deixar você travado por horas.

Concluí recentemente uma migração desafiadora do Virtualmin de um VPS Debian 12 na França para um VPS novo com Debian 13 nos Países Baixos, movendo mais de 4,4 GB de dados de backup entre 10+ domínios. Durante o processo, encontrei todos os principais erros que administradores do Virtualmin enfrentam—e resolvi todos. Este artigo documenta os problemas e as soluções exatos para que você não precise aprendê-los da forma difícil.

Se você está trocando de provedor de VPS, escalando horizontalmente ou se recuperando de um servidor com falha, este guia mostra erros do mundo real e como corrigi-los.

---

Parte 1: planejamento e preparação antes da migração

Como escolher as especificações do VPS de destino

Antes de mexer em qualquer coisa no servidor atual, garanta que o novo VPS tenha recursos adequados. O erro comum é achar que só o espaço em disco importa—não importa.

Especificações mínimas para o Virtualmin com 10+ domínios:

• Espaço em disco: 100 GB (não 50 GB—sites WordPress com backups crescem rápido)
• CPU: 6+ núcleos (8+ núcleos recomendados para 10+ domínios)
• RAM: 8 GB no mínimo (15 GB+ para produção)
• Swap: 4 GB (adicionados após a instalação do sistema operacional, se não estiver pré-configurado)

O novo servidor deve ter CPU e RAM iguais ou superiores às do servidor antigo, com mais espaço em disco. O Virtualmin usa muita CPU e I/O durante a restauração—um processador fraco vai deixar a restauração lenta.

Lista de verificação antes da migração

No servidor antigo (48 horas antes da migração):

1. Reduza o TTL do DNS para 300 segundos (5 minutos) para minimizar problemas de cache:

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

2. Crie um backup novo com o formato recomendado pelo Virtualmin:

mkdir /backup
virtualmin backup-domain \
  --dest /backup/ \
  --all-domains \
  --all-features \
  --newformat

3. Verifique a integridade do backup antes de transferir:

tar -tzf /backup/backup_*.tar.gz > /dev/null && echo "Backup OK" || echo "Backup corrupted"

4. Anote o tamanho dos bancos de dados para planejamento:

mysql -e "SELECT table_schema AS 'Database', ROUND(SUM(data_length+index_length)/1024/1024,2) AS 'Size_MB' FROM information_schema.TABLES GROUP BY table_schema;"

5. Verifique configurações personalizadas que podem não ser transferidas:
   • Versões personalizadas do PHP
   • Configurações modificadas do NGINX
   • Tarefas cron em /etc/cron.d/
   • Certificados SSL personalizados

---

Parte 2: o processo de migração

Passo 1: transferir o arquivo de backup

Uso SCP com checksums para verificar a integridade dos arquivos:

# On old server, generate checksum
sha256sum /backup/backup_*.tar.gz > /backup/backup.sha256

# Transfer backup and checksum
scp /backup/backup_*.tar.gz [email protected]:/Files/
scp /backup/backup.sha256 [email protected]:/Files/

# On new server, verify
cd /Files/
sha256sum -c backup.sha256

Se os checksums não coincidirem, pare imediatamente. O arquivo foi corrompido durante a transferência. Transfira novamente ou use rsync com checksums:

rsync -avz --checksum /backup/backup_*.tar.gz [email protected]:/Files/

Passo 2: instalar o Virtualmin no novo servidor

Use o instalador oficial do Virtualmin:

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

Importante: Instale a mesma versão do sistema operacional (ou uma próxima)—isso importa mais do que as pessoas pensam. Eu migrei do Debian 12 para o Debian 13 (não é recomendado, mas funciona). Se possível, fique na mesma versão principal.

Passo 3: configuração do sistema antes da restauração

É aqui que a maioria das migrações falha. Antes de mexer na restauração, ajuste estes três limites críticos:

Correção 1: aumentar os descritores de arquivos abertos

Esta é a causa nº 1 dos erros “No space left on device” durante a restauração, mesmo quando há bastante espaço em disco.

# Check current limit
ulimit -n
# Likely shows: 1024 (too low for Virtualmin)

# Increase for current session
ulimit -n 65536

# Verify
ulimit -n
# Should show: 65536

# Make permanent
cat >> /etc/security/limits.conf << EOF
* soft nofile 65536
* hard nofile 65536
root soft nofile 65536
root hard nofile 65536
EOF

Por que 65536? Cada arquivo aberto, socket, pipe e conexão de banco de dados consome um descritor de arquivo. Com 10+ sites WordPress, servidores de e-mail, workers do NGINX e conexões MySQL, você passa de 1024 com facilidade. A OVH e outros provedores definem esse padrão conservador por segurança—ele deve ser aumentado por aplicação.

Correção 2: aumentar /tmp (tmpfs)

Durante a restauração, o Virtualmin cria dumps do MySQL em /tmp/. Por padrão, /tmp é um tmpfs (disco em RAM) limitado a ~50% da RAM total. Com 11 GB de RAM, /tmp chega no máximo a ~5,8 GB. Mas o Virtualmin pode facilmente gerar 5-6 GB de arquivos temporários durante a restauração.

# Check current /tmp size
df -h /tmp

# Dynamically resize without unmounting
mount -o remount,size=8G /tmp

# Verify
df -h /tmp

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

Correção 3: adicionar espaço de swap

Se a restauração consumir toda a RAM, o sistema fica sem responder. 4 GB de swap fornecem uma margem de segurança:

# Create 4GB swap file
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# Make permanent
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# Verify
swapon --show

---

Parte 3: o processo de restauração e erros comuns

Erro 1: “Checking contents of the backup ..” trava por mais de 20 minutos

Como isso aparece:

Verificando o conteúdo do backup ..

[travado por 15-30 minutos sem progresso]

Causa raiz: Isso não é um travamento—é lentidão de verdade. O tar -tzf do Virtualmin lê o arquivo compactado inteiro de 4,4 GB, verifica cada cabeçalho de arquivo e checa a integridade do tar. Em CPUs mais antigas (como Haswell), isso pode levar 20+ minutos para um backup de 4 GB.

Solução:

1. Não entre em pânico. Verifique se o tar está realmente em execução:

ps aux | grep tar
iostat -x 1  # Check disk activity

2. Use a restauração pela CLI em vez da interface web (ignora o tempo limite de verificação):

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

O --reuid faz com que os IDs de usuário/grupo sejam ajustados automaticamente—essencial ao restaurar entre sistemas diferentes.

Erro 2: “/bin/tar: Cannot write: No space left on device”

Como isso aparece:

/bin/tar: ./seo.grahammiranda.com_mail_users: Cannot write: No space left on device
/bin/tar: ./esim.grahammiranda.com_virtualmin_ssl_key: Cannot write: No space left on device

[dezenas de outros erros como esses]

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

A parte confusa: Você tem 75 GB livres, mas a mensagem diz “No space left on device.”

Causas raiz (em ordem de probabilidade):

1. Limite de descritores de arquivos atingido (mais comum)
   • Sintoma: Os erros aparecem 5-10 minutos após o início da restauração, não no começo
   • Correção: ulimit -n 65536 (abordado acima)
2. /tmp fica cheio (segunda causa mais comum)
   • Sintoma: Os erros mencionam MySQL ou arquivos temporários
   • Verifique: df -h /tmp durante a restauração—observe ele chegar a 100%
   • Correção: mount -o remount,size=8G /tmp (abordado acima)
3. O espaço em disco de verdade acaba (menos comum, mas possível)
   • Verifique: df -h / mostra <5 GB livres
   • Solução:

# Clean up failed restore
rm -rf /home/*
rm -rf /var/lib/virtualmin/*
rm -rf /tmp/*
rm -rf /extract_test/

# If backup is still in /Files, consider moving it
mv /Files/backup_*.tar.gz /mnt/  # Move to another partition if available

4. Esgotamento de inodes (raro)
   • Verifique: df -i / mostra >90% de iUsed
   • Causa: Sistema de arquivos criado com poucos inodes
   • Solução: Reformatar o sistema de arquivos com mais inodes (destrutivo)

Abordagem de diagnóstico durante a restauração:

Abra um segundo terminal e monitore em tempo real:

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

Isso mostra exatamente quando e onde você atingiu o limite.

Erro 3: o NGINX não inicia após a restauração

Mensagem de erro:

nginx[34392]: [emerg] 34392#34392: open() "/etc/nginx/snippets/block-manager.conf" failed (2: No such file or directory)
nginx: configuration file /etc/nginx/nginx.conf test failed

Causa raiz: A restauração falhou parcialmente, ou alguns arquivos não foram transferidos corretamente. As configurações do NGINX fazem referência a arquivos que não existem.

Solução:

1. Crie o arquivo que falta:

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

2. Teste a configuração do NGINX:

nginx -t

3. Inicie o NGINX:

systemctl start nginx
systemctl status nginx

Se o arquivo precisar de conteúdo de verdade, verifique o servidor antigo:

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

---

Parte 4: soluções avançadas e otimização

Restaurar um domínio por vez (abordagem mais segura)

Se a restauração completa continuar falhando apesar das correções, restaure de forma seletiva:

# Clean previous failed attempts
rm -rf /home/*
rm -rf /var/lib/virtualmin/*

# Restore just the main domain first
virtualmin restore-domain \
  --source /Files/backup_*.tar.gz \
  --domain grahammiranda.com \
  --all-features \
  --reuid

Isso isola quais domínios têm problemas. Se um for restaurado com sucesso, o padrão funciona para os outros.

Considerações sobre a migração do Debian 12 para o Debian 13

Eu migrei do Debian 12 para o Debian 13. Embora sejam geralmente compatíveis, fique atento a:

1. Diferenças de versão do PHP: O Debian 12 pode ter PHP 8.1, o Debian 13 tem 8.3
   • Verifique: php -v nos dois servidores
   • Problema: Problemas raros de compatibilidade com extensões PHP antigas
   • Correção: Force a versão antiga do PHP: virtualmin modify-web --domain example.com --php-version 8.1
2. Sintaxe de configuração do NGINX/Apache: Geralmente compatível, mas teste após a restauração
   • Teste: nginx -t e apache2ctl configtest
3. Compatibilidade com MySQL/MariaDB: Geralmente compatível com versões futuras
   • Verifique: mysql --version nos dois servidores
   • Diferenças no formato do dump: Raro, mas o Debian mais novo pode ter modos SQL mais rígidos
4. Compatibilidade de certificados SSL: Sem problemas entre versões do Debian, mas verifique:

certbot certificates  # Check Let's Encrypt certs

---

Parte 5: verificação após a migração

Verificações críticas antes de entrar no ar

Depois que a restauração terminar, verifique se tudo funciona:

# 1. List all restored domains
virtualmin list-domains

# 2. Test web connectivity
curl -I https://yourdomain.com

# 3. Check mail functionality
mysql -u root -p'password' -e "SELECT user FROM mysql.user;"

# 4. Verify DNS
dig yourdomain.com @localhost

# 5. Check Virtualmin module
virtualmin test-domain --domain yourdomain.com

# 6. Monitor logs for errors
journalctl -f
tail -f /var/log/nginx/error.log

Atualizar os registros DNS

Depois que todos os domínios forem restaurados com sucesso:

1. Atualize os nameservers no registrador para apontar para o novo servidor
2. Monitore a contagem regressiva do TTL (deve ser 5 minutos com o TTL reduzido)
3. Teste de vários locais:

nslookup yourdomain.com
dig yourdomain.com +short

4. Volte o TTL do DNS ao normal após 24-48 horas:

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

---

Parte 6: referência de limites do sistema

Para referência futura, veja todos os limites do sistema verificados durante esta migração:

# User/process limits
ulimit -a                              # All limits
ulimit -n                              # Open files
ulimit -u                              # Max processes
ulimit -v                              # Virtual memory

# System-wide limits
cat /proc/sys/fs/file-max              # System-wide open files
cat /proc/sys/kernel/pid_max           # Max process IDs
cat /proc/sys/vm/max_map_count         # Memory map limit

# Current resource usage
df -h                                  # Disk space
df -i                                  # Inode usage
free -h                                # RAM and swap
ps aux | wc -l                         # Running processes
lsof | wc -l                           # Open file descriptors

# Filesystem specifics
mount | grep /dev/sda1                 # Mount options
quota -s                               # Disk quotas
tune2fs -l /dev/sda1                   # Filesystem properties

---

Principais lições

1. OVH (e a maioria dos provedores) define padrões conservadores. Você precisa aumentar os limites de descritores de arquivos antes de restaurar backups do Virtualmin.
2. Os limites do sistema são o verdadeiro inimigo, não o espaço em disco. Mesmo com 75 GB livres, você verá “No space left on device” se /tmp estiver cheio ou os descritores de arquivos estiverem esgotados.
3. Aumente /tmp o tamanho antes da restauração. O Virtualmin cria 5-6 GB de arquivos temporários durante a restauração do backup. A alocação padrão de tmpfs não é suficiente.
4. Use a restauração pela CLI, não a interface web. A interface web tem problemas de tempo limite com backups grandes. A restauração pela linha de comando é mais confiável e mostra o progresso real.
5. A migração do Debian 12 para o Debian 13 funciona, mas usar a mesma versão é mais seguro. Diferenças de versão secundária raramente causam problemas, mas fique na mesma versão principal se possível.
6. Verifique a integridade do backup antes de transferir. Use checksums SHA256 para garantir que o arquivo de backup não se corrompeu durante a transferência.
7. O planejamento antes da migração economiza horas. Reduzir o TTL do DNS, verificar o tamanho dos bancos de dados e preparar o servidor de destino evita a maioria dos problemas.

---

Conclusão

Migrar o Virtualmin não é difícil — é só chato. A maioria das falhas não vem do Virtualmin em si, mas de limites ocultos do sistema definidos pelos provedores de hospedagem. Entendendo essas restrições e aplicando as correções documentadas aqui, você consegue migrar mais de 10 sites WordPress entre servidores com confiabilidade.

Os erros específicos que encontrei (limites de descritores de arquivo, /tmp esgotamento, snippets do NGINX ausentes) são reprodutíveis e comuns. Se você esbarrar em algum deles, volte a este guia — vai encontrar a solução exata.

Boa sorte com a sua migração. Que seus backups restaurem rápido e seus domínios entrem no ar sem drama.

---

Sobre o autor

Este guia documenta uma migração real de Virtualmin concluída em fevereiro de 2026, movendo mais de 10 domínios de produção de um VPS Debian 12 (França) para um VPS Debian 13 (Países Baixos). As soluções foram testadas na prática e verificadas em campo.