Como migrar um servidor para um novo VPS

Migrar um servidor para um novo VPS como uma mudança ensaiada

Para migrar um servidor para um novo VPS, trate a mudança como uma mudança ensaiada, e não como uma simples cópia. Prepare o novo servidor de raiz, sincronize os dados duas vezes, confirme que o novo servidor funciona com o seu próprio endereço IP antes de alterar o DNS e, depois, altere os registos e mantenha o servidor antigo em execução até ter a certeza de que tudo está correto. Copiar os dados é a parte fácil. A ordem das operações determina se a mudança será tranquila ou dispendiosa.

Este guia abrange um servidor Linux que executa uma aplicação Web, uma base de dados e um certificado TLS (transport layer security). Isto cobre a maioria das configurações de servidor único. Estão envolvidos dois hosts, por isso cada exemplo indica num comentário em que host deve ser executado. Os endereços pertencem aos intervalos reservados para documentação: 198.51.100.10 é o servidor antigo e 203.0.113.20 é o novo.

Leia todo o procedimento antes de começar. O primeiro passo, reduzir o TTL do DNS, tem de ser feito vários dias antes do passo que realmente interessa.

Faça o inventário antes de criar qualquer coisa

Não é possível reconstruir um servidor que não foi descrito. Reserve uma hora para registar o que o servidor antigo faz, porque o item que falha depois de uma migração é sempre aquele de que ninguém se lembrou: uma tarefa do cron, uma exceção da firewall ou um ficheiro de ambiente fora do diretório da aplicação.

Execute estes comandos no servidor antigo e guarde o resultado num local a que possa aceder a partir do novo servidor.

# old server: packages you asked for, not the dependencies they pulled in
apt-mark showmanual > ~/inv-packages.txt

# old server: what runs now, and what starts at boot
systemctl list-units --type=service --state=running --no-pager > ~/inv-services.txt
systemctl list-unit-files --state=enabled --no-pager >> ~/inv-services.txt
systemctl list-timers --all --no-pager > ~/inv-timers.txt

# old server: what is listening, on which address and port
sudo ss -tulpn > ~/inv-ports.txt

# old server: human accounts, skipping the system ones
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $6, $7}' /etc/passwd

apt-mark showmanual é a lista que vale a pena manter, porque inclui tudo o que foi instalado como dependência. Um dpkg --get-selections completo num servidor com cinco anos devolve duas mil linhas e não informa sobre a finalidade de nada.

As tarefas agendadas podem estar em dois locais, por isso verifique ambos. A tarefa que só é executada mensalmente é aquela que descobrirá seis semanas depois da migração.

# old server: per-user crontabs, then the system drop-ins
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -lu "$u" 2>/dev/null | sed "s/^/$u: /"; done
sudo ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly

Depois, verifique os elementos que não são ficheiros comuns: regras da firewall, certificados, bases de dados e a quantidade de dados que será realmente transferida.

# old server
sudo ufw status verbose        # or: sudo nft list ruleset
sudo certbot certificates
sudo -u postgres psql -c '\l'  # or: sudo mysql -e 'SHOW DATABASES;'
sudo du -xh --max-depth=1 / | sort -h

certbot certificates apresenta o nome de cada certificado, os domínios abrangidos, a data de expiração e os caminhos dos ficheiros no disco. Esse resultado é a sua lista de verificação de TLS. du -x permanece num único sistema de ficheiros, por isso não entra num volume de backup montado nem apresenta um valor dez vezes superior ao real.

Dois itens ficam fora do servidor e são esquecidos repetidamente. Primeiro, qualquer entidade externa que autorize o endereço IP do servidor numa allowlist: um gateway de pagamentos, uma base de dados gerida, um relay SMTP ou uma API de um parceiro. O novo servidor terá um endereço diferente, por isso é necessário adicionar o novo IP a essas allowlists antes da mudança, e não depois. Segundo, os registos DNS que não criou pessoalmente, como um registo MX ou um registo SPF que contenha o IP antigo em texto.

Por que reconstruir em vez de clonar o sistema de ficheiros raiz antigo

