Plano de atualizações de segurança automáticas e reinicializações em VPS (2026): como configurar unattended-upgrades, reboot-required e janelas de manutenção

A documentação oficial do Ubuntu Server coloca as atualizações automáticas dentro do gerenciamento de software, e o componente central é o unattended-upgrades. Ele pode instalar atualizações de segurança automaticamente e também pode ser configurado para decidir se limpa automaticamente e se reinicia automaticamente.

Mas essas ações devem ser vistas separadamente:

• Verificar atualizações automaticamente
• Baixar atualizações automaticamente
• Instalar atualizações de segurança automaticamente
• Se é necessário reiniciar após a atualização
• Se realmente reinicia automaticamente
• Se os serviços se recuperam normalmente após a reinicialização

Muitos VPS chegam apenas ao terceiro passo. Os pacotes de segurança são de fato instalados, mas a máquina não é reiniciada e ninguém verifica o serviço web, o banco de dados ou os contêineres Docker. Para um blog pessoal, pode ser apenas um risco pequeno; para um site com pedidos, login e callbacks de pagamento, pode se tornar um incidente em produção.

Primeiro confirme se o pacote está instalado:

dpkg -l unattended-upgrades

Se não estiver instalado, você pode instalá-lo:

sudo apt update
sudo apt install unattended-upgrades

Depois verifique a configuração de atualizações automáticas:

cat /etc/apt/apt.conf.d/20auto-upgrades

Uma configuração comum é semelhante a:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Essas duas linhas significam aproximadamente: atualizar a lista de pacotes todos os dias e executar o unattended-upgrades.

Você também pode confirmar com a saída de configuração do próprio apt:

apt-config dump | grep -E 'APT::Periodic|Unattended-Upgrade'

Se você vir apenas Update-Package-Lists e não vir Unattended-Upgrade, isso pode significar que apenas a lista de pacotes é atualizada automaticamente, e as atualizações de segurança não são instaladas automaticamente.

Os sistemas Ubuntu/Debian atuais geralmente acionam tarefas relacionadas ao apt por meio de timers do systemd. Você pode verificar:

systemctl list-timers | grep apt

Você pode ver:

apt-daily.timer
apt-daily-upgrade.timer

Depois verifique o status específico:

systemctl status apt-daily.timer
systemctl status apt-daily-upgrade.timer

Não fique tranquilo só porque viu o timer ativo. O timer ativo significa apenas que ele será executado conforme o agendamento; não significa que toda atualização terá sucesso.

Verificar os logs é mais confiável:

sudo ls -lh /var/log/unattended-upgrades/
sudo tail -n 80 /var/log/unattended-upgrades/unattended-upgrades.log

Se quiser consultar o histórico relacionado ao apt:

sudo less /var/log/apt/history.log
sudo less /var/log/apt/term.log

Fique atento a informações como failed, kept back, dependency problem ou dpkg interrupted.

Para um VPS comum, prefiro instalar automaticamente as atualizações de segurança em vez de instalar sem supervisão todas as atualizações normais.

Os motivos são práticos:

• As atualizações de segurança geralmente são mais adequadas para automação
• Atualizações de versão normais podem trazer mudanças de configuração
• Mudanças de versão principal em bancos de dados, runtimes de linguagem e serviços web têm mais probabilidade de afetar a aplicação
• Equipes pequenas ou sites pessoais não têm testes de regressão completos

O /etc/apt/apt.conf.d/50unattended-upgrades configura as fontes permitidas para atualizações automáticas. No Ubuntu, o security pocket costuma ser habilitado. Você pode verificar:

sudo grep -n "Allowed-Origins" -A 20 /etc/apt/apt.conf.d/50unattended-upgrades

Não copie um bloco grande da internet sem ler a configuração. Versões diferentes do Ubuntu, se o Ubuntu Pro está habilitado e se existem fontes de terceiros podem fazer a configuração ser diferente.

Meu conselho é:

• Patches de segurança do sistema: podem ser instalados automaticamente
• Repositórios de terceiros: cautela com atualizações automáticas
• Versões principais de bancos de dados: não atualizar sem supervisão
• Aplicações de negócio: seguir seu próprio processo de publicação

As atualizações automáticas servem para reduzir riscos de segurança básicos, não para fazer uma gestão completa de mudanças por você.

No Ubuntu/Debian, a verificação mais direta:

test -f /var/run/reboot-required && cat /var/run/reboot-required

Se existir, normalmente exibe:

*** System restart required ***

Você também pode ver quais pacotes acionaram a necessidade de reinicialização:

cat /var/run/reboot-required.pkgs

Comumente você verá:

linux-base
linux-image-...
libc6

Se o kernel foi atualizado e você quer confirmar qual kernel está em execução no momento:

uname -r
dpkg -l 'linux-image*' | grep '^ii'

Se o novo kernel já está instalado, mas o uname -r ainda é a versão antiga, isso significa que é necessário reiniciar para fazer a troca.

O unattended-upgrades pode ser configurado para reiniciar automaticamente; por exemplo, a opção relevante geralmente se parece com:

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";

Aqui eu não recomendo que todos alterem diretamente para true.

Os riscos da reinicialização automática são concretos:

• Os serviços não iniciam automaticamente após a máquina reiniciar
• Os contêineres Docker não têm uma política de reinicialização configurada
• As regras do firewall são perdidas após a reinicialização
• A recuperação do banco de dados é lenta e o site retorna 502 por um curto período
• Verificações de disco ou manutenção do provedor de nuvem fazem o tempo de inicialização aumentar
• Você está no meio de uma sessão SSH e a máquina reinicia de repente
• Um site pequeno fica sem supervisão e cai por meio dia antes de alguém perceber

Se for um VPS puramente de testes, a reinicialização automática não é problema. Se for um site em produção, prefiro "instalação automática de atualizações de segurança + reinicialização manual/semiautomática em uma janela de manutenção fixa".

Para a maioria dos sites pequenos, eu organizaria assim:

• Verificar e instalar atualizações de segurança automaticamente todos os dias
• Fixar uma janela de manutenção de baixo tráfego toda semana, por exemplo terça-feira às 03:30
• Verificar o /var/run/reboot-required antes da janela de manutenção
• Se for necessário reiniciar, confirmar primeiro os backups, o status dos serviços e o monitoramento
• Executar um conjunto de verificações de integridade após a reinicialização

Uma verificação simples antes da manutenção:

hostnamectl
uptime
systemctl --failed
df -h
df -i
free -m
test -f /var/run/reboot-required && cat /var/run/reboot-required

Se o systemctl --failed já mostrar serviços com falha, não se apresse em reiniciar. Primeiro descubra se os serviços com falha são críticos. Caso contrário, após a reinicialização pode virar "antes apenas um serviço falhava, agora o site inteiro não abre".

Antes de reiniciar o VPS, verifique se os serviços críticos estão enabled:

systemctl is-enabled nginx
systemctl is-enabled mysql
systemctl is-enabled postgresql
systemctl is-enabled docker

Se você usa Docker Compose, confirme a política de reinicialização dos contêineres:

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
docker inspect --format '{{.Name}} {{.HostConfig.RestartPolicy.Name}}' $(docker ps -q)

As políticas comuns incluem:

always
unless-stopped
on-failure

Se o seu site depende totalmente do Docker, mas o Docker não inicia na inicialização, ou os contêineres não têm política de reinicialização, é muito provável que o site não se recupere automaticamente após o VPS reiniciar.

Quando a janela de manutenção chegar, recomenda-se primeiro deixar um registro do estado atual:

date
uptime
systemctl --failed
ss -lntp

Depois reiniciar:

sudo reboot

Se for um VPS remoto, espere de 1 a 3 minutos após a reinicialização antes de conectar novamente via SSH. Provedores de nuvem diferentes, atualizações de kernel diferentes e estados de disco diferentes podem fazer o tempo de inicialização variar.

Ao voltar, verifique primeiro:

uptime
uname -r
systemctl --failed
journalctl -b -p warning --no-pager | tail -n 80

Depois verifique os serviços de negócio:

systemctl status nginx --no-pager
systemctl status docker --no-pager
curl -I https://example.com

Se o site tiver um banco de dados, fila ou cache por trás, verifique também os serviços correspondentes. Não termine só porque o SSH consegue conectar.

Normalmente preparo uma lista de verificação bem simples, mas eficaz:

systemctl --failed
journalctl -b -p err --no-pager
ss -lntp
df -h
df -i
free -m

Para sites web, adicione:

curl -I https://example.com
curl -I https://example.com/login

