Checklist de manutenção para servidor Linux

O que a manutenção de um servidor Linux realmente significa

A manutenção de um servidor Linux consiste numa lista curta de verificações executadas segundo um calendário fixo, não num projeto sem fim. Todas as semanas, confirme se as atualizações foram instaladas, se há espaço no disco, se algum serviço parou e se o trabalho de backup terminou. Todos os meses, teste uma restauração, verifique a validade dos certificados, audite as contas e as chaves e remova kernels e logs antigos. Uma vez por versão da distribuição, planeje a atualização da versão e faça o reboot que continua a adiar.

A criação do servidor é outro trabalho, e os primeiros dez minutos num novo VPS aborda essa parte. Esta página trata do ano seguinte. Cada item abaixo identifica a falha que evita, porque uma checklist sem consequências é uma checklist que as pessoas deixam de executar silenciosamente.

Os comandos apresentados são ilustrativos e devem ser lidos antes de serem executados. Compare a saída com a do seu próprio servidor, porque um valor saudável de espaço livre ou de quantidade de processos depende da função do servidor. Quando uma verificação varia entre distribuições, o texto informa isso. Os exemplos usam Debian e Ubuntu com apt. Na família RHEL, a ferramenta é dnf e vários caminhos são diferentes.

Como escolher uma cadência de manutenção de servidores Linux que consiga cumprir

As verificações semanais abrangem os elementos que mudam sem intervenção: pacotes, utilização do disco, estado dos serviços e tarefas agendadas. Esses elementos evoluem por si só, por isso uma semana é aproximadamente o período máximo durante o qual pode deixá-los sem verificação.

As verificações mensais abrangem a degradação lenta: certificados próximos da expiração, contas que ninguém removeu, kernels acumulados em /boot e ficheiros de log que ultrapassaram uma regra de rotação que deixou de corresponder. Nenhum destes problemas causa uma falha amanhã. Todos acabam por causar uma falha.

As verificações de release são orientadas pelo calendário. Um release da distribuição é o único item de manutenção com um prazo externo, porque o suporte da versão atual termina, esteja ou não preparado.

Agende a execução num horário fixo: segunda-feira de manhã para a verificação semanal e o primeiro dia do mês para a verificação mensal. Uma checklist executada "quando tiver tempo" não é uma checklist. Quando tiver mais do que algumas máquinas, execute estas tarefas a partir de um único local, em vez de as executar manualmente. Esse é o tema de gerir vários servidores Linux a partir de um único local.

Semanalmente: as atualizações foram realmente instaladas?

Ativar unattended-upgrades não é o mesmo que saber se foi executado. O serviço pode estar mascarado, a configuração pode estar limitada a uma origem que não utiliza e um pacote retido pode impedir todas as execuções seguintes. A instalação está descrita em atualizações de segurança automáticas no Ubuntu. A tarefa semanal confirma se o que foi instalado executou efetivamente o trabalho.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable é a medida mais fiável, porque comunica o estado atual em vez da intenção. As atualizações de segurança que ainda aparecem nessa lista indicam que a automatização não está a funcionar. Por isso, leia o log antes de assumir que a máquina está atualizada. Um pacote fixado com apt-mark hold é ignorado indefinidamente e não comunica nada. Por isso, apt-mark showhold deve fazer parte da mesma verificação.

Isto evita o seguinte problema: executar durante meses um pacote com uma vulnerabilidade conhecida enquanto se acredita que as atualizações são automáticas.

Semanal: margem de espaço em disco e inodes

Um sistema de ficheiros root cheio interrompe componentes que parecem não estar relacionados com o disco. A base de dados recusa escritas, o registo deixa de funcionar, uma atualização de pacotes falha a meio da configuração e, em algumas configurações, não é possível abrir uma nova sessão porque o sistema não consegue escrever os próprios ficheiros.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i é a metade que a maioria das pessoas ignora. Os inodes são estruturas de quantidade fixa que armazenam metadados dos ficheiros, e um sistema de ficheiros pode ficar sem inodes enquanto df -h ainda indica que há gigabytes livres. As escritas falham então com No space left on device, apesar de a saída mostrar espaço disponível. Na primeira vez, isto pode causar uma hora de diagnóstico confuso. Milhões de ficheiros pequenos, resultantes de uma fila de correio bloqueada ou de um diretório de sessões que ninguém limpa, são a causa habitual.