Clonar todo o sistema de ficheiros raiz para o novo VPS parece mais rápido, e é, até deixar de ser. Um sistema de ficheiros raiz que esteve em produção durante anos contém configurações editadas manualmente que ninguém documentou, pacotes de um repositório que já não existe e uma configuração de arranque criada para o hardware virtual da plataforma antiga. Importa tudo isso, incluindo o motivo da migração.

Reconstruir é mais lento no primeiro dia e mais barato todos os dias seguintes. Instale a versão atual, aplique o hardening base e copie apenas os dados: o diretório da aplicação, as configurações dos sites, o dump da base de dados, os certificados e os uploads dos utilizadores. Tudo o que não conseguir explicar fica para trás. Prepare o novo servidor como prepararia qualquer servidor, seguindo os primeiros dez minutos num novo VPS, depois adicione os serviços do inventário um de cada vez e confirme cada um antes de adicionar o seguinte.

Quando restaurar uma imagem ou snapshot é a decisão certa

Há uma exceção legítima à reconstrução. Se o servidor antigo não arrancar ou se já não for possível reconstruir a aplicação a partir do código-fonte, restaurar uma imagem ou snapshot do fornecedor é a opção pragmática. Existem limitações concretas: normalmente, isto só funciona dentro do mesmo fornecedor e, muitas vezes, apenas na mesma família de planos, porque o disco restaurado espera os dispositivos virtuais e a nomenclatura de rede dessa plataforma.

Um snapshot de um servidor em execução também tem o mesmo problema de consistência que qualquer outra cópia ao nível dos ficheiros de uma base de dados ativa. Trate a restauração de uma imagem como uma via de recuperação, não como um plano de migração, e leia porque um snapshot não é o mesmo que um backup antes de basear um plano num snapshot.

Como os ficheiros são transferidos: rsync sobre SSH

Execute rsync no servidor antigo, enviando os dados para o novo. Enviar é normalmente mais simples, porque o servidor antigo já tem os dados e consegue lê-los todos através de sudo.

# old server: dry run first, and read what it says it will do
sudo rsync -aHAX --dry-run --itemize-changes \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

# old server: the real bulk pass
sudo rsync -aHAX --info=progress2 \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

As flags são importantes. -a preserva permissões, marcas temporais, ligações simbólicas e propriedade. -H mantém as ligações físicas como ligações físicas, em vez de as expandir para cópias separadas. -A copia as ACL POSIX (listas de controlo de acesso) e -X copia os atributos estendidos. Sem estas duas últimas opções, um ficheiro que parece idêntico pode comportar-se de forma diferente, porque os rótulos SELinux e as ACL ficam armazenados nos atributos estendidos e nenhum outro mecanismo os regista.

Dois detalhes causam a maioria das falhas nesta operação.

A barra final determina onde os dados ficam. /srv/app/ significa o conteúdo desse diretório. /srv/app significa o próprio diretório. Se se enganar, acaba com /srv/app/app no servidor novo, e a aplicação inicia-se mas depois comunica que faltam ficheiros, porque os caminhos configurados passaram a ter um nível a menos.

Em sudo, o til representa o diretório pessoal de root. Escrever -e 'ssh -i ~/.ssh/id_ed25519' dentro de um sudo rsync procura a chave em /root/.ssh, não no seu próprio diretório pessoal. Se a chave não estiver nesse local, o SSH apresenta Permission denied (publickey), o rsync apresenta rsync: connection unexpectedly closed e termina com um código diferente de zero. Especifique o caminho completo da chave. Se essa mensagem de autenticação continuar a aparecer depois de corrigir o caminho, a falha publickey tem uma lista curta de causas e as permissões dos diretórios no servidor novo são o próximo ponto a verificar.

É necessário tomar uma decisão relativamente à propriedade. Quando é executado como root, o rsync associa o proprietário e o grupo pelo nome, por predefinição. Assim, um ficheiro pertencente a www-data no servidor antigo passa a pertencer a www-data no servidor novo, mesmo que o UID numérico (ID de utilizador) seja diferente. É isso que pretende numa reconstrução. Adicione --numeric-ids apenas quando estiver a copiar um sistema de ficheiros cujas contas não existem no destino. Nesse caso, verifique o resultado com ls -ln, porque um ficheiro pertencente a um UID sem uma conta correspondente aparece apenas como um número e todos os serviços que o leem têm o acesso negado.

