Migrar site do cPanel para VPS Debian 12 sem downtime

Migrar site do cPanel para VPS Debian 12 é o processo de transferir arquivos, banco de dados, configurações de domínio e certificados SSL de um ambiente gerenciado pelo cPanel para um servidor VPS com Debian 12 configurado manualmente, sem interromper o acesso dos visitantes. Para executar a migração sem downtime, siga estes passos:

1. Reduza o TTL do DNS para 300 segundos com antecedência de 24 horas.
2. Prepare o VPS Debian 12 com Nginx, PHP-FPM e MariaDB.
3. Exporte os arquivos do cPanel via rsync e o banco de dados com mysqldump.
4. Importe os dados no VPS e valide o funcionamento pelo arquivo hosts.
5. Emita o certificado SSL com Certbot no novo servidor.
6. Altere o registro A do DNS e monitore a propagação.

Pré-requisitos para migrar do cPanel para VPS Debian 12

• Acesso SSH root ao VPS de destino com Debian 12 instalado.
• Acesso ao cPanel da hospedagem de origem (usuário e senha ou chave SSH).
• Acesso ao painel de DNS do domínio (Cloudflare, registro.br ou painel da registradora).
• Debian 12 (Bookworm) com pelo menos 1 vCPU, 1 GB de RAM e 20 GB de disco.
• Nginx 1.22+ ou Apache 2.4+, PHP-FPM 8.2/8.3 e MariaDB 10.11 ou MySQL 8.0.
• Certbot instalado no VPS de destino para emissão do SSL Let's Encrypt.
• rsync e scp disponíveis em ambos os servidores.
• TTL do DNS reduzido para 300 segundos pelo menos 24 horas antes da virada.

Migrar site do cPanel para VPS Debian 12: preparação do ambiente

Antes de transferir qualquer arquivo, o ambiente de destino precisa estar funcional. Instale e configure Nginx, PHP-FPM e MariaDB no Debian 12 para replicar o stack do cPanel.

Atualize o sistema e instale os pacotes essenciais:

apt update && apt upgrade -y
apt install -y nginx php8.2-fpm php8.2-mysql php8.2-xml php8.2-mbstring \
  php8.2-curl php8.2-zip php8.2-gd mariadb-server rsync certbot \
  python3-certbot-nginx unzip curl

Inicie e habilite os serviços:

systemctl enable --now nginx php8.2-fpm mariadb

Execute o assistente de segurança do MariaDB:

mysql_secure_installation

Crie o banco de dados e o usuário que receberão os dados migrados:

mysql -u root -p
CREATE DATABASE meusite_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'meusite_user'@'localhost' IDENTIFIED BY 'SenhaForte123!';
GRANT ALL PRIVILEGES ON meusite_db.* TO 'meusite_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Crie o diretório raiz do site e ajuste as permissões:

mkdir -p /var/www/meusite.com.br/public_html
chown -R www-data:www-data /var/www/meusite.com.br
chmod -R 755 /var/www/meusite.com.br

Configure o virtual host do Nginx. Crie o arquivo /etc/nginx/sites-available/meusite.com.br:

server {
    listen 80;
    server_name meusite.com.br www.meusite.com.br;
    root /var/www/meusite.com.br/public_html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }
}

ln -s /etc/nginx/sites-available/meusite.com.br /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Output esperado:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Se você ainda não conhece bem o processo de acesso SSH ao VPS, consulte o artigo Acessando servidores VPS Linux da AviraHost antes de continuar.

Exportar arquivos e banco de dados do cPanel sem interromper o site

A transferência de arquivos via rsync é a técnica central para garantir a migração sem downtime: o site permanece no ar no servidor antigo enquanto os dados são copiados incrementalmente para o VPS de destino.

No servidor de origem (cPanel), localize o diretório raiz do site. Geralmente fica em /home/usuario/public_html. Execute o rsync a partir do VPS de destino para puxar os arquivos:

rsync -avz --progress -e "ssh -p 22" \
  usuario@ip-do-cpanel:/home/usuario/public_html/ \
  /var/www/meusite.com.br/public_html/

Output esperado (exemplo):
sending incremental file list
./
index.php
wp-config.php
wp-content/uploads/2024/01/imagem.jpg
...
sent 1,234,567 bytes  received 12,345 bytes  98,765.43 bytes/sec
total size is 1,890,123  speedup is 1.52

Exporte o banco de dados MySQL no servidor de origem. Acesse via SSH o cPanel ou use o terminal disponível no painel:

mysqldump -u usuario_db -p nome_do_banco --single-transaction \
  --routines --triggers > /tmp/backup_meusite.sql

Transfira o arquivo SQL para o VPS de destino:

scp usuario@ip-do-cpanel:/tmp/backup_meusite.sql /tmp/backup_meusite.sql

Importe o banco de dados no VPS de destino:

mysql -u meusite_user -p meusite_db < /tmp/backup_meusite.sql

Verifique se a importação foi bem-sucedida:

mysql -u meusite_user -p -e "USE meusite_db; SHOW TABLES;"

Output esperado:
+---------------------------+
| Tables_in_meusite_db      |
+---------------------------+
| wp_commentmeta            |
| wp_comments               |
| wp_options                |
| wp_posts                  |
...
+---------------------------+

Atualize o arquivo de configuração da aplicação (por exemplo, wp-config.php no WordPress) com as novas credenciais do banco de dados no VPS:

define('DB_NAME', 'meusite_db');
define('DB_USER', 'meusite_user');
define('DB_PASSWORD', 'SenhaForte123!');
define('DB_HOST', 'localhost');

Ajuste as permissões dos arquivos transferidos:

chown -R www-data:www-data /var/www/meusite.com.br/public_html
find /var/www/meusite.com.br/public_html -type d -exec chmod 755 {} \;
find /var/www/meusite.com.br/public_html -type f -exec chmod 644 {} \;

Validar o site no VPS antes de alterar o DNS

A validação prévia é o passo que garante zero downtime: você testa o site no novo servidor sem que os visitantes sejam afetados, pois o DNS ainda aponta para o cPanel.

No seu computador local, edite o arquivo hosts para forçar a resolução do domínio para o IP do VPS:

Linux/macOS:

sudo nano /etc/hosts

Windows: edite C:\Windows\System32\drivers\etc\hosts como administrador.

Adicione a linha:

IP_DO_VPS   meusite.com.br www.meusite.com.br

Acesse http://meusite.com.br no navegador. Se o site carregar corretamente, o ambiente está pronto. Verifique:

• Páginas internas e links internos funcionando.
• Formulários e envio de e-mail (se aplicável).
• Imagens e arquivos de mídia carregando.
• Login no painel administrativo (WordPress, Joomla, etc.).
• Conexão com o banco de dados sem erros.

Após validar, remova a entrada do arquivo hosts para restaurar a resolução normal.

Emitir certificado SSL com Certbot no Debian 12

Com o site validado, emita o certificado SSL antes de alterar o DNS. O Certbot precisa que o domínio já aponte para o VPS para completar o desafio HTTP-01. Por isso, emita o certificado imediatamente após a virada do DNS ou use o desafio DNS-01 se quiser emitir antes.

Para emitir após a virada do DNS (método mais simples):

certbot --nginx -d meusite.com.br -d www.meusite.com.br

O Certbot ajustará automaticamente o virtual host do Nginx para redirecionar HTTP para HTTPS. Verifique o resultado:

nginx -t && systemctl reload nginx

Para renovação automática, o Certbot já instala um timer systemd no Debian 12. Confirme:

systemctl status certbot.timer

Output esperado:
● certbot.timer - Run certbot twice daily
     Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; preset: enabled)
     Active: active (waiting)

Se quiser forçar HTTPS manualmente no Nginx antes do Certbot, consulte o artigo Como redirecionar um site http para https? para referência de configuração de redirect 301.