du -xh permanece num único sistema de ficheiros, que é o comportamento pretendido num servidor com bind mounts ou armazenamento anexado. Num host Docker, a resposta costuma estar nas camadas de imagens e nos volumes obsoletos, que podem ser removidos conforme descrito em limpar o uso de disco do Docker numa VPS.

O espaço livre informa sobre a capacidade. O armazenamento subjacente pode falhar segundo o seu próprio ciclo, pelo que esta é uma verificação separada, abordada em monitorizar a saúde do disco numa VPS.

Semanal: o que parou sem o avisar?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Uma unidade que terminou de forma anormal e atingiu o limite de reinícios fica no estado failed e permanece assim, em silêncio. Não receberá nenhuma mensagem sobre isso. list-timers é a parte mais útil: mostra quando cada timer foi executado pela última vez e quando será executado novamente. Assim, um valor de LAST mais antigo do que o próprio intervalo do timer indica que essa tarefa não foi executada.

Leia o journal da unidade antes de a reiniciar, com journalctl -u <unit> -n 100 --no-pager. Um reinício elimina o sintoma e, depois, deixa de ter motivo para verificar novamente até que o mesmo problema ocorra num horário pior.

A falha evitada por esta verificação: um agente de monitorização, um worker de fila ou um serviço de backup que está parado desde um pico de memória ocorrido há três semanas.

Semanalmente: o job de backup terminou realmente?

Um backup agendado e um backup concluído são factos diferentes, e apenas um deles permite restaurar dados. Verifique a conclusão.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

Confirme duas coisas. A última execução terminou com código zero, e o arquivo mais recente é recente e tem aproximadamente o tamanho esperado. Um ficheiro de backup que passa subitamente a ter um décimo do tamanho habitual é um dump que falhou mas que ainda criou um ficheiro. Esta é a forma mais perigosa de falha de backup, porque tudo o que depende dele parece normal.

Se o seu script encaminha um dump para um compressor, adicione set -o pipefail no início. Sem essa opção, o código de saída do pipeline é o do compressor, e o compressor terminou com sucesso: comprimiu a mensagem de erro. O job passa então a indicar sucesso todas as noites, enquanto grava um arquivo pequeno sem dados.

Mensalmente: restaure uma cópia de segurança noutro local

Este é o item que a maioria das pessoas ignora. É também o item que determina se o restante da lista teve alguma utilidade.

Restaure para outra máquina ou para um contentor novo, nunca sobre os dados em produção. Depois, abra o que restaurou e confirme que os dados são válidos. Conte as linhas de uma tabela. Abra um documento. Inicie sessão na aplicação restaurada. Uma extração concluída prova que o arquivo pode ser lido, e nada mais.

As ferramentas de repositório têm os seus próprios mecanismos de verificação: restic check --read-data-subset=5% e borg check --verify-data leem os dados armazenados, e não apenas o índice. Execute-os e trate-os como um teste básico, não como um substituto. A verificação confirma que os bytes sobreviveram. Uma restauração confirma que os bytes são os que a aplicação necessita.

Há dois detalhes que as pessoas aprendem da forma mais difícil. Teste a frase secreta de desencriptação numa máquina que não tenha a chave já carregada num agente, porque uma cópia de segurança que não consegue desencriptar não é uma cópia de segurança. Cronometre também a restauração, porque essa duração corresponde ao seu tempo real de recuperação, e o momento habitual para descobrir isso é durante uma interrupção de serviço.

Mensalmente: que certificados expiram em breve?

A automatização da renovação falha silenciosamente. O temporizador do certbot pode renovar o ficheiro no disco enquanto o servidor Web continua a servir o certificado antigo em memória, porque o deploy hook que recarrega o serviço não foi executado. Por isso, consulte o servidor em execução para saber o que está a servir, a partir de fora do servidor.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

A flag -servername define o SNI (indicação do nome do servidor), necessário em qualquer endereço que aloje mais de um site. Caso contrário, recebe o certificado predefinido em vez do seu. Se o certbot tiver sido instalado a partir de um snap, o temporizador terá outro nome. Nesse caso, procure pela palavra em vez de assumir o nome de uma unidade.

Lembre-se também dos certificados sem qualquer automatização: os de um servidor de correio, de uma VPN ou de uma autoridade de certificação interna. São esses que expiram durante um fim de semana, e os browsers e clientes recusam-nos diretamente em vez de apresentarem um aviso.