Execute a transferência principal vários dias antes, enquanto o servidor antigo ainda serve tráfego. Repita-a tantas vezes quantas quiser: o rsync envia apenas o que mudou, por isso a segunda execução demora minutos em vez de horas. A execução final, dentro da janela de migração, adiciona --delete para que os ficheiros removidos no servidor antigo também desapareçam no novo.

# old server: final pass, inside the window, after the app has stopped writing
sudo rsync -aHAX --delete --info=progress2 \
  -e 'ssh -i /root/.ssh/id_ed25519' \
  /srv/app/ deploy@203.0.113.20:/srv/app/

--delete remove no destino os ficheiros que já não existem na origem. Por isso, um caminho de origem incorreto combinado com --delete esvazia o diretório de destino. Execute primeiro com --dry-run, sempre. As transferências longas também terminam quando a sessão SSH do seu portátil cai. Por isso, inicie-as dentro de tmux ou screen no servidor antigo. Adicione --bwlimit=20M se a cópia saturar a ligação enquanto o servidor antigo ainda serve utilizadores.

Como a base de dados é transferida: um dump nativo

Uma base de dados não é um diretório de ficheiros, embora pareça ser. É um conjunto de ficheiros, estado em memória e um write-ahead log. Só é consistente nos instantes definidos pela própria base de dados. Use a ferramenta nativa.

O PostgreSQL precisa de dois dumps, porque os roles são globais ao cluster e pg_dump não os inclui:

# old server
sudo -u postgres pg_dumpall --globals-only -f /var/backups/globals.sql
sudo -u postgres pg_dump -Fc -f /var/backups/appdb.dump appdb

# new server: restore in this order
sudo -u postgres psql -f /var/backups/globals.sql
sudo -u postgres createdb -O appuser appdb
sudo -u postgres pg_restore -d appdb --no-owner /var/backups/appdb.dump

Se ignorar globals.sql, todas as tabelas serão restauradas, mas nenhum role da aplicação poderá lê-las, porque as instruções GRANT referem um utilizador que não existe. -Fc escreve o formato de arquivo custom, que apenas pg_restore lê e que permite restaurar tabelas selecionadas mais tarde. Restaure na mesma versão principal ou numa versão mais recente. A operação inversa, por exemplo de 17 para 16, não é suportada, e pg_restore rejeita o arquivo com um erro de versão não suportada no cabeçalho do ficheiro antes de escrever qualquer coisa.

MySQL e MariaDB usam um comando, com quatro opções que não estão ativas por predefinição:

# old server
sudo mysqldump --single-transaction --routines --triggers --events \
  --databases appdb > /var/backups/appdb.sql

# new server
sudo mysql < /var/backups/appdb.sql

--single-transaction cria um snapshot consistente sem bloquear as operações de escrita, mas apenas para tabelas InnoDB. Uma tabela MyISAM na mesma base de dados é copiada sem essa garantia. Verifique, portanto, os motores de armazenamento antes de confiar no dump. --routines, --triggers e --events estão desativadas por predefinição. Isto significa que um dump simples restaura os dados, mas deixa silenciosamente para trás os procedimentos armazenados e os eventos agendados. Os utilizadores da base de dados e as respetivas permissões estão na base de dados de sistema mysql, que um dump de --databases appdb nunca inclui. Recrie-os no novo servidor com CREATE USER e GRANT. O MariaDB 11 disponibiliza a mesma ferramenta como mariadb-dump e mantém mysqldump como uma ligação simbólica. Por isso, ambos os nomes funcionam em agosto de 2026.

O SQLite é um único ficheiro. Copiá-lo enquanto a aplicação escreve cria um ficheiro inconsistente. Existe um procedimento seguro próprio:

# old server
sqlite3 /var/lib/app/app.db ".backup '/var/backups/app.db'"

Independentemente do motor, verifique o dump antes de confiar nele. Um dump que terminou prematuramente porque o disco ficou cheio será restaurado sem erro, até ao ponto em que foi truncado.

