Atualizar uma VPS Linux para Ubuntu 26.04 ou Debian 13 sem derrubar a produção

O Ubuntu 26.04 LTS foi lançado em abril de 2026 e, desde setembro, a atualização a partir do 24.04 está liberada para todos. O Debian 13 é a versão estável desde agosto de 2025, e o Debian 12 agora só é mantido pela equipe LTS. Veja como levar sua VPS Linux para a nova versão sem transformar uma atualização em queda de produção: panorama, checklist, comandos e plano de rollback.

Onde estão Ubuntu e Debian em outubro de 2026

Dados das notas de versão da Canonical e do calendário LTS do Debian:

Versão	Lançamento	Suporte	A partir de qual versão
Ubuntu 26.04 LTS (Resolute Raccoon)	23 de abril de 2026, point release 26.04.1 em 27 de agosto de 2026	5 anos de atualizações padrão (abril de 2031), 10 anos com o ESM do Ubuntu Pro	somente 24.04 LTS ou 25.10
Ubuntu 24.04 LTS	abril de 2024	suporte padrão até 2029	22.04 LTS
Debian 13 (trixie)	9 de agosto de 2025 (13.7 em setembro de 2026)	equipe de segurança até 9 de agosto de 2028, depois LTS até 30 de junho de 2030	somente Debian 12
Debian 12 (bookworm)	10 de junho de 2023	em LTS desde 11 de junho de 2026, até 30 de junho de 2028	Debian 11

Duas consequências práticas:

Não existe salto direto a partir do Ubuntu 22.04. A Canonical deixa isso claro: primeiro é preciso ir para o 24.04 LTS (ou 25.10), depois para o 26.04. São duas atualizações, com reinicialização e testes entre elas.
O Debian também não pula versões. Só é suportada a atualização a partir da versão anterior: um servidor com Debian 11 vai primeiro para o 12 e depois para o 13.

Não há pressa numa VPS com Ubuntu 24.04, coberta até 2029. Já um servidor com Debian 12 só recebe correções da equipe LTS, com escopo mais restrito: planeje a migração para o Debian 13 com calma, e não às pressas em 2028.

Atualização no lugar ou servidor novo?

Em produção, a atualização no lugar nem sempre é o caminho mais seguro. Você tem duas opções:

Atualização no lugar (do-release-upgrade ou apt full-upgrade): rápida, mantém o IP e a configuração, mas o serviço fica fora do ar durante a operação e o rollback depende de uma restauração.
Nova VPS com 26.04 ou 13 e depois a virada: você migra os dados, testa com calma e muda o DNS. O servidor antigo fica intacto e serve de rollback imediato.

Para um servidor simples, a atualização no lugar resolve se a preparação for séria. Com muitos repositórios de terceiros ou contêineres antigos, uma reinstalação limpa costuma ser menos arriscada.

O checklist antes de mexer na produção

1. Um snapshot E um backup de verdade

O snapshot da VPS, se o seu provedor oferecer, é o jeito mais rápido de voltar atrás: ele congela o disco inteiro. Mas fica na mesma infraestrutura do servidor e não substitui um backup. Faça os dois:

um snapshot logo antes da operação, com os serviços ou pelo menos os bancos de dados parados, para ter um estado consistente;
um backup externo do que importa, fora do servidor: dumps dos bancos, /etc, diretórios dos sites, volumes Docker, crontabs.

# Como root (sudo -i), adapte à sua instalação
mkdir -p /root/backup

# Dumps dos bancos de dados
mysqldump --all-databases --single-transaction > /root/backup/mysql-all.sql
su - postgres -c pg_dumpall > /root/backup/pg-all.sql

# Configuração e pacotes instalados
tar czf /root/backup/etc.tar.gz /etc
dpkg --get-selections '*' > /root/backup/pacotes.txt
apt-mark showmanual > /root/backup/pacotes-manuais.txt

Depois copie /root/backup para outra máquina (rsync, armazenamento de objetos, seu próprio computador). Backup que nunca foi restaurado é só uma hipótese: teste pelo menos um dump.

