Como Mover Todas as Contas cPanel de um Servidor para Outro

Migrar todas as contas cPanel entre servidores é o processo de transferir cada domínio alojado, os seus ficheiros, bases de dados MySQL, contas de email, zonas DNS, certificados SSL e cron jobs de uma instância WHM de origem para uma instância WHM de destino — normalmente utilizando a Ferramenta de Transferência WHM integrada através de uma ligação SSH autenticada. Quando executado corretamente, este processo não requer cópia manual de ficheiros e preserva todos os metadados das contas intactos.

Este guia abrange o fluxo de trabalho completo de migração a nível de produção: verificações pré-voo, configuração da Ferramenta de Transferência, estratégia de transição DNS, validação pós-migração e limpeza — incluindo casos extremos que causam falhas silenciosas em ambientes reais.

Pré-requisitos e Lista de Verificação Pré-Migração

Ignorar a preparação é a causa mais comum de migrações cPanel falhadas ou incompletas. Antes de tocar em qualquer um dos servidores, verifique cada item abaixo.

Acesso root em ambos os servidores. A Ferramenta de Transferência WHM autentica-se no servidor de origem via SSH como root. Se o servidor de origem tiver PermitRootLogin no em /etc/ssh/sshd_config, deve ativá-lo temporariamente ou pré-configurar a autenticação SSH baseada em chaves para root.

Versões cPanel/WHM compatíveis. O cPanel pode transferir contas de versões mais antigas para versões mais recentes, mas não ao contrário. Um destino a executar cPanel 110 pode importar de uma origem a executar cPanel 98, mas o oposto falhará. Verifique as versões no WHM em Informações do Servidor ou execute:

cat /usr/local/cpanel/version

Versões PHP e MySQL correspondentes ou compatíveis. Se a origem executa PHP 7.4 e MySQL 5.7 enquanto o destino executa PHP 8.2 e MySQL 8.0, as aplicações podem falhar após a transferência mesmo que os ficheiros sejam copiados corretamente. Audite as versões PHP instaladas e os handlers padrão em ambos os servidores antes de prosseguir.

Espaço em disco suficiente no destino. A Ferramenta de Transferência requer espaço livre igual pelo menos ao tamanho total comprimido de todas as contas a transferir, mais margem para extração. Execute df -h no destino e compare com o uso total de disco das contas visível na vista Listar Contas do WHM na origem.

Regras de firewall que permitem SSH entre servidores. O servidor de destino inicia uma ligação SSH de saída para a origem. Certifique-se de que a porta 22 (ou a porta SSH personalizada) está aberta na firewall do servidor de origem para o endereço IP do destino.

Backups completos das contas na origem. Gere um backup cPanel completo para cada conta antes de começar. Este é o seu ponto de recuperação caso a transferência corrompa ou copie parcialmente uma conta.

/scripts/pkgacct username /backup/directory

Se estiver a executar o seu novo ambiente num plano de Alojamento VPS, confirme que o seu VPS tem cPanel/WHM já licenciado e instalado antes de prosseguir. Uma instalação cPanel nova requer uma licença válida associada ao endereço IP do servidor.

Passo 1: Instalar e Configurar cPanel/WHM no Servidor de Destino

Se o cPanel ainda não estiver instalado no destino, execute o instalador oficial como root. Este processo demora 20–45 minutos dependendo do hardware:

cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest && sh latest

Após a conclusão da instalação, aceda ao WHM em https://your-server-ip:2087 e conclua o assistente de configuração inicial. Preste especial atenção a:

• Nome do host: Defina um nome de domínio completamente qualificado (FQDN) que resolva para o IP do servidor. Um nome de host não resolvível causa falhas na entrega de email após a migração.
• Servidores de nomes: Configure os nomes dos seus servidores de nomes e os respetivos endereços IP se planeia alojar DNS no novo servidor.
• Handlers PHP: Instale as mesmas versões PHP disponíveis no servidor de origem utilizando WHM > MultiPHP Manager para evitar problemas de compatibilidade de aplicações.
• Versão MySQL/MariaDB: Corresponda à versão do motor de base de dados do servidor de origem sempre que possível, ou teste a compatibilidade das aplicações com a versão mais recente antes de migrar contas de produção.

Para equipas que gerem múltiplos ambientes de clientes, um VPS com cPanel fornece um ambiente pré-configurado que elimina completamente a fase de instalação manual.

Passo 2: Configurar a Ferramenta de Transferência WHM

A Ferramenta de Transferência WHM é o método oficial para migração em massa de contas. Trata do empacotamento, transferência, extração e criação de contas de forma atómica para cada conta.

2.1 Aceder à Ferramenta de Transferência

No servidor de destino, inicie sessão no WHM e navegue até:

WHM > Transferências > Ferramenta de Transferência

Este é um ponto crítico que confunde muitos administradores: a Ferramenta de Transferência é sempre executada a partir do servidor de destino que importa contas da origem — não ao contrário.

2.2 Ligar ao Servidor de Origem

Introduza os seguintes detalhes de ligação:

• Endereço do Servidor Remoto: Endereço IP ou nome do host do servidor de origem
• Porta SSH Remota: O padrão é 22; utilize a porta real se foi alterada (verifique /etc/ssh/sshd_config na origem para a diretiva Port)
• Método de autenticação: Palavra-passe root ou chave SSH (a autenticação por chave é fortemente preferida por segurança e fiabilidade)

Para utilizar autenticação por chave SSH, copie a chave pública root do servidor de destino para a origem:

ssh-copy-id -i /root/.ssh/id_rsa.pub -p 22 root@source-server-ip

Uma vez ligada, a Ferramenta de Transferência consulta o servidor de origem e devolve uma lista de todas as contas cPanel, pacotes e configurações de revendedor.

2.3 Selecionar Contas e Âmbito de Transferência

Pode selecionar todas as contas ou um subconjunto. Além das contas individuais, a Ferramenta de Transferência também oferece:

• Pacotes: Transferir definições de planos de alojamento para que as contas mantenham as suas alocações de recursos
• Zonas DNS: Copiar todos os ficheiros de zona, o que é essencial se o novo servidor atuará como servidor de nomes autoritativo
• Privilégios de Revendedor e ACLs: Preservar configurações de contas de revendedor e as respetivas permissões associadas

2.4 Configurar Opções de Transferência

Duas configurações aqui têm impacto operacional significativo:

Transferência Expressa automatiza a transição DNS atualizando as zonas DNS no servidor de origem para apontar para o IP do destino imediatamente após cada conta ser copiada. Isto minimiza a janela durante a qual um domínio resolve para o servidor antigo. Utilize isto apenas se o destino estiver pronto para servir tráfego imediatamente e tiver confirmado que todas as aplicações estão funcionais.

Encaminhamento de Email: Defina como Automático a menos que tenha uma razão específica para forçar encaminhamento local ou remoto. O encaminhamento de email incorreto é uma das principais causas de falhas na entrega de email após a migração.

2.5 Iniciar a Transferência

Clique em Copiar para iniciar o processo. O WHM irá:

1. Ligar via SSH ao servidor de origem
2. Executar pkgacct para criar um arquivo comprimido de cada conta
3. Transferir o arquivo para o destino via SSH/SCP
4. Executar restorepkg no destino para extrair e criar a conta
5. Registar o resultado para cada conta

Monitorize cuidadosamente o registo de transferência em tempo real. Erros em contas individuais não interrompem o processo geral — uma conta pode falhar silenciosamente enquanto outras têm sucesso. Reveja o registo completo após a conclusão da transferência e execute novamente as contas com falha individualmente.

A duração da transferência depende do volume total de dados e da largura de banda entre servidores. Um servidor com 50 GB de dados de contas numa ligação de 1 Gbps normalmente conclui em menos de 30 minutos. Numa ligação de 100 Mbps, preveja 60–90 minutos.

Passo 3: Estratégia de Transição DNS

A gestão DNS é onde as migrações mais frequentemente criam períodos prolongados de inatividade. Compreender a mecânica de propagação é essencial para minimizar o impacto nos utilizadores.

3.1 Reduzir o TTL Antes da Migração

Idealmente, 24–48 horas antes da migração, reduza o TTL em todos os registos A dos domínios alojados para 300 segundos (5 minutos). Isto garante que, uma vez atualizados os registos DNS, a alteração se propague globalmente em minutos em vez de horas. Se não fez isto antecipadamente, deve considerar o valor TTL existente como a sua janela máxima de propagação.

3.2 Atualizar Zonas DNS

Se o novo servidor é o servidor de nomes autoritativo para os domínios, atualize os registos A em cada ficheiro de zona via WHM > Funções DNS > Editar Zona DNS, alterando o IP do endereço do servidor antigo para o novo.

Se os domínios utilizam um fornecedor DNS externo ou DNS do registador, inicie sessão em cada registador ou painel de gestão DNS e atualize os registos A manualmente. Para atualizações em massa em muitos domínios, a maioria dos registadores oferece acesso API ou importação CSV.

3.3 Atualizar Registos Glue dos Servidores de Nomes

Se também estiver a migrar servidores de nomes (por exemplo, ns1.yourdomain.com), deve atualizar os registos glue no registador de domínios — não apenas o ficheiro de zona. Os registos glue são mapeamentos de endereços IP para servidores de nomes registados sob o mesmo domínio que servem. Não atualizar os registos glue é um erro comum que causa falha completa na resolução DNS para todos os domínios alojados.