# old server: a complete mysqldump ends with a line reading "-- Dump completed on ..."
tail -n 3 /var/backups/appdb.sql

# new server: after restore, count rows in a table whose size you know
sudo mysql -e 'SELECT COUNT(*) FROM appdb.orders;'

Por que não é possível usar rsync com um banco de dados em execução

O rsync copia os arquivos um a um. Um banco de dados em execução grava em vários arquivos ao mesmo tempo. Quando o rsync chega ao último arquivo, o primeiro já está desatualizado. A cópia contém páginas de momentos diferentes. Esse estado nunca existiu no banco de dados. O resultado pode ser um servidor que se recusa a iniciar. No pior caso, o servidor inicia, responde corretamente por uma semana e falha quando uma consulta finalmente acessa a página danificada. Não há nenhum aviso nesse intervalo.

Há duas formas seguras de mover os próprios arquivos. Pare o banco de dados, faça a cópia e inicie-o novamente. É uma opção correta e simples, mas o período de indisponibilidade será igual ao tempo necessário para a cópia. A outra opção é usar a ferramenta própria para fazer uma cópia física de um servidor em execução. No PostgreSQL, essa ferramenta é pg_basebackup. Ela coordena a operação com o servidor para manter a cópia consistente:

# new server: pull a physical copy from the old one
pg_basebackup -h 198.51.100.10 -U replicator -D /var/lib/postgresql/16/main -X stream -P

Essa opção exige uma role com o atributo REPLICATION e uma entrada pg_hba.conf correspondente no servidor antigo. Por isso, requer mais configuração do que um dump. Vale a pena quando o banco de dados é grande o suficiente para que um dump e uma restauração não caibam na janela de manutenção. Em uma migração normal de um único servidor, o dump é a melhor opção.

Recrie os certificados antes da migração, não depois

Um certificado TLS está associado ao nome de domínio, não ao endereço IP, por isso o próprio ficheiro do certificado pode ser movido sem problemas. O que não é migrado de forma simples é a renovação. O desafio HTTP-01 predefinido do Certbot pede à autoridade certificadora para obter um ficheiro através da porta 80 no nome que está a ser certificado. Enquanto o DNS não apontar para o novo servidor, esse pedido chega ao servidor antigo e a renovação no novo servidor falha.

A primeira opção é copiar os certificados existentes e o respetivo estado de renovação. Eles permanecem válidos até à data de expiração, independentemente do servidor onde estejam.

# old server
sudo rsync -aHAX -e 'ssh -i /root/.ssh/id_ed25519' \
  /etc/letsencrypt/ root@203.0.113.20:/etc/letsencrypt/

Cada ficheiro em /etc/letsencrypt/renewal/ identifica o plugin autenticador que emitiu o certificado. Por isso, instale o mesmo plugin no novo servidor (python3-certbot-nginx, por exemplo), caso contrário a primeira renovação falha com uma mensagem sobre um autenticador desconhecido. Confirme que a renovação funciona antes de depender dela:

# new server, after DNS has moved
sudo certbot renew --dry-run

A segunda opção é emitir um certificado novo no novo servidor usando o desafio DNS-01. Este desafio comprova o controlo através de um registo TXT e nunca utiliza a porta 80. Funciona antes da migração, enquanto o nome ainda resolve para o servidor antigo. É a opção mais simples se conseguir automatizar o seu fornecedor de DNS. Emitir certificados com o desafio DNS-01 explica a configuração do plugin e das credenciais.

Em qualquer dos casos, verifique o que o novo servidor apresenta efetivamente, sem alterar o DNS:

# your laptop
echo | openssl s_client -connect 203.0.113.20:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -dates -issuer

-servername envia SNI (indicação do nome do servidor), que permite ao servidor web escolher o virtual host correto. Se o omitir, recebe o certificado predefinido desse IP e uma incompatibilidade que parece um problema real, mas não é.

Reduza o TTL do DNS dias antes da mudança

