Rotina de manutenção: atualizações, logs, temperatura e limpeza

Por que uma rotina, e não "quando der problema"

Um computador de uso pessoal avisa quando algo vai mal: fica lento, trava, mostra um erro na tela. Um servidor sem monitor, guardado no armário, não tem a quem avisar. Ele continua respondendo aos pedidos da rede até o dia em que o disco enche e o backup noturno para de rodar em silêncio, ou até a poeira elevar a temperatura ao ponto de o processador desligar. Manutenção, aqui, é substituir a tela que você não olha por uma lista curta de verificações que você faz.

A boa notícia é que a lista é curta mesmo. Os sistemas Linux de servidor, como o Ubuntu Server instalado em Instalar o Ubuntu Server passo a passo, foram feitos para ficar meses ligados sem intervenção. O que precisa de olho humano cabe em três frequências: semanal (o que muda rápido), mensal (o que degrada devagar) e semestral (o que é físico). Tudo o que está abaixo vale para qualquer distribuição baseada em Debian, incluindo o OpenMediaVault, que faz parte disso pela interface web.

Rotina semanal: cinco minutos

Escolha um dia e um horário fixos (domingo à noite, por exemplo) e conecte por SSH. Os quatro comandos abaixo respondem às quatro perguntas que importam: há correções pendentes, há espaço, há erros e está esquentando.

1. Atualizar o sistema
   Terminal

   sudo apt update
   apt list --upgradable
   sudo apt upgrade

   O primeiro baixa a lista de versões disponíveis; o segundo mostra o que seria atualizado, para você ler antes; o terceiro instala. Leia a lista: se aparecer o pacote do kernel (linux-image-...), o servidor vai pedir reinício; se aparecer algo de que seus serviços dependem (docker, samba), é bom saber que mudou caso algo se comporte diferente depois.