3.4 Verificar Propagação

Utilize dig para verificar a resolução a partir de múltiplas localizações geográficas:

dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1

Confirme com um verificador de propagação baseado na web. A propagação global completa normalmente conclui em 1–4 horas quando o TTL foi pré-reduzido, ou até 48 horas quando o TTL não foi reduzido antecipadamente.

Se os seus domínios estão registados através do Registo de Domínios, as atualizações dos servidores de nomes podem ser geridas diretamente a partir do mesmo painel de controlo, simplificando o processo de transição.

Passo 4: Validação Pós-Migração

Nunca declare uma migração concluída baseando-se apenas no registo de sucesso da Ferramenta de Transferência. Valide cada camada da pilha de forma independente.

4.1 Funcionalidade das Aplicações Web

Aceda a cada domínio transferido diretamente por IP utilizando uma substituição no ficheiro hosts (para contornar a propagação DNS) e verifique se a aplicação carrega corretamente:

# Add to /etc/hosts on your local machine temporarily
203.0.113.50  yourdomain.com www.yourdomain.com

Verifique erros de ligação à base de dados, caminhos de ficheiros em falta e configurações de aplicações incorretas. Os sites WordPress falham frequentemente se as credenciais de base de dados em wp-config.php referenciam localhost mas o caminho do socket MySQL difere entre servidores.

4.2 Integridade da Base de Dados

Inicie sessão no cPanel para cada conta e verifique se as bases de dados existem e estão acessíveis. Para bases de dados críticas, execute uma verificação de integridade:

mysqlcheck -u root -p --all-databases --check

4.3 Funcionalidade de Email

Teste o email de entrada e saída para cada conta. Verifique se os registos MX resolvem corretamente e se o servidor de email está a aceitar ligações nas portas 25, 465 e 587. Verifique /var/log/exim_mainlog para erros de entrega:

tail -f /var/log/exim_mainlog

Para empresas com infraestrutura de email dedicada, o Alojamento de Email fornece ambientes de email isolados que não são afetados por migrações de servidores web.

4.4 Verificação de Certificados SSL

Confirme que os certificados SSL foram transferidos corretamente e estão ativos. No WHM, navegue até SSL/TLS > Gerir Hosts SSL e verifique se cada domínio tem um certificado válido e não expirado. O AutoSSL deve reemitir automaticamente certificados Let’s Encrypt para os que falharam na transferência, mas acione-o manualmente para evitar aguardar pela execução agendada:

/usr/local/cpanel/bin/autossl_check --all

Se gerir certificados de forma independente, os Certificados SSL podem ser instalados diretamente no novo servidor sem dependência do processo de transferência.

4.5 Cron Jobs e Tarefas Agendadas

Os cron jobs são transferidos como parte do pacote de conta, mas verifique-os em cPanel > Cron Jobs para cada conta. Preste especial atenção aos cron jobs que referenciam caminhos de ficheiros absolutos ou variáveis de ambiente específicas do servidor que podem diferir no novo servidor.

Passo 5: Limpeza e Reforço Pós-Migração

5.1 Suspender Contas no Servidor de Origem

Assim que o DNS tiver propagado e a validação estiver concluída, suspenda todas as contas no servidor de origem via WHM > Listar Contas > Suspender. Não as elimine ainda. A suspensão impede que novos dados sejam escritos na origem enquanto a mantém disponível como alternativa caso surja um problema crítico após a migração.

5.2 Backup Pós-Migração

Crie um backup completo e atualizado de todas as contas no novo servidor imediatamente após a migração. O estado transferido é a sua nova linha de base:

/scripts/cpbackup --force

Verifique se os backups são concluídos com sucesso e estão armazenados numa localização separada do próprio servidor — idealmente um destino de backup externo ao servidor configurado em WHM > Configuração de Backup.

5.3 Monitorização de Desempenho

Monitorize a utilização de recursos do novo servidor durante 72 horas após a migração. Métricas principais a observar:

• Média de carga CPU (deve permanecer abaixo do número de núcleos CPU sob carga normal)
• Utilização de memória e atividade de swap
• Tempo de espera de I/O de disco (tempo de espera de I/O elevado indica estrangulamentos de armazenamento)
• Registo de consultas lentas MySQL para consultas com fraco desempenho no novo esquema ou versão do motor

Utilize top, iostat e vmstat para monitorização em tempo real, e reveja o Monitor de Recursos do cPanel no WHM para consumo de recursos por conta.

5.4 Desativar o Servidor de Origem

Após um período mínimo de observação de 7 dias sem problemas reportados, pode desativar o servidor de origem. Antes de encerrar o servidor antigo, arquive um backup final em armazenamento frio. Este arquivo serve como registo legal e operacional e tem um custo muito reduzido de retenção.