O DNS é onde uma migração cuidadosa ainda pode falhar, porque o atraso é inerente ao processo e não pode ser reduzido no próprio dia. Um resolver que tenha colocado o seu registo A em cache continua a fornecê-lo durante o período do TTL (time to live) recebido. Reduzir o TTL agora não altera nada para um resolver que colocou o registo em cache há dez minutos com o valor antigo: ele mantém o valor antigo durante o restante do TTL antigo e só depois toma conhecimento do novo valor, mais curto. Por isso, reduza o TTL pelo menos um período completo do TTL antigo antes da mudança. Um dia de antecedência é a opção mais confortável. Se estes componentes ainda forem novos para si, a explicação detalhada sobre registos, resolvers e cache apresenta o contexto.

Os números abaixo são cálculos baseados no próprio TTL, não uma medição.

[
  {
    "label": "TTL 3600 s (common default)",
    "ttl_seconds": 3600,
    "worst_case_stale_minutes": 60
  },
  {
    "label": "TTL 900 s",
    "ttl_seconds": 900,
    "worst_case_stale_minutes": 15
  },
  {
    "label": "TTL 300 s (lowered for cutover)",
    "ttl_seconds": 300,
    "worst_case_stale_minutes": 5
  },
  {
    "label": "TTL 60 s (short window)",
    "ttl_seconds": 60,
    "worst_case_stale_minutes": 1
  }
]

Um registo publicado com um TTL de 3600 segundos pode continuar a encaminhar utilizadores para o IP antigo durante 60 minutos depois de o alterar. Reduza-o para 300 segundos e esse pior caso passa para 5 minutos. Considere estes valores como um limite mínimo, não como uma garantia. Alguns resolvers aplicam um TTL mínimo próprio e ignoram valores inferiores, e alguns ambientes de execução de aplicações colocam um endereço resolvido em cache durante toda a vida do processo. Por isso, um cliente iniciado antes da alteração pode nunca voltar a consultar o DNS até ser reiniciado.

Ao verificar se o TTL reduzido está ativo, leia a resposta autoritativa, não a sua própria cache:

# your laptop: ask the zone's own nameserver, so no cache is involved
dig +short NS example.com
dig +noall +answer @$(dig +short NS example.com | head -n1) example.com A

O segundo campo dessa linha de resposta é o TTL em segundos. Depois, verifique os registos que são frequentemente esquecidos: o registo AAAA se o servidor antigo tinha IPv6, o nome www quando é um registo A separado em vez de um CNAME, qualquer registo MX que aponte para o próprio servidor, um registo SPF que liste o IP antigo e o registo de DNS inverso (PTR) no novo endereço. Configure o PTR através do painel de controlo do seu provedor antes da mudança se o servidor enviar correio, porque os servidores de correio de destino verificam esse registo e a ausência de um PTR pode resultar em mensagens rejeitadas horas depois de tudo o resto parecer estar correto.

Verifique o novo servidor pelo respetivo IP antes de alterar o DNS

Pode testar toda a aplicação no novo servidor enquanto o DNS ainda aponta para o servidor antigo. Substitua a resolução do nome numa única requisição:

# your laptop: force one name to the new IP, for this request only
curl -sS --resolve example.com:443:203.0.113.20 \
  -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' https://example.com/

--resolve altera apenas o destino da ligação. O certificado TLS continua a ser validado com base no nome real, por isso este teste confirma tanto o certificado como o serviço. %{ssl_verify_result} imprime 0 quando a cadeia é validada.

Para navegar pelo site num browser, substitua o nome no computador inteiro adicionando uma linha a /etc/hosts no seu portátil ou a C:\Windows\System32\drivers\etc\hosts no Windows:

203.0.113.20 example.com www.example.com

Depois, utilize a aplicação como um utilizador faria. Inicie sessão. Carregue uma página que leia dados da base de dados. Envie um formulário que escreva dados na base de dados. Carregue um ficheiro e confirme que fica guardado no disco. Acione uma função que envie email e confirme a entrega, porque o SMTP de saída a partir de um IP novo costuma causar surpresas. Remova a linha do hosts assim que terminar. Se a deixar no ficheiro, pode passar uma hora a depurar um site que todos os outros utilizadores conseguem ver corretamente.

A mudança, passo a passo