Nginx:

sudo nginx -t
sudo tail -n 80 /var/log/nginx/error.log

Docker:

docker ps
docker compose ps
docker compose logs --tail 80

Banco de dados:

systemctl status mysql --no-pager
systemctl status postgresql --no-pager

Isso não é para exibir comandos, mas para evitar que "a máquina reiniciou, mas o negócio não se recuperou". O ciclo das atualizações de segurança deve ser: instalar, reiniciar, verificar, registrar.

Alguns VPS realmente não podem ser reiniciados de qualquer jeito, por exemplo quando estão rodando uma campanha, uma migração de dados, tarefas longas, ou quando você temporariamente não tem ninguém de plantão.

Nesse caso, pelo menos três coisas devem ser feitas:

• Registrar o motivo pelo qual a reinicialização é necessária no momento
• Avaliar quais pacotes estão envolvidos
• Combinar um horário de reinicialização claro

Você pode verificar:

cat /var/run/reboot-required.pkgs
apt list --upgradable

Se for uma atualização de segurança do kernel, o risco de não reiniciar por muito tempo será cada vez maior. Você pode adiar por alguns dias, mas não arraste indefinidamente.

Algumas distribuições ou soluções comerciais suportam live patching, que pode aplicar alguns patches de segurança do kernel sem reiniciar. Mas não é uma solução mágica e não substitui todas as reinicializações. Para VPS baratos comuns, o mais confiável continua sendo organizar uma janela de manutenção.

Se você usa a família RHEL, a ideia é a mesma, mas as ferramentas são diferentes.

Comandos comuns:

sudo dnf update --security
sudo needs-restarting -r

O needs-restarting geralmente vem do dnf-utils ou do pacote de ferramentas correspondente. Ele pode determinar se é necessário reiniciar.

Para atualizações automáticas agendadas, verifique o dnf-automatic:

sudo dnf install dnf-automatic
systemctl status dnf-automatic.timer

Os caminhos dos arquivos de configuração variam conforme a distribuição, então não aplique à força a configuração unattended-upgrades do Ubuntu no Rocky/AlmaLinux.

Se você não quer lidar com um processo complexo, pode seguir esta configuração mínima:

Uma vez por semana, em horário de baixo tráfego, execute:

sudo apt update
sudo apt list --upgradable
sudo unattended-upgrade --dry-run --debug

Depois de confirmar que não há anomalias evidentes, deixe o sistema instalar as atualizações de segurança automaticamente, ou execute manualmente:

sudo unattended-upgrade

Se for necessário reiniciar:

test -f /var/run/reboot-required && cat /var/run/reboot-required
cat /var/run/reboot-required.pkgs

Antes de reiniciar:

systemctl --failed
df -h
df -i

Após reiniciar:

uptime
uname -r
systemctl --failed
curl -I https://example.com
journalctl -b -p err --no-pager

Por fim, anote a data, os pacotes atualizados, se houve reinicialização e se houve anomalias. Mesmo que seja apenas em um arquivo Markdown, é melhor do que depender totalmente da memória.

• Confirmado se o unattended-upgrades está instalado
• Confirmado /etc/apt/apt.conf.d/20auto-upgrades
• Verificados apt-daily.timer e apt-daily-upgrade.timer
• Revisados os logs do /var/log/unattended-upgrades/
• O escopo das atualizações automáticas cobre apenas fontes de software adequadas
• Verificado /var/run/reboot-required
• Revisado /var/run/reboot-required.pkgs
• Decidido se a reinicialização automática será habilitada
• Os VPS de produção têm uma janela de manutenção fixa
• Antes de reiniciar, verificados systemctl --failed, disco e memória
• Confirmado que Docker / Nginx / banco de dados iniciam na inicialização
• Após reiniciar, verificados serviços, portas, logs e status HTTP do site
• Cada patch e reinicialização tem um registro simples

O que mais preocupa nas atualizações de segurança de VPS são dois extremos: um é nunca atualizar, e o outro é reiniciar automaticamente sem critério. A abordagem mais confiável é usar a automação para tarefas repetitivas e de baixo risco, e colocar as reinicializações em uma janela de manutenção em que você possa acompanhar a recuperação. Assim, os patches de vulnerabilidade não ficam atrasados por meses, nem o site é reiniciado de madrugada e fica fora do ar sem ninguém saber.