Migração de Contas cPanel: Comparação de Métodos

Problemas Comuns e Como Evitá-los

Falhas silenciosas na transferência de contas. A Ferramenta de Transferência continua a processar mesmo quando contas individuais falham. Leia sempre o registo de transferência completo — não assuma sucesso porque a ferramenta terminou sem parar.

Incompatibilidade de privilégios de utilizador MySQL. restorepkg recria utilizadores de base de dados, mas se um nome de utilizador de base de dados exceder o limite de 32 caracteres do MySQL (um problema comum com contas legadas), o utilizador é criado com um nome truncado e as credenciais de base de dados da aplicação deixam de corresponder. Audite nomes de utilizadores de base de dados longos antes de migrar.

Dependências de módulos Perl e software personalizado. Aplicações que dependem de módulos Perl compilados de forma personalizada, pacotes Python ou bibliotecas do sistema instaladas fora dos caminhos geridos pelo cPanel não serão transferidas. Estas dependências devem ser reinstaladas manualmente no destino.

Discrepâncias de quotas de disco. O sistema de quotas de disco do cPanel utiliza quotas ao nível do sistema de ficheiros. Após a migração, as quotas podem não refletir com precisão até que o script de recálculo de quotas seja executado:

/scripts/fixquotas

Conflitos de regras ModSecurity. Se o servidor de origem tinha regras ModSecurity personalizadas ou uma versão de conjunto de regras diferente do destino, os sites transferidos podem receber erros 403 inesperados. Reveja os registos ModSecurity em /usr/local/apache/logs/error_log após a migração.

Lacunas de permissões em contas de revendedor. As ACLs de revendedor e atribuições de pacotes são transferidas, mas se o WHM de destino tiver listas de funcionalidades diferentes configuradas, os revendedores podem verificar que as suas contas têm capacidades diferentes ou menores do que o esperado. Audite as configurações de revendedor após a migração.

Para ambientes de alto tráfego onde a tolerância a inatividade é próxima de zero, considere executar a migração num Servidor Dedicado com recursos dedicados, eliminando o risco de contenção de recursos durante as fases de transferência e validação.

Matriz de Decisão Técnica

Utilize esta matriz para determinar a sua abordagem de migração com base nas características do ambiente:

FAQ

Posso migrar contas cPanel sem acesso root ao servidor de origem?

Não. A Ferramenta de Transferência WHM requer acesso SSH root ao servidor de origem para executar pkgacct e ler todos os dados das contas. Se o acesso root não estiver disponível, a única alternativa é solicitar ficheiros de backup cPanel individuais (arquivos .tar.gz) ao administrador do servidor de origem e restaurá-los manualmente utilizando restorepkg no destino.

Quanto tempo demora uma migração completa de servidor cPanel?

O tempo de transferência depende do volume total de dados e da largura de banda de rede entre servidores. Um servidor com 100 GB de dados de contas numa ligação dedicada de 1 Gbps normalmente transfere em 15–30 minutos. Em ligações partilhadas ou com limitação de velocidade, os mesmos dados podem demorar várias horas. A propagação DNS acrescenta 1–48 horas adicionais dependendo dos valores TTL.

Os certificados SSL são transferidos automaticamente?

Os certificados SSL instalados via AutoSSL (Let’s Encrypt) não são transferidos como certificados válidos — são reemitidos pelo AutoSSL no servidor de destino porque estão vinculados ao IP do servidor e à conta. Os certificados adquiridos comercialmente armazenados no cPanel são transferidos como parte do pacote de conta, mas devem ser verificados e reativados após a migração.

O que acontece ao email no servidor antigo durante a janela de migração?

O email entregue ao servidor antigo durante a janela de migração é armazenado na fila de email do servidor antigo e nas caixas de correio dos utilizadores. Não replica automaticamente para o novo servidor. Para evitar perda de email, mantenha os serviços de email do servidor antigo em funcionamento até que o DNS propague completamente, ou configure o Exim do servidor antigo para reencaminhar o email recebido para o IP do novo servidor durante o período de transição.

A Ferramenta de Transferência WHM pode migrar contas entre sistemas operativos diferentes (por exemplo, CentOS para AlmaLinux)?

Sim. A Ferramenta de Transferência é agnóstica ao SO ao nível da camada de aplicação — transfere dados de contas cPanel, não configurações ao nível do SO. As migrações de CentOS 7 para AlmaLinux 8 ou Rocky Linux 8 são totalmente suportadas e são o cenário de migração mais comum após o fim de vida do CentOS 7. Verifique se quaisquer configurações personalizadas ao nível do sistema (políticas SELinux, módulos de kernel personalizados, serviços fora do cPanel) são replicadas manualmente no destino.