Abaixo está um planejamento completo de migração de VPS para servidor dedicado, focado em reduzir risco, downtime e surpresas. Migração de VPS para servidor dedicado.

Planejamento de Migração de VPS para Servidor Dedicado

1️⃣ Justificativa técnica da migração (não pule isso)

Antes de qualquer comando:

Sinais claros de que a VPS virou gargalo

• CPU steal alto (%st no top)
• IO inconsistente mesmo com disco “rápido”
• Latência imprevisível em horários de pico
• Hypervisor impactando performance
• Crescimento que exige previsibilidade

Validação

top
vmstat 1
iostat -x 1

Se o problema não é configuração, e sim limite estrutural, o dedicado faz sentido.

2️⃣ Inventário completo da VPS (estado atual)

Nada de migrar “no escuro”.

Sistema

uname -a
cat /etc/os-release
uptime
timedatectl

Recursos

lscpu
free -h
lsblk
df -h
df -i

Serviços críticos

systemctl list-units --type=service --state=running
ss -tulpen
crontab -l
ls /etc/cron.*

Stack web (exemplo típico seu cenário)

• Apache / Nginx (proxy reverso)
• PHP-FPM (pools)
• MariaDB 11.x
• Redis / Memcached
• Certbot
• Firewall (nftables / firewalld)

📌 Documente tudo — isso vira checklist de validação depois.

3️⃣ Planejamento do servidor dedicado

Hardware (regra prática)

• CPU: menos cores, mais clock
• RAM: sobra ≥ 30%
• Disco:
  • NVMe preferencial
  • RAID 1 ou RAID 10
• Rede: porta dedicada + SLA

SO

• Mesmo SO da VPS (AlmaLinux, Rocky, Debian, etc)
• Mesma versão → menos surpresas

4️⃣ Provisionamento do dedicado (ANTES da migração)

Hardening inicial

dnf update -y
timedatectl set-timezone America/Sao_Paulo

Kernel e limites

sysctl -a | egrep 'vm.swappiness|fs.file-max'
ulimit -n

Firewall mínimo funcional

nft list ruleset

⚠️ Não migre dados sem o firewall ativo.

5️⃣ Replicar a stack (sem dados ainda)

Instale exatamente o que existe hoje:

• Web server
• PHP + extensões
• Banco
• Cache
• Certbot
• Ferramentas auxiliares (rsync, htop, iotop…)

Valide:

php -v
nginx -t
apachectl -t
mysql --version

6️⃣ Migração de dados (estratégia correta)

Arquivos (WordPress, apps, etc)

rsync -avz --numeric-ids \
--exclude=/proc \
--exclude=/sys \
--exclude=/dev \
/var/www/ novo_servidor:/var/www/

Faça mais de um rsync (pré-sync + sync final).

Banco de dados (sem gambiarra)

mysqldump --single-transaction --routines --events \
--databases db1 db2 > dump.sql

No dedicado:

mysql < dump.sql

📌 Se banco for grande → considere replicação temporária.

7️⃣ Ajustes pós-migração (onde muitos erram)

MariaDB

• Recalcular buffers (innodb_buffer_pool_size)
• Ajustar IO para NVMe
• Remover tuning feito “pra VPS fraca”

PHP-FPM

• Recalcular pm.max_children
• Ajustar request_terminate_timeout
• Separar pools se necessário

Nginx / Apache

• Worker/processes conforme CPU real
• Timeouts coerentes

8️⃣ Testes antes do corte

Testes locais (hosts)

echo "IP_DEDICADO dominio.com" >> /etc/hosts

Valide:

• Login admin
• Checkout
• Upload
• Cron
• Cache
• SSL

Carga leve

ab -n 1000 -c 50 https://dominio.com/

9️⃣ Plano de corte (downtime mínimo)

1. Baixar TTL do DNS (antes!)
2. Último rsync
3. Último dump do banco
4. Atualizar DNS
5. Monitorar logs em tempo real

tail -f /var/log/nginx/access.log
tail -f /var/log/mysql/mysqld.log

🔟 Rollback (obrigatório)

Se algo der errado:

• VPS continua intacta
• TTL baixo permite voltar rápido
• Nunca desligue a VPS no mesmo dia

Checklist rápido (resumo)

• Inventário completo da VPS
• Stack idêntica no dedicado
• Firewall ativo
• Pré-sync de dados
• Dump consistente do banco
• Testes via hosts
• Plano de rollback definido
• Monitoramento pós-corte

FAQ