Mensal: utilizadores, acesso sudo e chaves SSH

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T apresenta a configuração efetiva depois de todas as ocorrências de Include terem sido combinadas. É essa configuração que o daemon utiliza realmente. As imagens recentes do Ubuntu incluem ficheiros de configuração adicionais em /etc/ssh/sshd_config.d/. Esses ficheiros podem substituir as definições do ficheiro principal. Por isso, ler apenas sshd_config pode indicar o oposto da configuração efetiva. Na família RHEL, o grupo administrativo é wheel e não sudo. Ajuste a linha getent em conformidade.

Depois, leia os próprios ficheiros authorized_keys. O acesso é concedido por chave, não por conta. Por isso, uma chave deixada por um prestador de serviços cujo contrato terminou há seis meses continua a permitir o login. Nenhuma lista de utilizadores a assinalará. As chaves incluem um campo de comentário. Utilize-o e elimine tudo o que não consiga atribuir a uma pessoa.

Para consultar o histórico de logins, journalctl -t sshd --since "30 days ago" | grep -i accepted procura pelo identificador do syslog, e não pelo nome de uma unidade. Isto é importante porque o Ubuntu 24.04 ativa o SSH através de um socket. Cada ligação é então registada numa unidade gerada para essa ligação. Um journalctl -u ssh simples pode não as encontrar.

Mensalmente: kernels antigos e um /boot cheio

/boot é frequentemente uma partição separada, com algumas centenas de megabytes, numa imagem padrão de VPS. Cada atualização do kernel adiciona-lhe uma imagem e um initramfs. Quando fica cheia, a atualização seguinte falha a meio e deixa pacotes por configurar. É uma situação problemática para descobrir inesperadamente a uma sexta-feira.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r primeiro, sempre: identifica o kernel que está a executar agora, e esse kernel tem de permanecer instalado, independentemente do que remover. apt autoremove trata do caso normal em Debian e Ubuntu, porque os kernels são marcados como instalados automaticamente e o kernel atual fica protegido. Os casos especiais, como um kernel instalado manualmente ou um /boot que já esteja suficientemente cheio para bloquear o próprio apt, são abordados em remover kernels antigos no Ubuntu.

Mensalmente: crescimento dos logs e o journal do systemd

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug é uma simulação e não escreve nada, por isso é seguro executá-lo num sistema em produção. Vale a pena executá-lo porque as regras de rotação correspondem aos caminhos: uma aplicação que alterou a localização do log durante uma atualização deixa de estar abrangida pela sua própria regra, e esse ficheiro cresce sem limite até encher o disco.

O journal é limitado pelo systemd, mas com base numa fração do sistema de ficheiros, e não num valor que tenha escolhido. Defina SystemMaxUse= em /etc/systemd/journald.conf e reinicie systemd-journald se quiser estabelecer um limite específico. sudo journalctl --vacuum-time=14d recupera espaço imediatamente e é uma ação única, não uma política; por isso, associe-a à alteração de configuração.

Por release: o reboot que continua a adiar

Um pacote de kernel atualizado no disco não é um kernel em execução. Até ao reboot, a máquina continua a executar o kernel antigo. A aplicação de patches em tempo real, quando disponível, cobre apenas um subconjunto das correções.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

Esse ficheiro de sinalização é uma convenção do Debian e do Ubuntu, criada pelos scripts dos pacotes. Os sistemas da família RHEL não o criam. Neles, a pergunta equivalente é respondida por needs-restarting -r, que vem de dnf-utils. needrestart, instalado por predefinição nas imagens recentes de servidor Ubuntu, verifica a camada abaixo do kernel: lista os processos que continuam a mapear uma biblioteca substituída no disco. Por isso, um OpenSSL corrigido só produz efeito depois de os serviços que o utilizam serem reiniciados.

Agende o reboot em vez de o evitar. Em /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; e Unattended-Upgrade::Automatic-Reboot-Time "03:00";, transfira a decisão para a hora que escolheu. Um reboot planeado também é o único teste para confirmar se o servidor volta a arrancar, porque uma entrada fstab inválida ou um serviço que nunca ativou só se manifesta no boot e em nenhum outro momento.

Planejamento da distribuição por versão

