Como migrar um site da hospedagem para uma VPS

Este artigo trata de como fazer a mudança. Se vale a pena mudar e que servidor escolher está explicado no artigo Quando migrar da hospedagem compartilhada para uma VPS. Aqui partimos do princípio de que a VPS já foi comprada e o site é feito em WordPress, Bitrix, Laravel ou outra plataforma em PHP com banco MySQL. Para outras stacks a ordem é a mesma, só mudam os comandos.

Prazos: a migração em quatro etapas

1. Dois dias antes: anotar tudo o que funciona na hospedagem e reduzir o TTL dos registros DNS.
2. Um dia antes: preparar o servidor, copiar os arquivos e o banco, testar o site no novo endereço.
3. Dia da migração: bloquear gravações no site, transferir os dados recentes, trocar o DNS.
4. Uma ou duas semanas depois: manter a hospedagem ativa como plano B.

O que anotar na hospedagem

Quase todos os problemas depois da migração são coisas que funcionavam sozinhas na hospedagem e foram esquecidas. Percorra o painel da hospedagem e anote:

• A versão do PHP e as extensões. Elas aparecem no painel ou via SSH com os comandos php -v e php -m. Na VPS, instale a mesma versão e deixe a atualização do PHP para depois, separadamente.
• A versão e o tamanho do banco de dados, a codificação das tabelas.
• As tarefas do cron: o que roda e com que frequência. Os caminhos dos arquivos na VPS serão outros.
• As regras do .htaccess: redirecionamentos, URLs amigáveis, restrições de acesso a pastas.
• O e-mail: caixas, encaminhamentos, para onde apontam os registros MX.
• Os subdomínios e todos os registros DNS, inclusive os TXT de verificação de serviços.
• Serviços externos que conhecem o IP do site. Sistemas de pagamento, integração com o 1C, APIs de parceiros e serviços de e-mail muitas vezes só aceitam requisições de endereços autorizados. O novo IP precisa ser cadastrado neles com antecedência.

Um ou dois dias antes da migração, reduza o TTL dos registros A e AAAA do domínio para 300 segundos. Assim, no dia da troca, o novo endereço se propaga em minutos, e não em um dia.

Prepare o servidor

Comece pela proteção básica: atualizações, login por chave, firewall. Tudo isso está reunido no artigo Primeiros 10 passos depois de comprar uma VPS: segurança. Depois há dois caminhos.

Com painel de controle. O ISPmanager, o FASTPANEL ou o aaPanel instalam o servidor web, a versão certa do PHP e o banco de dados em poucos cliques e oferecem uma interface parecida com a da hospedagem. Planos com eles: VPS com ISPmanager, VPS com FASTPANEL, VPS com aaPanel.

Sem painel. No Ubuntu e no Debian, o conjunto mínimo se instala com um único comando; os pacotes sem número de versão trazem o PHP que vem com o sistema:

apt install nginx mariadb-server php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-zip php-intl

Se na hospedagem a versão do PHP era mais antiga ou mais nova que a do sistema, ela é instalada a partir de repositórios de terceiros com pacotes PHP para Ubuntu e Debian.

Leve em conta a principal diferença em relação à hospedagem: o nginx não lê o .htaccess. Os redirecionamentos e as URLs amigáveis precisam ser levados para a configuração do site. Para o WordPress, a regra principal é esta: try_files $uri $uri/ /index.php?$args;. Se há muitas regras, é mais simples colocar o Apache atrás do nginx: é assim que funciona a maioria dos painéis, e o .htaccess continua valendo.

Transfira os arquivos

Se a hospedagem dá acesso por SSH, o mais rápido é buscar os arquivos direto da VPS com o rsync:

rsync -avz user@old-host.example:~/public_html/ /var/www/example.com/

Rodar de novo o mesmo comando transfere só o que mudou, o que vai ser útil no dia da migração. Se não há SSH, há duas opções: criar um arquivo compactado no gerenciador de arquivos do painel e baixá-lo no servidor com wget, ou buscar os arquivos por FTP com o utilitário lftp:

lftp -u user old-host.example -e "mirror --parallel=4 public_html /var/www/example.com; quit"

O FTP comum transmite a senha em texto aberto, então, se a hospedagem suporta SFTP ou FTPS, use um deles. Depois da cópia, passe os arquivos para o usuário do servidor web e defina as permissões normais:

chown -R www-data:www-data /var/www/example.com
find /var/www/example.com -type d -exec chmod 755 {} +
find /var/www/example.com -type f -exec chmod 644 {} +

Transfira o banco de dados

Faça o dump na hospedagem. Via SSH:

mysqldump --single-transaction --default-character-set=utf8mb4 -u user -p dbname | gzip > db.sql.gz

Sem SSH, o dump é exportado pelo phpMyAdmin, mas bancos grandes podem não passar por causa do limite de tempo da hospedagem; nesse caso, peça o dump ao suporte ou faça-o em partes. Na VPS, crie o banco e o usuário e importe o dump:

mysql -e "CREATE DATABASE site CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'site'@'localhost' IDENTIFIED BY 'senha_forte';
GRANT ALL PRIVILEGES ON site.* TO 'site'@'localhost';"
zcat db.sql.gz | mysql site

Um erro comum na importação é Unknown collation: 'utf8mb4_0900_ai_ci'. Ele significa que o dump foi feito no MySQL 8, mas na VPS está o MariaDB, que não conhece essa collation. Ou instale na VPS o mesmo SGBD da hospedagem, ou troque no dump a collation por utf8mb4_unicode_ci.