Virar o DNS e sincronizar dados finais

Com o TTL já reduzido para 300 segundos desde 24 horas antes, a propagação do DNS ocorrerá em minutos. Execute um rsync final para capturar arquivos alterados desde a primeira sincronização:

rsync -avz --progress --delete -e "ssh -p 22" \
  usuario@ip-do-cpanel:/home/usuario/public_html/ \
  /var/www/meusite.com.br/public_html/

Atenção: o parâmetro --delete remove do destino arquivos que não existem mais na origem. Use-o apenas nesta sincronização final, quando você tem certeza de que o destino está correto.

Faça um dump final do banco de dados e reimporte para capturar transações recentes:

mysqldump -u usuario_db -p nome_do_banco --single-transaction > /tmp/backup_final.sql
scp usuario@ip-do-cpanel:/tmp/backup_final.sql /tmp/backup_final.sql
mysql -u meusite_user -p meusite_db < /tmp/backup_final.sql

Altere o registro A do domínio no painel de DNS para apontar para o IP do VPS. No painel da registradora ou no Cloudflare, atualize:

• Tipo: A
• Nome: @ (raiz) e www
• Valor: IP_DO_VPS
• TTL: 300

Monitore a propagação com:

watch -n 10 "dig +short meusite.com.br @8.8.8.8"

Quando o IP retornado for o do VPS, a migração está concluída. Restaure o TTL para 3600 ou 86400 após confirmar estabilidade.

Configurar firewall UFW no Debian 12 após a migração

Após a virada do DNS, proteja o VPS com regras de firewall básicas. O UFW simplifica o gerenciamento de iptables no Debian 12:

apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp comment "SSH"
ufw allow 80/tcp comment "HTTP"
ufw allow 443/tcp comment "HTTPS"
ufw enable

Output esperado:
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Verifique as regras ativas:

ufw status verbose

Se você usa MariaDB apenas localmente, não abra a porta 3306 para o mundo. Caso precise de acesso remoto ao banco, restrinja por IP específico:

ufw allow from IP_CONFIAVEL to any port 3306

Para referência sobre configuração de servidor Linux para hospedagem de sites, veja o artigo Configurando um Servidor Linux para Hospedagem de Sites.

Problemas comuns e como resolver

Sintoma: erro 502 Bad Gateway no Nginx após a migração

Causa: O PHP-FPM não está rodando ou o socket configurado no virtual host não corresponde ao socket real do PHP-FPM.
Solução: Verifique o status do PHP-FPM com systemctl status php8.2-fpm. Confirme o caminho do socket com grep -r "listen" /etc/php/8.2/fpm/pool.d/www.conf. O valor deve ser /run/php/php8.2-fpm.sock e deve coincidir com o fastcgi_pass no Nginx. Reinicie ambos os serviços: systemctl restart php8.2-fpm nginx.

Sintoma: site carrega mas imagens e CSS não aparecem

Causa: Permissões incorretas nos arquivos transferidos pelo rsync ou URLs hardcoded no banco de dados apontando para o servidor antigo.
Solução: Reaplique as permissões: chown -R www-data:www-data /var/www/meusite.com.br. Para WordPress, use o WP-CLI para atualizar URLs: wp search-replace 'http://ip-antigo' 'https://meusite.com.br' --all-tables. Verifique também se o wp-config.php tem as constantes WP_HOME e WP_SITEURL corretas.

Sintoma: erro de conexão com o banco de dados após importação

Causa: Credenciais do banco de dados no arquivo de configuração da aplicação ainda apontam para o usuário e senha do cPanel.
Solução: Edite o arquivo de configuração (wp-config.php, .env ou equivalente) e atualize DB_NAME, DB_USER, DB_PASSWORD e DB_HOST para os valores criados no MariaDB do VPS. Teste a conexão diretamente: mysql -u meusite_user -p meusite_db -e "SELECT 1;".

Sintoma: certificado SSL não emite — erro "Domain not pointing to this server"