2. Verificar o cgroup v2 (bloqueante para o Ubuntu 26.04)

É a mudança que mais tem causado estrago este ano. O systemd 259, que vem com o Ubuntu 26.04, não suporta mais o cgroup v1 (hierarquias legacy e hybrid). Segundo as notas de versão da Canonical:

uma instalação Ubuntu rodando cgroup v1 não poderá ser atualizada para o 26.04;
cargas em contêiner do 26.04 não rodam num host iniciado com cgroup v1;
um host com 26.04 não suporta contêineres que exigem cgroup v1, como imagens Ubuntu anteriores ao 18.04.

Ubuntu e Debian usam cgroup v2 por padrão há várias versões, mas alguns servidores foram forçados para v1 para rodar contêineres antigos, versões velhas do Docker ou agentes de monitoramento. Verifique:

stat -fc %T /sys/fs/cgroup/
# cgroup2fs  -> cgroup v2, tudo certo
# tmpfs      -> cgroup v1 ou híbrido, corrija antes de atualizar

grep -o 'systemd.unified_cgroup_hierarchy=[0-9]' /proc/cmdline
grep -n 'cgroup' /etc/default/grub /etc/default/grub.d/* 2>/dev/null

Se sobrou um parâmetro systemd.unified_cgroup_hierarchy=0 na configuração do GRUB, remova-o, rode sudo update-grub, reinicie e confirme que seus contêineres continuam funcionando antes da atualização. No Docker, liste contêineres e imagens com docker ps -a e procure distribuições muito antigas: uma imagem cujo systemd interno é anterior ao cgroup v2 precisa ser substituída, não contornada, porque o systemd 259 não consegue mais iniciar em cgroup v1 e no 26.04 não existe ajuste para voltar a ele.

No Debian 13, o systemd 257 já considera o cgroup v1 obsoleto: a mesma verificação evita uma surpresa desagradável na próxima atualização.

3. Levantar os repositórios de terceiros

Docker, PHP de um repositório externo, Node.js, PPAs diversos: são eles que quebram as atualizações. Liste-os:

ls /etc/apt/sources.list.d/
grep -rhE '^(deb|URIs|Suites)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Para cada um, confirme que ele publica pacotes para a versão de destino (resolute para o Ubuntu 26.04, trixie para o Debian 13). O repositório oficial do Docker, por exemplo, suporta Ubuntu 26.04 e Debian 13. O do-release-upgrade desativa os repositórios de terceiros durante a operação; no Debian, isso fica por sua conta. Em todo caso, anote-os para reativá-los depois.

4. Pacotes retidos

apt-mark showhold

Um pacote essencial em hold faz a atualização falhar. As notas do Debian recomendam remover os holds antes de começar (sudo apt-mark unhold pacote), exceto para um pacote que você mesmo recompilou.

5. Espaço em disco, acesso de emergência e janela de manutenção

Deixe alguns GB livres em / e confira /boot: df -h / /boot. No Debian, apt -o APT::Get::Trivial-Only=true full-upgrade estima o espaço necessário depois que as novas fontes estiverem configuradas.
Localize o console de emergência do seu provedor (console VNC ou equivalente na área do cliente): é ele que salva você se a rede não voltar depois da reinicialização.
Trabalhe dentro do tmux ou screen: se a conexão SSH cair, a atualização continua e você se reconecta à sessão.
Avise seus usuários, reduza antes o TTL dos registros DNS se pretende fazer a virada para outro servidor e escolha um horário tranquilo.

6. Escrever o plano de rollback

Decida antes de começar, não durante: “se os serviços não voltarem em X minutos, restauro o snapshot”. Anote onde fica a restauração, quanto tempo ela leva e o que você perde (tudo o que foi gravado depois do snapshot).

Do Ubuntu 24.04 para o 26.04, passo a passo

Desde o lançamento do 26.04.1, a atualização é oferecida normalmente: a opção -d, que servia para forçá-la antes da liberação oficial, não é mais necessária.

# 1. Deixar o 24.04 totalmente atualizado e reiniciar se um novo kernel foi instalado
sudo apt update && sudo apt full-upgrade
sudo reboot

# 2. Verificar a ferramenta e a política de atualização
sudo apt install update-manager-core
grep Prompt /etc/update-manager/release-upgrades   # deve mostrar Prompt=lts

# 3. Iniciar a atualização dentro do tmux
tmux new -s upgrade
sudo do-release-upgrade

Quando executada via SSH, a ferramenta oferece abrir um segundo serviço SSH em outra porta como reserva; se aceitar, libere essa porta temporariamente no firewall. Nas perguntas sobre arquivos de configuração, na dúvida mantenha sua versão e compare depois com o arquivo .dpkg-dist.

Se você parte do Ubuntu 22.04, o mesmo comando leva ao 24.04. Reinicie, confira os serviços e rode do-release-upgrade de novo para chegar ao 26.04.

O que muda num servidor Ubuntu 26.04

Kernel 7.0 e systemd 259; o 26.04 é a última versão com suporte a scripts System V: migre-os para units do systemd.
sudo-rs substitui o sudo por padrão; o sudo original continua disponível como sudo.ws. Teste scripts e playbooks que usam opções de sudoers pouco comuns.
rust-coreutils agora fornece os utilitários básicos. A Canonical continua oferecendo as ferramentas GNU para os casos de incompatibilidade: teste seus scripts shell.
/tmp em tmpfs por padrão: o que ficava em /tmp agora ocupa RAM e some na reinicialização.
OpenSSH 10.2: chaves DSA não são mais suportadas.
Chrony é o serviço de horário das novas instalações; num servidor atualizado a troca é manual (sudo apt-mark auto systemd-timesyncd e depois sudo apt install chrony).
Apache e mod_php: a unit systemd do Apache ativa MemoryDenyWriteExecute=yes, o que quebra o JIT do PHP com libapache2-mod-php. A Canonical recomenda migrar para php-fpm ou, se não der, sobrescrever a opção com sudo systemctl edit apache2.
PostgreSQL: a Canonical aponta uma regressão de desempenho com o kernel 7.0 e recomenda ativar huge pages.
Versões: PHP 8.5, MySQL 8.4 LTS. Leia as notas de migração das suas aplicações.

Do Debian 12 para o Debian 13, passo a passo

O Debian não tem equivalente ao do-release-upgrade: você troca as fontes do APT e atualiza em duas etapas.

# 1. Atualizar totalmente o Debian 12 (incluindo a correção do OpenSSH para atualizações remotas)
sudo apt update && sudo apt full-upgrade
sudo reboot

As notas de versão alertam que uma sessão SSH interrompida durante a atualização podia deixar o servidor inacessível com o OpenSSH original do bookworm: garanta pelo menos a versão 1:9.2p1-2+deb12u7 (dpkg -l openssh-server) e trabalhe no tmux.

Em seguida, passe as fontes para o formato deb822 recomendado pelo Debian 13: um único arquivo /etc/apt/sources.list.d/debian.sources, removendo o antigo /etc/apt/sources.list.

sudo mv /etc/apt/sources.list /root/backup/sources.list.bookworm
sudo tee /etc/apt/sources.list.d/debian.sources <<'EOF'
Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
EOF

Acrescente contrib ou non-free à linha Components se a configuração antiga os usava. Desative os repositórios de terceiros (renomeie os arquivos para .disabled) e remova as entradas bookworm-backports-sloppy, para as quais o Debian não prevê um caminho de atualização limpo.

# 2. Atualização mínima, depois completa
sudo apt update
sudo apt upgrade --without-new-pkgs
sudo apt full-upgrade

Antes de reiniciar, confira o nome da interface de rede: a passagem para o systemd 257 pode mudar o nome gerado para algumas placas, e uma VPS cuja interface muda de nome volta sem rede. As notas de versão indicam o comando a rodar logo antes da reinicialização:

ip -br link
udevadm test-builtin net_setup_link /sys/class/net/eth0 2>/dev/null | grep ID_NET_NAME

Troque eth0 pelo nome mostrado por ip -br link. Se ID_NET_NAME for diferente do nome atual, ajuste /etc/network/interfaces ou fixe o nome com um arquivo .link do systemd antes de reiniciar. Confirme também que há um metapacote de kernel instalado (dpkg -l 'linux-image*' | grep ^ii | grep -i meta).

Depois da reinicialização, faça a limpeza e converta as fontes restantes:

sudo apt modernize-sources   # converte os arquivos .list restantes para deb822
sudo apt autoremove
apt list '?obsolete'          # pacotes que não vêm mais de nenhum repositório

O Debian 13 também informa que os caminhos de chaveiros em .gpg agora são apenas links de compatibilidade para os arquivos .pgp: terminada a atualização, você pode trocar debian-archive-keyring.gpg por debian-archive-keyring.pgp nas suas fontes.

O que muda num servidor Debian 13

Kernel 6.12, OpenSSH 10.0 (sem chaves DSA), OpenSSL 3.5, PHP 8.4, PostgreSQL 17, MariaDB 11.8, Nginx 1.26, Python 3.13.
/tmp passa a ser tmpfs (até 50% da RAM por padrão), e /tmp e /var/tmp são limpos regularmente: um serviço que guarda arquivos duradouros ali precisa ser mudado de lugar.
i386 deixa de ser uma arquitetura completa: não atualize um servidor de 32 bits.

Depois da reinicialização: as verificações

lsb_release -a               # versão certa?
systemctl --failed           # nenhum serviço com falha?
journalctl -p err -b         # erros desde o boot
ss -tlnp                     # as portas esperadas estão escutando?
stat -fc %T /sys/fs/cgroup/  # cgroup2fs
docker ps -a                 # contêineres de volta?

Depois reative os repositórios de terceiros com o nome da nova versão. Para o Docker, normalmente basta colocar Suites: resolute (Ubuntu 26.04) ou Suites: trixie (Debian 13) em /etc/apt/sources.list.d/docker.sources e rodar sudo apt update && sudo apt full-upgrade. Por fim, teste seus sites e APIs de fora, os cron jobs, os backups automáticos e a renovação dos certificados (sudo certbot renew --dry-run se usar o Certbot).

Se der problema: o rollback

O servidor não responde mais: use o console de emergência do provedor. A causa mais comum é a rede (nome da interface, Netplan) ou o firewall.
Um serviço não sobe: journalctl -u servico -b quase sempre mostra o motivo (opção de configuração removida, módulo PHP ausente, versão do banco de dados).
Não resolveu no prazo que você definiu: restaure o snapshot, coloque o serviço de volta no ar e analise com calma numa cópia. Não existe “downgrade” limpo de uma distribuição: rollback é o snapshot ou o backup.

Perguntas frequentes

Dá para ir direto do Ubuntu 22.04 para o 26.04?

Não. A Canonical exige passar antes pelo 24.04 LTS (ou 25.10). Num servidor, faça duas atualizações seguidas com testes entre elas.

Por que o do-release-upgrade diz que não há nova versão disponível?

Confira Prompt=lts em /etc/update-manager/release-upgrades e se o 24.04 está totalmente atualizado. Lembre também que um sistema rodando cgroup v1 não pode ser atualizado para o 26.04: migre antes para o cgroup v2.

O Debian 12 ainda é seguro em produção?

Ele recebe correções de segurança da equipe LTS até 30 de junho de 2028, mas para um conjunto menor de pacotes. Continua utilizável, mas planeje a migração para o Debian 13.

Meus contêineres Docker antigos vão funcionar no Ubuntu 26.04?

Os que exigem cgroup v1, como imagens Ubuntu anteriores ao 18.04, não. Atualize essas imagens antes da atualização, de preferência num servidor de testes.