Em seguida, coloque os novos dados de acesso ao banco nas configurações do site: no WordPress, wp-config.php; no Bitrix, /bitrix/.settings.php e /bitrix/php_interface/dbconn.php; no Laravel, o arquivo .env. O servidor do banco agora é localhost.

Transfira as tarefas do cron

Rode as tarefas com o usuário do site, e não como root: crontab -u www-data -e. Confira os caminhos: na hospedagem o site ficava em algo como /home/user/public_html, na VPS em /var/www/example.com, e o caminho do PHP também pode ser outro (which php). Verifique à parte as tarefas que a hospedagem executava por conta própria: os agentes do Bitrix no cron, a integração com o 1C, o envio de e-mails da fila.

Teste o site antes de trocar o DNS

Os visitantes ainda acessam a hospedagem, mas você pode abrir o novo servidor na sua máquina. Aponte o domínio para o IP do servidor no arquivo hosts do seu computador (/etc/hosts no Linux e no macOS, C:\Windows\System32\drivers\etc\hosts no Windows):

203.0.113.10  example.com www.example.com

Percorra a página inicial, o catálogo, a página de produto, a busca, os formulários, o carrinho e o login no painel administrativo, e envie uma imagem. Ao mesmo tempo, acompanhe o log de erros: tail -f /var/log/nginx/error.log. Para conferir rapidamente a resposta do servidor sem navegador: curl -I --resolve example.com:80:203.0.113.10 http://example.com/.

Problemas típicos nesta etapa:

• 502 Bad Gateway: o nginx não enxerga o PHP-FPM; o caminho do socket na configuração do site não bate com o das configurações do pool do PHP.
• Tela branca ou erro 500: falta uma extensão do PHP. O nome exato estará no log de erros.
• Arquivos grandes não sobem: no nginx, o corpo da requisição é limitado por padrão a 1 MB (client_max_body_size); no PHP, pelos parâmetros upload_max_filesize e post_max_size.
• Os links dão 404: as regras do .htaccess não foram transferidas.

Certificado TLS

A validação de domínio padrão para um certificado gratuito é feita por HTTP no endereço para onde o DNS aponta agora, ou seja, a hospedagem. Por isso, antes da troca há três caminhos:

• Obter o certificado com validação por DNS: certbot certonly --manual --preferred-challenges dns -d example.com -d www.example.com. O certbot vai pedir que você adicione um registro TXT. Esse certificado não se renova sozinho, então depois da migração emita um comum.
• Transferir temporariamente o certificado e a chave atuais da hospedagem, se o painel permitir exportá-los.
• Trocar o DNS e emitir o certificado logo em seguida com o comando certbot --nginx -d example.com -d www.example.com. Por alguns minutos o site vai dar erro em HTTPS; para um site pequeno, isso é aceitável.

Depois da emissão, confira a renovação automática: certbot renew --dry-run.

O dia da migração

1. Bloqueie as gravações no site: ative o modo de manutenção ou pelo menos suspenda pedidos e comentários. Para uma loja, são alguns minutos.
2. Rode mais uma vez o mesmo comando rsync: ele vai transferir só as mudanças.
3. Faça um dump recente do banco e importe-o na VPS por cima do antigo.
4. Altere o registro A do domínio e do www para o IP do servidor. Se o domínio tem um registro AAAA com o endereço IPv6 da hospedagem, troque-o pelo IPv6 do servidor ou apague-o; caso contrário, parte dos visitantes vai continuar caindo no servidor antigo.
5. Confira se os novos registros estão visíveis: dig +short example.com A @8.8.8.8 e dig +short example.com AAAA @8.8.8.8.
6. Libere as gravações no site, agora já na VPS.

Não perca o e-mail

É o contratempo mais comum da migração. Veja para onde aponta o MX: dig +short example.com MX. Se ali está example.com ou mail.example.com, que leva ao mesmo IP do site, a troca do registro A vai mandar o e-mail para a VPS, onde não há servidor de e-mail. Antes da troca, crie para o e-mail um registro separado com o IP antigo da hospedagem e aponte o MX para ele; melhor ainda, leve com antecedência o e-mail do domínio para um serviço de e-mail separado.

Se o site envia e-mails (pedidos, recuperação de senha), teste-os depois da migração. E-mails vindos de um IP novo sem registro SPF vão parar no spam: adicione o IP do servidor ao SPF ou envie os e-mails pelo SMTP de um serviço de e-mail. Um servidor de e-mail próprio na VPS é outra história; planos para isso estão na seleção VPS para servidor de e-mail.

Depois da migração e como voltar atrás

Não desative a hospedagem por uma ou duas semanas. Nas primeiras horas, confira o banco antigo: se entre o dump final e a troca do DNS alguém conseguiu fazer um pedido no servidor antigo, transfira-o à mão. Depois de alguns dias, dê uma olhada no log de acessos da hospedagem: se ainda há pessoas chegando lá, ficou um endereço antigo em algum lugar, geralmente no registro AAAA ou no www.

Voltar atrás é simples enquanto a hospedagem está ativa: coloque de volta no DNS o IP antigo e, graças ao TTL curto, os visitantes voltam para a hospedagem em minutos. Quando tudo estiver estável, restaure o TTL para os valores normais, configure os backups seguindo o artigo Backups de VPS: estratégias e ferramentas e um monitoramento externo. Planos para sites: VPS para site, VPS para WordPress, VPS para loja virtual, VPS para Bitrix. Para a primeira montagem de teste, a cobrança por hora é prática.