1. Com alguns dias de antecedência: reduza o TTL, execute o rsync em massa, prepare o novo servidor e teste-o através de uma substituição no ficheiro hosts.
2. No dia da mudança, antes da janela: adicione o novo IP a todas as allowlists de terceiros e confirme que a tarefa de backup do novo servidor está configurada e aponta para o seu repositório.
3. Abra a janela: coloque a aplicação em modo de manutenção no servidor antigo para que deixe de aceitar escritas.
4. Faça o dump final da base de dados e execute a passagem final do rsync com --delete.
5. Restaure o dump no novo servidor e inicie os serviços.
6. Teste novamente através de --resolve e da substituição no ficheiro hosts, incluindo uma escrita real.
7. Altere os registos A e AAAA para o novo IP.
8. Monitorize os dois servidores. O access log do servidor antigo mostra quem continua a chegar lá, e o número deverá aproximar-se de zero ao longo do TTL.
9. Remova a página de manutenção.
10. Deixe o servidor antigo em execução e sem alterações durante pelo menos uma semana.

A etapa do modo de manutenção é a que muitas pessoas ignoram. É também a que o protege. Depois de a nova base de dados aceitar uma escrita, reverter a mudança significa perder essa escrita ou fazer um dump da nova base de dados e carregá-lo novamente na antiga. Uma janela de apenas alguns minutos em modo só de leitura tem um custo reduzido. Duas bases de dados que receberam escritas tornam necessária uma reconciliação manual que pode levar dias.

O plano de rollback

O rollback consiste numa ação: alterar novamente os registos DNS para 198.51.100.10. Isto só funciona por causa de quatro medidas que tomou anteriormente.

• O servidor antigo continua em execução, com os serviços ativos e os dados intactos. Parou as escritas nesse servidor, mas não o desativou.
• O TTL continua baixo, por isso o regresso é tão rápido quanto foi a mudança para o novo servidor.
• Adicionou o novo IP às allowlists de terceiros, em vez de substituir o antigo. Se remover o endereço antigo, o rollback falhará no gateway de pagamentos.
• O novo servidor não recebeu escritas que não consiga identificar, porque as únicas escritas realizadas até agora foram as suas próprias transações de teste.

Defina, antes do início da janela, o que desencadeia um rollback. Dois gatilhos são suficientes: qualquer erro que não consiga diagnosticar dentro de um número fixo de minutos e qualquer perda de dados. Registá-los antecipadamente evita a hora de tentativas e incerteza que transforma uma indisponibilidade de dez minutos numa indisponibilidade prolongada.

Comprove que a migração funcionou

A migração não termina quando o site carrega. Verifique os problemas que só surgem mais tarde.

# new server
systemctl --failed
journalctl -p err -b --no-pager | tail -n 40
sudo certbot certificates
sudo systemctl list-timers --all --no-pager

O resultado pretendido é systemctl --failed a indicar 0 loaded units listed. certbot certificates deve apresentar as datas de expiração esperadas, e list-timers deve apresentar todos os jobs agendados do seu inventário com uma hora real da próxima execução, não um valor vazio.

Em seguida, reinicie o novo servidor uma vez, de forma intencional, enquanto acompanha o processo. Um serviço iniciado manualmente e nunca ativado funciona perfeitamente até ao primeiro reboot não planeado às três da manhã.

# new server
sudo reboot

# your laptop, once it comes back
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

Se a aplicação for executada em contentores, a mesma armadilha assume uma forma diferente, porque uma stack do Compose precisa de uma política de reinício explícita para voltar a arrancar depois de um reboot.

A última verificação é a mais fácil de adiar e a mais importante: o job de backup. Uma migração que termina com um servidor sem backup troca um risco por outro. Execute manualmente o backup no novo servidor e, em seguida, restaure um único ficheiro a partir dele para um diretório temporário. Um repositório restic com uma restauração efetivamente testada é a opção que ajuda quando for necessário. Se mantiver os servidores antigo e novo em paralelo durante uma semana, uma forma consistente de aceder e configurar cada host impede que se afastem enquanto ambos estiverem ativos.

Depois da migração: o servidor antigo e os últimos itens

Mantenha o servidor antigo durante uma a duas semanas. Isso custa um mês de um plano que já pretendia cancelar e é o único rollback disponível. Em seguida, conclua os restantes passos.