Causa: O DNS ainda não propagou para o IP do VPS quando o Certbot tentou o desafio HTTP-01.
Solução: Aguarde a propagação completa do DNS (verifique com dig +short meusite.com.br @8.8.8.8) e execute o Certbot novamente: certbot --nginx -d meusite.com.br -d www.meusite.com.br. Alternativamente, use o desafio DNS-01 com certbot certonly --manual --preferred-challenges dns para emitir o certificado antes da virada do DNS.

Sintoma: rsync falha com "Permission denied (publickey)"

Causa: O servidor de origem (cPanel) não aceita autenticação por senha via SSH ou a chave pública do VPS de destino não está autorizada.
Solução: Gere um par de chaves no VPS de destino com ssh-keygen -t ed25519 e adicione a chave pública ao arquivo ~/.ssh/authorized_keys do usuário no cPanel. Se o cPanel bloquear SSH direto, use o Terminal do cPanel para adicionar a chave ou transfira os arquivos via backup do cPanel (.tar.gz) e extraia no VPS.

Perguntas frequentes sobre migrar site do cPanel para VPS

Quanto tempo leva para migrar um site do cPanel para um VPS?

O tempo varia conforme o tamanho do site e do banco de dados. Sites pequenos (até 2 GB) costumam ser migrados em 30 a 60 minutos. O ponto crítico é o TTL do DNS: reduza-o para 300 segundos antes da migração para que a propagação ocorra em minutos após a virada.

É possível migrar do cPanel para VPS sem downtime?

Sim. A estratégia é manter o site antigo no ar enquanto configura o novo servidor, sincronizar os arquivos com rsync e só alterar o DNS quando o ambiente novo estiver validado. Dessa forma, o tempo de indisponibilidade fica restrito à propagação do DNS, que pode ser de segundos a poucos minutos com TTL baixo.

Preciso de cPanel no VPS de destino para migrar?

Não. Você pode migrar para um VPS com Nginx ou Apache puro, sem painel. O cPanel é necessário apenas na origem para exportar os backups. No destino, basta configurar o servidor web, PHP-FPM, banco de dados e transferir os arquivos manualmente via rsync ou SCP.

Como migrar o banco de dados MySQL do cPanel para o VPS sem perder dados?

Exporte o banco com mysqldump no servidor de origem, transfira o arquivo .sql via SCP para o VPS de destino e importe com o comando mysql. Execute a importação antes de virar o DNS para garantir que os dados estejam completos e consistentes no novo servidor.

O que fazer com os e-mails durante a migração do cPanel para VPS?

Se você não vai hospedar e-mail no VPS, mantenha os registros MX apontando para o servidor de e-mail atual. Se for migrar o e-mail também, exporte as caixas postais com imapsync ou pelo backup do cPanel, configure o Postfix/Dovecot no VPS e só altere os registros MX após validar o recebimento.

Conclusão

• Reduza o TTL do DNS para 300 segundos pelo menos 24 horas antes da migração — esse único passo é o que torna o downtime praticamente imperceptível.
• Valide o site no VPS via arquivo hosts antes de alterar qualquer registro DNS, garantindo que arquivos, banco de dados e SSL estejam funcionando corretamente no destino.
• Execute um rsync final com --delete imediatamente antes de virar o DNS para capturar arquivos alterados durante o período de migração e manter os dados sincronizados.

Leia também

• Migrar site do cPanel para Plesk sem perder dados
• WordPress: como migrar tema filho sem perder estilos — direto no código
• Comparativo: cPanel vs. Painéis Open Source para Gerenciamento de VPS Linux

Precisa de ajuda com migração para VPS?

Migrar do cPanel para um VPS Debian 12 exige atenção a cada etapa, mas o resultado é um ambiente mais flexível, com controle total sobre o stack e sem as limitações de um painel compartilhado. Se você prefere um VPS já configurado e pronto para receber sua aplicação, a AviraHost oferece planos com suporte técnico especializado para auxiliar no processo.

Conheça os planos de VPS da AviraHost