As versões Ubuntu LTS têm cinco anos de suporte padrão, enquanto as versões intermédias têm nove meses. Por isso, esta escolha define a carga de trabalho de atualização durante vários anos. Essa diferença é explicada em versões LTS e intermédias num servidor.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade lê esse ficheiro, e Prompt=lts restringe a operação a atualizações entre versões LTS. O caminho entre versões LTS normalmente fica disponível a partir do primeiro point release da nova versão, e não no dia do lançamento. Por isso, confirme qual é a versão disponibilizada para a sua máquina, em vez de planear com base numa data presumida. O processo da atualização é descrito em atualizar o Ubuntu 24.04 para 26.04.

Planeie uma margem de três meses. Crie um snapshot e teste a respetiva restauração, liste os repositórios apt de terceiros (a atualização desativa-os, e cada um precisa de um novo destino para a nova versão) e defina o rollback antes de começar. Em agosto de 2026, o Ubuntu 24.04 LTS terá suporte padrão até abril de 2029. Portanto, trata-se de um planeamento, não de uma emergência.

O que automatizar e o que manter manual

Automatize as decisões que já tomou: atualizações de segurança, rotação de logs, renovação de certificados e tarefas de backup. Automatize também os alertas, porque uma verificação que depende de se lembrar dela não será executada às 2am. Um monitor externo, como monitorização de estado autoalojada com Uptime Kuma, deteta a única situação que nenhum script no próprio servidor consegue comunicar: o servidor estar inacessível.

Mantenha duas tarefas manuais: o teste de restauração e a auditoria de contas. Ambas exigem que uma pessoa decida se o resultado está correto. Se preferir consultar o estado do sistema num navegador em vez de usar um terminal, Cockpit versus Webmin para gestão de servidores compara as duas consolas web habituais.

A automatização também precisa da sua própria verificação. Por isso, o primeiro item semanal desta lista é confirmar o atualizador. Uma automatização que falha silenciosamente é pior do que não ter automatização, porque elimina simultaneamente a indicação da falha e o hábito de verificar.

A checklist completa num só lugar

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

Com que frequência devo executar a manutenção de um servidor Linux?

Semanalmente para tudo o que muda por si só: estado das atualizações, espaço disponível em disco e inodes, unidades que falharam e confirmação de que o trabalho de backup terminou. Mensalmente para a degradação lenta: um teste de restauração, a validade dos certificados, a auditoria das contas e das chaves SSH, kernels antigos e o crescimento dos logs. Uma vez por lançamento da distribuição para atualizar a versão e reiniciar com o kernel atual. A verificação semanal demora alguns minutos num servidor saudável. Esse é o motivo para a executar semanalmente, em vez de esperar até algo parecer errado.

Por que devo testar uma restauração se o trabalho de backup indica sucesso?

Porque o trabalho informa o seu próprio código de saída, e esse código pode indicar sucesso enquanto o arquivo é inútil. Um dump encaminhado para um compressor sem set -o pipefail devolve o estado do compressor. Assim, um dump que falhou, mas produziu apenas uma mensagem de erro, ainda termina com código zero e grava um ficheiro pequeno. Restaure os dados noutra máquina, abra-os e conte alguma coisa. A restauração também mede o próprio tempo, e essa duração é o seu tempo real de recuperação.

Tenho de reiniciar depois de cada atualização do kernel?

Tem de reiniciar antes de o novo kernel passar a ser o kernel em execução. No Debian e no Ubuntu, a presença de /var/run/reboot-required indica que um pacote o solicitou, e /var/run/reboot-required.pkgs identifica qual. Na família RHEL, esse ficheiro não existe, e needs-restarting -r de dnf-utils responde à mesma pergunta. Configure uma janela de reinício automático em /etc/apt/apt.conf.d/50unattended-upgrades em vez de o adiar indefinidamente, porque uma máquina que não é reiniciada há um ano tem um caminho de arranque não testado, além de um kernel antigo.

Quais destas verificações posso automatizar com segurança?

Automatize as ações cuja decisão já está definida: atualizações de segurança, rotação de logs, renovação de certificados e backups agendados. Automatize também as notificações, para que uma unidade que falhou ou um disco que está a ficar cheio chegue ao seu conhecimento sem alguém ter de executar um comando. Mantenha o teste de restauração e a auditoria das chaves como tarefas manuais, porque cada uma exige que alguém avalie se o resultado está correto. Depois, adicione uma verificação da própria automação, pois uma falha silenciosa do atualizador parece exatamente um funcionamento normal.