Atualização do servidor sem tempo fora do ar
Um servidor não pode ficar sem atualizações, mas cada atualização traz o risco de derrubar o site. Esse risco se controla com processo: as pequenas correções de segurança são instaladas automaticamente, as grandes mudanças seguem um plano com snapshot, verificação e rollback pronto, e as reinicializações ficam concentradas na janela de manutenção. Veja como organizar isso numa única VPS.
As atualizações de servidor são de dois tipos, e cada uma pede um tratamento diferente. As correções de segurança saem com frequência, mudam pouco e quase nunca quebram algo: o melhor é instalá-las automaticamente no mesmo dia. As atualizações planejadas (uma nova versão do sistema, do PHP, do banco de dados ou do painel) mudam o comportamento dos programas, por isso são preparadas e testadas. Na maioria das vezes, o site sai do ar não pela atualização em si, mas porque uma mudança grande foi aplicada como se fosse pequena.
Atualizações automáticas de segurança
No Ubuntu Server, o pacote unattended-upgrades vem instalado e ativado por padrão: uma vez por dia, ele instala apenas as atualizações de segurança, e as demais origens no arquivo /etc/apt/apt.conf.d/50unattended-upgrades ficam comentadas. A frequência é definida em 20auto-upgrades, e o log é gravado em /var/log/unattended-upgrades/. O Debian usa o mesmo pacote, mas numa instalação mínima ele pode não estar presente; como ativá-lo está descrito na página da Debian Wiki.
No AlmaLinux e em outros sistemas compatíveis com o RHEL, a mesma tarefa fica a cargo do dnf-automatic. Por padrão, ele não instala as atualizações: em /etc/dnf/automatic.conf definem-se upgrade_type = security e apply_updates = yes, e depois se ativa o timer dnf-automatic.timer.
Nenhuma das duas ferramentas reinicia o servidor por padrão. Isso está certo: o servidor não deve reiniciar no horário de pico. Mas também não dá para esquecer a reinicialização: o kernel e as bibliotecas atualizados só passam a valer depois dela. No Ubuntu e no Debian, quem avisa que é preciso reiniciar é o arquivo /run/reboot-required; no AlmaLinux, o comando dnf needs-restarting -r. Vale incluir essa verificação no monitoramento do servidor e fazer a reinicialização em si na janela de manutenção.
Snapshot antes da atualização planejada
Antes de qualquer mudança grande, faça um snapshot do disco no painel do provedor. Ele devolve o servidor ao estado original em minutos se a atualização der errado. Pelo catálogo da accsly.io (novembro de 2026), as condições de backup estão descritas em 1.644 dos 2.247 provedores de VPS, e os snapshots são citados de forma explícita em 318 deles. Se o provedor não faz snapshots, antes da atualização é preciso um backup completo que você já tenha testado com uma restauração.
Duas ressalvas. O snapshot costuma ficar no mesmo lugar que o disco do servidor e não substitui um backup: se o armazenamento falhar, os dois se perdem. Além disso, o snapshot de um banco de dados em funcionamento pode sair inconsistente, por isso antes dele se faz um dump do banco ou se suspende a escrita por alguns instantes. Como montar o backup completo está no artigo Backups de VPS: estratégias e ferramentas, e os planos com espaço para as cópias estão na página VPS para backups.
Blue-green e atualização gradual numa única VPS
Os esquemas sem tempo fora do ar vêm de sistemas grandes, com vários servidores atrás de um balanceador: o blue-green mantém duas cópias completas e passa o tráfego de uma para a outra, e a atualização gradual (rolling) tira os servidores de operação um por vez. Numa única VPS, as mesmas ideias se aplicam à aplicação, embora não ao sistema em si.
- Diretórios de releases. Cada versão do site é publicada num diretório separado, por exemplo
releases/2026-11-07, e o servidor web aponta para o link simbólicocurrent. A nova versão é preparada ao lado (dependências, build, cache) e depois o link é trocado com um único comando. O rollback é apontar o link de volta para o diretório anterior. - Duas instâncias da aplicação. A nova versão sobe em outra porta ou em outro contêiner, passa pela verificação e então o nginx é apontado para ela. Recarregar a configuração do nginx não derruba as conexões: segundo a documentação do nginx, o processo principal primeiro verifica a configuração e, se houver erro, continua com a antiga, e os processos de trabalho antigos terminam de atender os seus clientes. Mesmo assim, rode
nginx -tantes. Como rodar aplicações em contêineres está no artigo Docker em VPS: por onde começar. - Migrações de banco compatíveis. Enquanto as duas versões estão rodando, o banco precisa servir para ambas. Por isso, as mudanças de esquema são divididas em etapas: primeiro se adicionam as novas colunas e tabelas, publica-se o código que as usa, e só no release seguinte se remove o que ficou velho.
Atualizar o próprio sistema para uma nova versão principal sem tempo fora do ar não é possível num único servidor. O mais seguro é subir uma segunda VPS com o sistema novo, transferir o site para ela, testar e trocar o DNS, depois de reduzir com antecedência o tempo de vida dos registros; como fazer isso está no artigo Domínios e DNS para quem tem servidor. Para o segundo servidor, durante a migração, é prático usar cobrança por hora. Como escolher a versão do sistema para que essas migrações sejam mais raras está no artigo Distribuições Linux para servidor: Ubuntu, Debian, AlmaLinux.
Atualização do kernel sem reiniciar
A correção do kernel em tempo real (live patching) fecha vulnerabilidades críticas no kernel em execução, sem reiniciar o servidor. No Ubuntu, isso é o Livepatch, parte da assinatura Ubuntu Pro: para uso pessoal, ele é gratuito em até cinco máquinas. Os sistemas compatíveis com o RHEL têm mecanismos próprios, inclusive serviços comerciais.
A tecnologia tem limites. Só podem ser corrigidas as funções que o kernel consegue rastrear, uma restrição descrita na documentação do kernel Linux, por isso parte das correções chega apenas com um kernel novo. A Canonical diz claramente que o Livepatch não dispensa as reinicializações planejadas, só permite adiá-las até a janela de manutenção. E o mais importante para uma VPS: só a virtualização KVM tem kernel próprio. No OpenVZ e no LXC, o kernel é compartilhado e quem o atualiza é o provedor; mais detalhes no artigo KVM ou OpenVZ: o que escolher.
Janela de manutenção e rollback
A janela de manutenção é um horário escolhido de antemão, com o menor número de visitas, geralmente de madrugada no fuso do público principal, em que reinicializações e mudanças planejadas são permitidas. O horário vem das estatísticas do site, e não de um palpite. Se o site é usado por clientes ou funcionários, eles são avisados com antecedência. A janela não é só sua: o provedor também faz manutenções, e como ele as comunica está no artigo SLA e uptime: o que os provedores prometem.
O plano de rollback é feito antes de começar o trabalho, e não depois que algo quebrou:
- defina de antemão os sinais de falha (erros nos logs, aumento do tempo de resposta, falha na verificação das páginas principais) e o prazo a partir do qual você faz o rollback sem mais tentativas de consertar;
- para o código, aponte o link ou o nginx de volta para o release anterior;
- para os pacotes, o AlmaLinux tem o
dnf history undo, que desfaz a última transação; no Ubuntu e no Debian não há rollback oficial de pacotes, então ali a base é o snapshot; - o snapshot restaura o disco inteiro, e tudo o que foi gravado depois dele (pedidos, mensagens, cadastros) se perde. Por isso, durante uma atualização arriscada, o site é colocado em modo de manutenção ou somente leitura.
Depois da atualização, confira as páginas principais e os logs de erros e compare o tempo de resposta com o habitual. Se você fez um teste de carga antes do lançamento, o mesmo cenário rodado depois de uma atualização grande mostra rapidamente se o site ficou mais lento.