Alternativas à DigitalOcean: preço, rede e backups

O que as alternativas à DigitalOcean realmente mudam

A maioria das alternativas à DigitalOcean muda a fatura, não a máquina. Em qualquer uma delas, obtém uma máquina virtual Linux com um IP público, um disco virtio e acesso root, e o kernel não se importa com o logótipo no painel de controlo. As diferenças que determinam a escolha são o preço por GB de RAM, o volume de transferência incluído e o custo de cada byte acima desse limite, a composição real do disco e quanto da camada acima do sistema operativo será gerido por outra entidade.

Este guia compara esses aspetos, porque um programador pode verificar todos a partir de um terminal ou de uma tabela de preços publicada. Também identifica os casos em que a DigitalOcean é a escolha certa, porque uma comparação que nada admite em contrário é publicidade.

Todos os preços abaixo são preços de tabela publicados, verificados em 5 August 2026. Os valores da DigitalOcean foram verificados novamente em 21 October 2026 e não tinham mudado. Os preços mudam, e mais de um fornecedor apresentado aqui alterou os seus durante 2026. A estrutura de preços muda muito mais lentamente. Por isso, leia primeiro as proporções e o modelo de faturação. Depois, confirme o valor atual na própria página do fornecedor antes de assumir um compromisso.

O preço por GB de RAM é o número a comparar