2. Conferir o espaço em disco
   Terminal

   df -h

   Olhe a coluna "Use%" das linhas montadas em / (o sistema) e nos seus discos de dados (como /mnt/dados). Acima de 80% no disco de sistema é hora de investigar; acima de 90%, o sistema pode começar a falhar em operações básicas, como escrever registros. Discos de dados cheios param backups e cópias. O comando sudo du -sh /var/log /var/lib/docker /home/* 2>/dev/null mostra os suspeitos habituais.
3. Ler só os erros desde o último boot
   Terminal

   journalctl -p err -b

   O journalctl lê o registro central do sistema; -p err filtra prioridade "erro" ou pior e -b limita ao boot atual. Uma lista vazia ou com poucas linhas conhecidas é o normal. O que merece atenção: mensagens repetidas sobre o mesmo disco (I/O error, ata, sd), falhas de serviço (Failed to start) e erros de memória. Não é preciso entender cada linha; é preciso notar quando algo novo passa a se repetir.
4. Ver a temperatura
   Terminal

   sudo apt install lm-sensors    # só na primeira vez
   sudo sensors-detect            # só na primeira vez; responda Enter para os padrões
   sensors

   O lm-sensors lê os sensores da placa-mãe e do processador. A saída mostra temperaturas por núcleo e, quando disponível, da placa. O valor importante é o seu normal: anote a temperatura em repouso na primeira semana e compare nas seguintes. Uma subida constante ao longo dos meses, sem mudança de uso, costuma ser poeira ou ventoinha falhando; os limites de cada processador variam, e é o fabricante quem os informa. Para discos, a temperatura vem do SMART, na rotina mensal.

Rotina mensal: discos, backup e limpeza

Uma vez por mês, reserve vinte minutos para o que degrada devagar.

1. Saúde dos discos (SMART)
   Terminal

   sudo apt install smartmontools   # só na primeira vez
   sudo smartctl -H /dev/sda          # saúde geral: PASSED ou FAILED
   sudo smartctl -A /dev/sda          # atributos detalhados

   Repita para cada disco (lsblk lista todos). "PASSED" não garante nada, mas "FAILED" é um aviso para trocar imediatamente. Os atributos que de fato antecipam falhas, e como lê-los, estão em Saúde dos discos: SMART, sinais de falha e quando trocar. Vale também disparar o autoteste longo (sudo smartctl -t long /dev/sda), que roda em segundo plano por algumas horas.
2. Testar uma restauração do backupEscolha um arquivo qualquer do backup e restaure-o em outra pasta. Abra-o. Se não abrir, o backup não existe, por mais que a tarefa agendada diga que rodou. O roteiro completo, com o que registrar, está em Testar e restaurar backups: o passo que todo mundo pula.
3. Limpar o Docker
   Terminal

   docker system df       # quanto o Docker ocupa
   docker image prune     # remove imagens sem uso (pede confirmação)

   Cada atualização de serviço deixa a imagem anterior no disco. Em alguns meses são gigabytes. Evite o docker system prune -a sem entender o que ele apaga: ele remove também imagens de contêineres parados que você talvez queira de volta. O guia Docker para iniciantes explica a relação entre imagens, contêineres e volumes.
   Nunca limpe volumes para "liberar espaço"

   Os comandos docker volume prune e docker system prune --volumes apagam volumes que não estão ligados a um contêiner em execução. Se um serviço estiver parado naquele momento, o volume dele conta como "sem uso" e some junto com o banco de dados, as configurações e tudo o que o serviço guardou. Não há lixeira. Limite a limpeza mensal a docker image prune e, se precisar de espaço de verdade, descubra quem o ocupa antes de apagar qualquer coisa.

4. Limpar pacotes e registros antigos
   Terminal

   sudo apt autoremove
   sudo journalctl --vacuum-time=60d

   O primeiro remove dependências que ficaram órfãs (kernels antigos, principalmente). O segundo descarta registros com mais de 60 dias; o sistema já limita o tamanho total por padrão, mas em discos pequenos isso ajuda.

Rotina semestral: a parte física e a revisão de acessos

Duas vezes por ano, desligue o servidor de propósito (sudo poweroff, espere apagar, tire da tomada) e cuide do que nenhum comando alcança:

• Poeira. Abra o gabinete e limpe ventoinhas, dissipador do processador e filtros com ar comprimido ou pincel macio, segurando as pás da ventoinha para não girarem. Poeira é a causa número um de temperatura subindo e de desligamentos por superaquecimento. Os cuidados ao abrir um computador estão em Limpeza, pasta térmica e preparação física.
• Cabos. Confira se os cabos SATA e de energia dos discos estão firmes. Um cabo SATA meio solto gera erros intermitentes de disco que parecem falha de hardware. Confira também o cabo de rede e a trava do conector.
• Ventoinhas. Ao religar, ouça: ruído de rolamento ou ventoinha parada são sinais de troca. É uma peça barata que protege peças caras.
• Usuários e serviços. De volta ao SSH, liste quem pode entrar e o que está escutando na rede:
  Terminal

  cat /etc/passwd | grep -E "/bin/(bash|sh)$"   # usuários com login no sistema
  sudo ss -tlnp                                  # portas abertas e os programas por trás
  docker ps --format "{{.Names}}\t{{.Ports}}"   # portas publicadas por contêineres

  Cada linha deve ter um motivo que você lembra. Usuário de alguém que não mora mais na casa, serviço que você testou e esqueceu, porta aberta sem dono: remova ou desative. Serviço a menos é superfície de ataque a menos, e esse é o momento de aplicar as revisões de acesso remoto seguro.

Atualizações automáticas com unattended-upgrades

Entre uma semana e outra, correções de segurança podem sair. O pacote unattended-upgrades, que o Ubuntu Server já instala e ativa por padrão, aplica automaticamente as atualizações do repositório de segurança, sem tocar nas demais. É uma boa configuração para casa: você mantém a rotina semanal para as outras atualizações e para ler o que mudou, e o sistema cuida sozinho do que é urgente. Confirme que está ativo e veja o que ele faria:

sudo apt install unattended-upgrades       # no Ubuntu Server já vem; no Debian, instale
sudo dpkg-reconfigure unattended-upgrades  # responda "Yes" para ativar
sudo unattended-upgrade --dry-run -d       # simula e mostra o que seria aplicado

O comportamento é definido em /etc/apt/apt.conf.d/50unattended-upgrades. Duas opções valem a pena conhecer: Unattended-Upgrade::Automatic-Reboot "false"; (o padrão; mantenha assim para que o servidor não reinicie sem você saber) e Unattended-Upgrade::Remove-Unused-Dependencies "true"; (faz o autoremove sozinho). O registro do que foi aplicado fica em /var/log/unattended-upgrades/.

Reinício planejado

Diferente do Windows, o Linux não exige reinício para quase nada. A exceção é o kernel: uma atualização dele só entra em vigor no próximo boot. O sistema avisa com o arquivo /var/run/reboot-required (e, no login por SSH, com a mensagem "System restart required"). Verifique com cat /var/run/reboot-required ou uptime, que mostra há quanto tempo a máquina está ligada.

Planeje o reinício em vez de deixar acontecer: escolha um horário em que ninguém está usando o servidor, avise quem mora com você, confira que nenhum backup está rodando (docker compose ps e ps aux | grep -E "rsync|restic") e então sudo reboot. Dois minutos depois, conecte de novo e confirme que os serviços voltaram (docker ps, systemctl --failed). Um reinício planejado por mês, ou a cada kernel novo, também serve de teste: você descobre em horário cômodo se algum serviço não sobe sozinho, em vez de descobrir depois de uma queda de energia. Se o servidor não voltar, o roteiro está em Solução de problemas comuns.

O diário de manutenção

O hábito que mais ajuda a resolver problemas não é técnico: é anotar. Um arquivo de texto simples (no seu computador, não só no servidor) com uma linha por intervenção: data, o que você fez, o que viu de diferente. "12/03: apt upgrade, atualizou kernel, reiniciei, tudo ok. Temperatura CPU em repouso 42 °C." "20/04: smartctl mostrou 2 setores realocados no sdb; antes era 0." Quando algo falhar daqui a seis meses, esse diário responde às perguntas que você não vai lembrar: quando começou, o que mudou antes, qual era o normal. Ele também é o lugar de registrar o resultado dos testes de restauração, como pede o guia de planejamento de backup.

Erros comuns

Marcar este guia como lido (salvo apenas neste navegador)