• Reutilizar o mesmo nome de host no seu ~/.ssh/config para a nova máquina gera WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! na primeira ligação, porque esse nome agora responde com uma chave de host diferente. Remova a entrada antiga com ssh-keygen -R example.com depois de confirmar por que motivo ela mudou, e não de forma automática, porque o mesmo aviso também ocorre num ataque de interceção. Uma migração também é uma boa oportunidade para rever quais chaves podem aceder a quê. É esse o objetivo de gestão de chaves SSH numa pequena frota.
• Faça um último snapshot ou backup do servidor antigo e armazene-o num local que não pertença ao fornecedor antigo.
• Remova o IP antigo das verificações de monitorização, dos registos SPF e das listas de permissões de terceiros, nessa ordem e apenas no fim.
• Cancele o plano antigo apenas depois de confirmar que a última cópia pode ser lida noutro local.

FAQ

Quanto tempo demora a migrar um servidor para um novo VPS?

A indisponibilidade visível para o utilizador costuma limitar-se ao dump final da base de dados, à passagem final do rsync e ao arranque do serviço, ou seja, dez a trinta minutos para uma aplicação pequena. O tempo de calendário é maior, porque o TTL do DNS tem de ser reduzido pelo menos um período equivalente ao TTL anterior antes da mudança; fazê-lo um dia antes é mais seguro. Planeie também a cópia dos dados em massa com alguns dias de antecedência. Esta cópia é executada contra um servidor ativo, e repeti-la mais tarde transfere apenas o que mudou desde a passagem anterior.

Posso usar rsync numa base de dados MySQL ou PostgreSQL em execução em vez de fazer um dump?

Não. O rsync copia ficheiro a ficheiro enquanto a base de dados escreve em vários ficheiros ao mesmo tempo. Por isso, a cópia contém páginas de momentos diferentes e representa um estado que a base de dados nunca teve. Pode recusar-se a iniciar, ou iniciar e falhar mais tarde quando uma consulta aceder a uma página danificada. Use pg_dump com pg_dumpall --globals-only, ou mysqldump --single-transaction, ou pare primeiro a base de dados e copie depois os ficheiros. Num cluster PostgreSQL grande, pg_basebackup cria uma cópia física consistente de um servidor em execução.

Como testo o novo VPS antes de alterar o DNS?

Substitua a resolução do nome na sua própria máquina. Para um único pedido, curl --resolve example.com:443:203.0.113.20 https://example.com/ envia a ligação para o novo IP, mas continua a validar o certificado com o nome real. Para testar no navegador, adicione 203.0.113.20 example.com a /etc/hosts no seu portátil, teste um início de sessão, uma leitura da base de dados, o envio de um formulário e um carregamento de ficheiro, e remova depois a linha. Para inspecionar apenas o certificado, execute openssl s_client -connect 203.0.113.20:443 -servername example.com.

Que TTL devo definir e quando o devo reduzir?

Reduza os registos A e AAAA para 300 segundos e faça-o pelo menos um período completo equivalente ao TTL anterior antes da mudança. Um resolvedor que tenha colocado o registo em cache antes da alteração mantém o valor antigo durante o restante TTL anterior. Por isso, reduzi-lo uma hora antes não produz qualquer efeito se o TTL anterior era 86400. Volte a aumentá-lo para o valor normal alguns dias depois da migração, quando o access log do servidor antigo deixar de registar atividade.

Devo copiar o certificado TLS ou emitir um novo no servidor novo?

Ambas as opções funcionam. Copiar /etc/letsencrypt/ mantém o certificado válido até à data de expiração existente, mas tem de instalar o mesmo plugin autenticador do certbot no servidor novo. Caso contrário, a primeira renovação falha. Execute certbot renew --dry-run depois da mudança do DNS para confirmar. Emitir um certificado novo é mais simples quando pode usar o desafio DNS-01, porque este comprova o controlo através de um registo TXT e funciona antes de o DNS apontar para o servidor novo. O desafio HTTP-01 não pode ser usado no servidor novo enquanto o DNS não tiver sido alterado, porque o pedido de validação chegaria ao servidor antigo.