[
  {
    "provider": "DigitalOcean 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "DigitalOcean 4 GB",
    "ram_gb": 4,
    "monthly_usd": "24.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "ram_gb": 1,
    "monthly_usd": "5.00",
    "usd_per_gb_ram": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Hetzner CX23 4 GB (unavailable Oct 2026)",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

Num mesmo provedor, o preço por GB de RAM varia muito pouco. A DigitalOcean cobra $6.00 por GB no plano de 1 GB e os mesmos $6.00 por GB no plano de 4 GB, que custa $24.00 por mês. Escolher um plano maior no mesmo provedor não oferece desconto, portanto o tamanho do plano não é o fator de decisão. O provedor é.

Akamai, que agora comercializa o que antes era a Linode, cobra $12 e $24 pelos planos partilhados de 2 GB e 4 GB, exatamente o mesmo que a DigitalOcean. O seu plano de entrada é mais barato, a $5.00. Duas empresas praticarem exatamente o mesmo preço é um sinal importante: esse nível é definido com base num concorrente, não no hardware, e continuará a acompanhar esse concorrente.

A diferença aparece nos provedores que constroem os seus próprios datacenters e vendem em euros. Em 5 de agosto de 2026, um Hetzner CX23 oferecia 4 GB de RAM por cerca de $6.49 por mês, ou $1.62 por GB, perto de um quarto do preço da DigitalOcean. Em 21 de outubro de 2026, ainda não é possível encomendá-lo. A Hetzner lista o CX23, assim como todos os outros planos da linha Cost-Optimized, como atualmente indisponíveis, e explica que a linha utiliza hardware mais antigo, pelo que o número de servidores é limitado. A sua página de estado mantém um aviso sobre a disponibilidade limitada de instâncias cloud desde 26 de junho de 2026, e o aviso continuava publicado em 21 de outubro de 2026. Um plano que não pode ser encomendado não tem um preço por GB que valha a pena comparar. Em 6 de outubro de 2026, a Hetzner adicionou o CPX02, um plano Regular Performance com 1 vCPU, 1 GB de RAM e 20 GB de NVMe, como o seu menor servidor partilhado. Em 21 de outubro de 2026, a própria página da Hetzner indicava o preço de €6.49 por mês, sem IVA, nas suas localizações da UE. Isso corresponde a €6.49 por GB de RAM antes de qualquer conversão para dólares, contra $6.00 na DigitalOcean. A mesma página marcava o CPX02, assim como todos os outros planos Regular Performance, como atualmente indisponíveis. Confirme, portanto, se o plano pode ser encomendado na localização pretendida antes de fazer a comparação. Qualquer valor em dólares para a Hetzner é convertido a partir de um preço de tabela em euros, pelo que varia com a taxa de câmbio. A Hetzner também aumentou os preços da cloud durante 2026, por isso os artigos de comparação mais antigos apresentam valores que já não existem.

O preço por GB de RAM não diz nada sobre o CPU que recebe. Uma vCPU partilhada significa que o hypervisor agenda o seu núcleo juntamente com os de outros clientes. A verificação correta é feita num servidor que tenha efetivamente alugado:

vmstat 1 10

Leia a coluna st. Ela contabiliza a percentagem de tempo em que a sua vCPU estava pronta para executar, mas o hypervisor entregou o núcleo físico a outro cliente. Alguns pontos percentuais sob carga são normais. Um valor de dois dígitos mantido durante algum tempo indica que o host está com excesso de subscrição. Nenhum preço por GB compensa um núcleo que não pode utilizar. Execute o teste no seu horário de maior carga, porque o tempo de espera causado por outros clientes é um problema dos vizinhos, e os vizinhos têm horários. Para ter uma visão mais ampla do custo real de um mês de alojamento depois de incluir armazenamento e tráfego, leia quanto custa um VPS mês a mês.

O custo real da transferência incluída

[
  {
    "provider": "DigitalOcean 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "included_tb": 2,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Hetzner CX23 4 GB (unavailable Oct 2026)",
    "included_tb": 20,
    "overage_usd_per_tb": "1.20"
  }
]

A DigitalOcean inclui cerca de 1 TB (1,000 GiB) de transferência de saída no seu plano de 1 GiB por $6.00 e cobra o excesso a $0.01 por GiB, o que corresponde a cerca de $10.00 por cada TB adicional. O seu verdadeiro plano de entrada, com 512 MiB de RAM por $4.00 por mês, inclui apenas 500 GiB. O limite aumenta depois com o tamanho do plano, até 6,000 GiB nos planos Basic maiores. Por isso, consulte o valor correspondente ao plano que escolher. A Akamai inclui o mesmo número de TB no seu Nanode e cobra aproximadamente metade desse valor, cerca de $5.00 por TB. A Vultr inclui 2 TB e aplica uma taxa de excesso semelhante. Em 5 August 2026, o Hetzner CX23 incluía 20 TB e cobrava cerca de $1.20 por TB adicional. Esse valor é uma ordem de grandeza diferente dos restantes. Em 21 October 2026, a página da Hetzner ainda indicava 20 TB de tráfego incluído nas suas localizações na UE, também no CPX02, embora oferecesse muito menos nas localizações de Singapore e dos EUA, onde o CPX02 recebe 0.5 TB em Singapore.

Três detalhes estruturais são mais importantes do que os valores principais. O tráfego de entrada é gratuito nos quatro fornecedores. Apenas os dados enviados para fora são contabilizados. A DigitalOcean, a Akamai e a Vultr partilham o limite entre todos os servidores da conta. Assim, uma máquina com muito tráfego consome a quota das outras, e uma frota de servidores pequenos partilha um único limite grande. Além disso, o tráfego entre servidores através de uma rede privada ou VPC normalmente não é contabilizado. Por isso, colocar a base de dados na interface privada é uma decisão de faturação e também de segurança.

Nada disto é relevante se estiver longe do limite. Um blog, uma API com respostas JSON ou um pequeno serviço SaaS não atingem 1 TB num mês. Vídeo, galerias de imagens, servidores de jogos, mirrors de pacotes e destinos de backup externos atingem. Faça medições antes de assumir:

sudo apt update && sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

vnstat -m apresenta a transferência por mês, separada entre dados recebidos e enviados. Apenas a coluna dos dados enviados é faturada. A base de dados começa vazia. Por isso, a primeira leitura útil surge um dia depois da instalação, e o primeiro mês completo surge um mês mais tarde. Até lá, o gráfico de largura de banda do próprio fornecedor é o único registo disponível.

Faça mais uma pergunta que nenhuma tabela de preços responde: quando ultrapassa o limite, o fornecedor cobra-lhe ou limita a porta? A cobrança custa dinheiro. A limitação afeta os utilizadores, precisamente no momento em que tem mais utilizadores. É importante saber qual dos dois efeitos uma subida repentina do tráfego provoca.

NVMe ou SATA, e como confirmar o que realmente recebeu

O painel indica NVMe. Isso é uma afirmação sobre os discos do host, mas a sua máquina virtual pode não estar alojada nesses discos. O armazenamento local coloca o seu disco virtual em unidades dentro da mesma máquina física. O armazenamento de rede coloca-o num cluster de armazenamento separado, acedido através da rede do datacenter. É isso que permite redimensionamento imediato, migração em tempo real e snapshots no próprio local.

Dentro do guest, ambos parecem idênticos:

lsblk -d -o NAME,ROTA,MODEL,SIZE
cat /sys/block/vda/queue/rotational

ROTA e rotational reportam 0 para tudo o que o host declara como não rotacional. Por isso, um volume de rede suportado por NVMe apresenta exatamente o mesmo resultado que um NVMe local. O valor indica que o disco não usa pratos magnéticos giratórios. Não indica onde o disco está localizado. Confirmar um disco NVMe no Linux explica os nomes dos dispositivos e o que cada um implica.

O teste que os distingue mede a latência com profundidade de fila 1, porque uma leitura pequena e isolada não tem outras operações atrás das quais se possa ocultar. O NVMe local responde a partir do mesmo chassis. Um volume de rede acrescenta uma viagem de ida e volta pela rede do datacenter a cada leitura. Por isso, a sua latência mínima é maior, mesmo quando o débito com uma profundidade de fila elevada parece semelhante.

sudo apt update && sudo apt install -y fio
fio --name=lat --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based --group_reporting
fio --name=iops --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fiotest

A primeira execução apresenta um bloco clat, que mostra a latência de conclusão. Leia a linha do percentil 99 em vez da média, porque a média oculta as paragens que os utilizadores sentem. A segunda execução apresenta IOPS= na linha de resumo. Execute ambos no fornecedor que já utiliza e numa instância de avaliação do fornecedor que está a considerar, no mesmo dia, e compare os seus próprios dois valores. Um valor publicado por qualquer fornecedor foi medido numa máquina que não pode observar. Execute os testes três vezes, também em horários diferentes, porque um host pouco ocupado e um host congestionado produzem resultados diferentes no mesmo plano. Avaliar corretamente um VPS explica o método, e o que significa realmente um VPS com SSD explica os termos de marketing subjacentes.

Regiões: meça a latência, não leia o mapa

Uma lista de regiões é marketing até ser medida. O que o utilizador sente é o tempo de ida e volta entre a sua rede e o servidor. Isso depende da rota seguida pelos pacotes, não da distância no mapa. Um servidor a 300 km, atrás de uma ligação de trânsito congestionada, perde para outro a 1,500 km por um caminho livre.

ping -c 20 203.0.113.10
mtr -rwc 50 203.0.113.10
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} total %{time_total}\n' https://example.com

mtr mostra cada salto com a respetiva perda e latência. Assim, um aumento de 60 ms entre dois saltos identifica a ligação que está a causar o problema, em vez de culpar o destino. Execute-o numa máquina da rede onde estão os seus utilizadores. As rotas entre centros de dados são as melhores rotas da Internet e favorecem igualmente todos os fornecedores.

Há um ponto estrutural que se mantém independentemente das alterações de preço. Um fornecedor com uma única região no seu continente significa que o seu plano de recuperação de desastre consiste em mudar de continente, com a latência daí resultante. Conte as regiões para as quais faria efetivamente failover, não as regiões apresentadas na página.

Snapshots e backups são cobrados à parte

Os complementos de armazenamento são onde um plano barato fica caro. A DigitalOcean cobra $0.06 por GiB por mês pelos snapshots e define o preço dos backups automáticos como uma percentagem do servidor: 20% do preço do plano para backups semanais e 30% para backups diários, com uma opção baseada no uso, cobrada por GiB. Ambos os modelos são defensáveis e falham em sentidos opostos. Um preço percentual acompanha o tamanho do servidor, por isso um servidor grande com um conjunto de dados pequeno paga demasiado. Um preço por GiB acompanha os dados, por isso um servidor pequeno ligado a um volume grande paga demasiado.

Pergunte quanto custa uma restauração e quanto tempo demora, porque o preço de manter um backup é apenas metade menos interessante da questão. Pergunte se destruir o servidor também destrói os respetivos snapshots.

Depois, mantenha uma cópia que o fornecedor não controle. Os snapshots do fornecedor ficam dentro da conta do fornecedor, por isso uma conta perdida, uma falha no pagamento ou uma conta suspensa afeta o servidor e os respetivos backups no mesmo momento. Os backups do restic num armazenamento que controla custam alguns dólares de object storage, podem ser restaurados em qualquer fornecedor e são o que torna uma migração reversível em vez de definitiva.

Quanto da pilha você quer executar

Os provedores estão distribuídos ao longo de um espectro. Num extremo, você aluga uma máquina e executa tudo por conta própria. No outro, você envia um branch do git e nunca vê um servidor. Comparar o preço por GB de RAM só é adequado no primeiro extremo, porque no segundo você está a comprar trabalho, não memória, e o trabalho não tem um preço por GB.

Seja honesto sobre em que extremo está antes de comparar opções. Uma base de dados gerida a $15.15 por mês parece cara ao lado de um servidor de $6, até calcular o custo das horas envolvidas: replicação, failover, restauro para um ponto no tempo, atualizações de versões menores e o alerta que acorda alguém às 03:00. Se esse trabalho é sua responsabilidade, execute-o por conta própria e fique com a diferença. Se sua responsabilidade é a aplicação, comprar esse trabalho de volta é barato. A divisão entre serviços geridos e não geridos determina qual coluna da tabela de preços você deveria sequer consultar. Se a resposta honesta é que você quer a máquina inteira e os respetivos discos só para você, essa é uma questão de VPS versus servidor dedicado, não uma questão sobre o provedor. A mesma questão aparece no restante da fatura mensal de um developer, em que comparar os planos do Claude e do ChatGPT depende de quanto trabalho você quer delegar, e não do preço anunciado.

Onde o DigitalOcean é a escolha certa

O DigitalOcean é vantajoso quando está a comprar a plataforma, e não a máquina virtual.

• Bases de dados geridas. PostgreSQL e MySQL geridos começam nos $15.15 por mês, com 1 GiB de RAM e 10 GiB de armazenamento. O armazenamento adicional é faturado por GiB e os nós standby são cobrados por nó. Criar a mesma fiabilidade por conta própria exige Patroni ou repmgr, um sistema de consenso, um proxy de ligações e um teste de failover que tenha sido realmente ensaiado. Uma equipa de duas pessoas não consegue manter tudo isso e continuar a lançar funcionalidades.
• App Platform. Envie uma branch, obtenha uma compilação, um certificado e um serviço em execução, sem sistema operativo para corrigir. A versão VPS barata deste produto é você, num sábado.
• Armazenamento de objetos e balanceadores de carga abrangidos por um provider Terraform maduro. Uma infraestrutura que pode destruir e reconstruir a partir de código vale mais do que um preço unitário inferior.
• A empresa por trás do produto. Níveis de suporte publicados, uma página de estado com histórico e uma organização que responde ao questionário de segurança de um cliente. Se revende alojamento, isso vale mais do que alguns dólares por GB.

O DigitalOcean fica caro quando se trata de uma máquina virtual simples, em quantidade, com tráfego de saída real. Esse é precisamente o caso que uma alternativa resolve, e representa a maior parte do que um developer de self-hosting compra.

Migrar para um novo provedor sem indisponibilidade

A indisponibilidade durante uma migração ocorre por um único motivo: o tráfego chega ao IP antigo depois de os dados terem sido transferidos para o novo. Cada etapa abaixo existe para tornar essa janela curta e previsível.

Comece pelo DNS, pelo menos 48 horas antes da mudança. Os resolvers armazenam o seu registo A em cache durante o TTL (time to live) definido. Por isso, um registo com TTL de 24 horas pode continuar a enviar utilizadores para o servidor antigo durante até um dia depois de o alterar. Reduzir o TTL no momento da mudança não ajuda, porque os resolvers já têm o valor antigo armazenado com o prazo de expiração antigo. Reduza-o primeiro, aguarde a expiração do valor antigo e só depois faça a migração.

dig +noall +answer example.com A
dig +noall +authority example.com SOA

O primeiro comando mostra o TTL atual na segunda coluna da resposta. Defina-o como 300 no seu provedor de DNS e aguarde mais tempo do que o valor que acabou de substituir.

Depois, siga esta ordem.

1. Provisione o novo servidor e aplique o hardening antes de colocar qualquer outra coisa nele. Os primeiros dez minutos num novo VPS explica a parte que muitas pessoas ignoram quando estão com pressa.
2. Instale a stack da aplicação e faça uma primeira cópia dos dados com rsync enquanto o servidor antigo continua a servir normalmente.
3. Emita já o certificado TLS no novo host, usando um desafio DNS-01, porque um desafio HTTP-01 valida contra o IP para o qual o DNS aponta atualmente, que ainda é o servidor antigo. Um desafio DNS-01 elimina completamente esse problema de ordem.
4. Teste o novo host antes de qualquer alteração pública, substituindo o DNS no seu próprio portátil. Adicione 203.0.113.20 example.com a /etc/hosts, aceda ao site real e depois remova a linha. Nenhum utilizador é afetado por este teste.
5. Avalie o tamanho da base de dados. Para volumes inferiores a alguns GB, um dump e um restore cabem no período de congelamento das escritas. Acima disso, configure a replicação da base de dados antiga para a nova com vários dias de antecedência e deixe-a acompanhar, para que o congelamento cubra apenas a promoção.
6. Congele as escritas. Coloque a aplicação em modo de manutenção ou somente leitura. Esta é a única parte visível para os utilizadores e deve durar apenas alguns minutos.
7. Faça a diferença final: execute novamente o mesmo rsync e depois a sincronização final da base de dados.
8. Altere os registos A e AAAA para o novo IP. Com um TTL de 300 segundos, a maioria dos resolvers seguirá a alteração em cerca de cinco minutos.
9. Mantenha o servidor antigo em execução e acessível durante pelo menos um dia, porque alguns resolvers ignoram TTLs curtos. Se a aplicação antiga ainda aceitar escritas, os pedidos que chegarem atrasados gravarão dados na base de dados errada. Por isso, aponte o host antigo para a nova base de dados ou devolva uma página de manutenção a partir dele.
10. Monitorize a taxa de erros do novo servidor durante um dia, volte a aumentar o TTL para o valor normal e destrua o servidor antigo depois de uma semana, não na mesma noite.

A cópia propriamente dita é feita com dois comandos, executados duas vezes cada. A sincronização dos ficheiros:

rsync -aHAX --numeric-ids --delete -e ssh /srv/ deploy@203.0.113.20:/srv/

-a preserva o proprietário, as permissões e os timestamps, -H mantém os hard links, -AX mantém as ACLs e os atributos estendidos, e --numeric-ids impede o rsync de remapear IDs de utilizador através de nomes que diferem entre duas máquinas. Execute-o com vários dias de antecedência e depois novamente durante o congelamento. Na segunda execução, apenas os dados alterados serão transferidos.

Para PostgreSQL com um tamanho suficientemente pequeno para usar um dump:

pg_dump --format=custom --no-owner --dbname=appdb --file=appdb.dump
scp appdb.dump deploy@203.0.113.20:/var/tmp/
pg_restore --clean --if-exists --no-owner --dbname=appdb /var/tmp/appdb.dump

Para MySQL ou MariaDB:

mysqldump --single-transaction --routines --triggers --databases appdb > appdb.sql

--single-transaction cria o dump dentro de uma única transação nas tabelas InnoDB, pelo que o resultado é consistente e a aplicação continua a aceitar escritas durante a execução. Sem essa flag, mysqldump bloqueia as tabelas. Isso significa que o congelamento das escritas começa mais cedo do que o planeado e deixa de ser uma decisão sua.

Há duas coisas que podem falhar fora dos seus servidores. Um novo endereço IP não tem reputação de email, pelo que as mensagens enviadas diretamente a partir do novo servidor podem ser filtradas como spam. Envie-as através de um relay que já tenha reputação. Além disso, qualquer parceiro que tenha o seu IP de saída numa allowlist, como um gateway de pagamentos ou uma firewall de cliente, tem de ser atualizado antes da mudança. Caso contrário, essas chamadas começarão a falhar assim que o tráfego for transferido.

O que verificar antes de contratar

• Se o plano pode ser efetivamente contratado hoje, na localização pretendida. Um plano marcado como indisponível na tabela de preços não é uma opção, por melhor que pareça o preço por GB.
• Se o preço é promocional e qual será o preço na renovação. Um desconto no primeiro período que duplica na renovação é um custo real, apenas adiado.
• Se o período é pré-pago. Os planos pré-pagos de vários anos, que é assim que a SSD Nodes vende os seus planos, permitem obter um preço muito mais baixo por GB de RAM mediante pagamento antecipado. A contrapartida é não poder cancelar no mês seguinte. Por isso, escolha um período compatível com o seu grau de certeza.
• Quanto custa um snapshot por mês e quanto custa uma restauração, tanto em dinheiro como em minutos.
• Se o excedente é cobrado ou se a velocidade é limitada.
• Se o IPv6 é encaminhado corretamente ou se consiste apenas num endereço adicional configurado de forma limitada.
• Se existe uma API com um provider Terraform mantido, caso pretenda recriar a infraestrutura a partir de código em vez de o fazer manualmente.
• Como contactar o suporte e qual é o tempo de resposta publicado para um servidor indisponível, em vez de para uma questão comercial.

Escolha o critério que mais pesa na sua própria fatura. Se esse critério for a memória, o preço por GB de RAM é decisivo. Se for o tráfego de saída, é o volume de transferência incluído. Se for o seu próprio tempo, a plataforma gerida é o fator decisivo, e a da DigitalOcean é a mais forte das quatro comparadas aqui.

FAQ

O Hetzner é sempre mais barato do que o DigitalOcean?

Para uma máquina virtual simples, era muito mais barato por GB de RAM: cerca de $1.62 contra $6.00 nos planos partilhados pequenos em 5 de agosto de 2026. Esse valor do Hetzner vinha do CX23, que o Hetzner indicava como indisponível em 21 de outubro de 2026, juntamente com o resto da linha Cost-Optimized e o novo CPX02. Por isso, compare com um plano que possa realmente encomendar hoje. A comparação também muda quando entram serviços geridos. O Hetzner vende servidores e rede, por isso uma base de dados gerida ou uma plataforma push-to-deploy tem de ser fornecida por si ou por terceiros, e essas horas têm um custo. O Hetzner também aumentou os preços da cloud durante 2026. Consulte o valor atual em euros em vez de confiar num artigo antigo.

Que alternativa ao DigitalOcean devo escolher se precisar de uma base de dados gerida?

A Vultr e a Akamai vendem bases de dados geridas. Por isso, são as alternativas mais próximas se a base de dados gerida for o motivo principal para usar o DigitalOcean. Os hosts europeus de baixo custo geralmente não vendem esse serviço. Isso significa executar PostgreSQL ou MySQL por sua conta, incluindo a replicação e um failover testado. Esse trabalho tem um custo real. Compare-o com os $15.15 por mês que custa uma instância gerida de 1 GiB antes de concluir que o servidor mais barato lhe permitiu poupar alguma coisa.

Como posso mover um site ativo para um novo fornecedor sem indisponibilidade?

Reduza o TTL do DNS para 300 segundos pelo menos 48 horas antes da migração. Os resolvers continuam a fornecer o IP antigo durante o período indicado pelo TTL anterior. Prepare e teste o novo host enquanto o antigo continua a servir tráfego, usando uma substituição /etc/hosts na sua própria máquina para que mais ninguém a veja. Depois, bloqueie as escritas durante alguns minutos, execute o delta final do rsync e a sincronização final da base de dados, altere os registos A e AAAA e mantenha o servidor antigo em execução durante uma semana. Assim, terá uma margem caso algum resolver ignore o TTL reduzido.

Um VPS mais barato significa discos mais lentos?

Não necessariamente. O que importa é saber se o disco virtual é local ao host ou se está num cluster de armazenamento de rede, algo que o painel raramente indica. lsblk -o NAME,ROTA apresenta 0 para ambos, porque os dois não usam discos rotativos. Faça uma medição: execute fio com --iodepth=1 --bs=4k --direct=1 e leia a latência de conclusão do percentil 99. Um volume de rede acrescenta uma viagem de ida e volta pela rede do datacenter a cada leitura. Por isso, o limite inferior da latência é superior ao de um NVMe local, mesmo quando o débito com filas profundas parece semelhante.

O meu email continuará a ser entregue a partir do novo servidor?

Muitas vezes, não no início. Um endereço IP novo não tem histórico de envio. Por isso, os destinatários consideram suspeitas as mensagens provenientes dele, que podem ir para spam ou ser rejeitadas diretamente. Os registos SPF e DKIM também apontam para o host antigo até serem atualizados. Envie o email da aplicação através de um relay ou de um serviço de email que já tenha reputação. Atualize os registos DNS do email antes da migração, e não depois.