Checklist: como detectar disco cheio antes de derrubar o servidor

16 min de leitura  ·  Guia técnico

Detectar disco cheio antes que impacte os usuários significa monitorar proativamente o uso de espaço em partições críticas do servidor Linux, identificando tendências de crescimento e configurando alertas antes que qualquer serviço falhe. Para executar este checklist completo, siga os passos abaixo:

1. Verifique o uso atual de disco com df -h e identifique partições acima de 80%
2. Audite o consumo por diretório com du -sh /* 2>/dev/null | sort -rh | head -20
3. Verifique o esgotamento de inodes com df -i
4. Identifique arquivos grandes e logs descontrolados em /var/log, /tmp e /home
5. Configure logrotate e limpeza automática de arquivos temporários
6. Implante um script de alerta via cron para notificar quando o disco atingir 80%

Pré-requisitos para executar este checklist de disco cheio

• Acesso SSH com privilégios de root ou sudo ao servidor
• Distribuição Linux compatível: Debian 12, Ubuntu 24.04 LTS, Rocky Linux 9 ou AlmaLinux 9
• Utilitários padrão instalados: df, du, find, logrotate, cron
• Endereço de email configurado no servidor para receber alertas (ou acesso a um webhook)
• Permissão para editar /etc/logrotate.d/ e o crontab do root

Como detectar disco cheio com df e du no Linux

O primeiro passo para detectar disco cheio antes que o servidor trave é obter uma visão geral imediata do uso de espaço em todas as partições montadas. O comando df -h exibe o consumo em formato legível por humanos, mostrando o percentual de uso de cada sistema de arquivos.

1. Conecte-se ao servidor via SSH. Se ainda não configurou acesso seguro, consulte o guia Acessando servidores VPS Linux da AviraHost.
2. Execute o comando de visão geral:

df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        40G   34G  3.2G  92% /
/dev/sda2       100G   61G   35G  64% /home
tmpfs           2.0G  1.1G  900M  56% /run
/dev/sdb1        50G   48G  1.2G  98% /var

Neste exemplo, a partição /var está em 98% — situação crítica. Qualquer serviço que precise gravar em /var (MySQL, Postfix, Nginx) começará a falhar imediatamente.

1. Para identificar quais diretórios consomem mais espaço dentro de uma partição crítica, use du:

du -sh /var/* 2>/dev/null | sort -rh | head -20

18G    /var/log
14G    /var/lib
8.2G   /var/spool
4.1G   /var/cache
1.3G   /var/tmp

1. Para descer um nível e identificar o subdiretório exato:

du -sh /var/log/* 2>/dev/null | sort -rh | head -10

12G    /var/log/mysql
3.1G   /var/log/nginx
1.8G   /var/log/mail.log
900M   /var/log/syslog

Neste caso, os logs do MySQL cresceram sem controle — um sinal claro de que o logrotate não está configurado corretamente para esse serviço.

1. Para encontrar arquivos individuais maiores que 500 MB em todo o sistema:

find / -xdev -type f -size +500M 2>/dev/null | sort

O parâmetro -xdev impede que o find atravesse outros sistemas de arquivos montados, tornando a busca mais precisa e rápida.

Verificar esgotamento de inodes antes que novos arquivos sejam bloqueados

O esgotamento de inodes é uma das causas mais silenciosas de falha em servidores Linux: o sistema reporta espaço livre em bytes, mas nenhum arquivo novo pode ser criado. Isso ocorre com frequência em servidores de email, servidores com muitas sessões PHP ativas ou sistemas com grande volume de arquivos pequenos.

1. Verifique o uso de inodes em todas as partições:

df -i

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      2621440 2619800    1640   99% /
/dev/sda2      6553600  312400 6241200    5% /home
/dev/sdb1      3276800  198000 3078800    6% /var

A partição raiz / está com 99% dos inodes consumidos. Mesmo que ainda haja gigabytes livres em bytes, o sistema não conseguirá criar novos arquivos, diretórios ou links simbólicos.

1. Para identificar qual diretório concentra mais inodes:

find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

1842300  /var/lib/php/sessions
 312400  /tmp
  98200  /home/usuario/public_html/cache

Sessões PHP acumuladas em /var/lib/php/sessions são o culpado mais comum. Cada sessão cria um arquivo separado, e sem limpeza automática elas se acumulam aos milhares.

1. Para contar rapidamente o número de arquivos em um diretório suspeito:

find /var/lib/php/sessions -type f | wc -l

1842287

Atenção: antes de remover arquivos de sessão em massa, certifique-se de que não há usuários ativos na aplicação, pois isso encerrará todas as sessões abertas.

1. Para limpar sessões PHP com mais de 24 horas de forma segura:

find /var/lib/php/sessions -type f -mtime +1 -delete

Identificar logs descontrolados e configurar logrotate corretamente

Logs sem rotação adequada são a principal causa de crescimento inesperado de disco em servidores de produção. O logrotate é a ferramenta nativa do Linux para controlar esse crescimento, mas precisa estar configurado para cada serviço relevante.

1. Verifique se o logrotate está ativo e quando rodou pela última vez:

cat /var/lib/logrotate/status | head -20

logrotate state -- version 2
"/var/log/nginx/access.log" 2025-1-10
"/var/log/mysql/error.log" 2024-11-03
"/var/log/mail.log" 2025-1-10

Observe que o log do MySQL não é rotacionado desde novembro de 2024 — isso explica os 12 GB encontrados anteriormente.

1. Crie ou corrija a configuração de logrotate para o MySQL:

cat /etc/logrotate.d/mysql-server

/var/log/mysql/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        /usr/bin/mysqladmin flush-logs 2>/dev/null || true
    endscript
}

1. Teste a configuração sem executar de fato:

logrotate --debug /etc/logrotate.d/mysql-server

1. Force a rotação imediata para liberar espaço agora:

logrotate --force /etc/logrotate.d/mysql-server

1. Verifique também arquivos de core dump que podem ocupar dezenas de gigabytes:

find /var/crash /tmp /var/core -type f -name "core*" 2>/dev/null | xargs ls -lh 2>/dev/null

Para uma visão completa das práticas de otimização de servidores Linux, incluindo gestão de logs e recursos, consulte as Dicas de Otimização de Servidores Linux.

Configurar alerta automático de disco cheio com script e cron

Monitorar o uso de disco manualmente não é sustentável em produção. A solução mais simples e confiável é um script shell agendado no cron que envia alertas quando o uso ultrapassa o limite seguro de 80%.

1. Crie o script de monitoramento:

cat > /usr/local/bin/check-disk.sh << 'EOF'
#!/bin/bash

THRESHOLD=80
EMAIL="[email protected]"
HOSTNAME=$(hostname -f)

df -h --output=pcent,target | tail -n +2 | while read PERCENT MOUNT; do
    USE=$(echo "$PERCENT" | tr -d '%')
    if [ "$USE" -ge "$THRESHOLD" ]; then
        echo "ALERTA: Disco em $PERCENT em $MOUNT no servidor $HOSTNAME" | \
        mail -s "[DISCO] $HOSTNAME: $MOUNT em $PERCENT" "$EMAIL"
    fi
done
EOF
chmod +x /usr/local/bin/check-disk.sh

1. Teste o script manualmente antes de agendar:

bash /usr/local/bin/check-disk.sh

1. Agende o script para rodar a cada 30 minutos via cron:

crontab -e

*/30 * * * * /usr/local/bin/check-disk.sh

1. Se preferir alertas via webhook (Slack, Discord, n8n), substitua o bloco mail por:

curl -s -X POST "https://hooks.slack.com/services/SEU_WEBHOOK" \
  -H "Content-type: application/json" \
  -d "{\"text\":\"ALERTA: Disco em $PERCENT em $MOUNT no servidor $HOSTNAME\"}"

1. Para monitoramento visual com histórico e dashboards, ferramentas como Zabbix e Netdata oferecem alertas nativos de disco. O artigo Como Configurar Monitoramento Básico de Servidor VPS Linux com Zabbix detalha a configuração completa.

Limpeza segura de espaço em disco sem derrubar serviços

Após identificar os culpados pelo consumo excessivo de espaço, é necessário liberar disco de forma segura, sem interromper serviços em produção. Esta seção cobre as ações mais comuns em ordem de segurança.

1. Limpe o cache de pacotes do sistema (seguro, sem impacto em serviços):

apt clean && apt autoremove -y

No Rocky Linux 9 ou AlmaLinux 9, use:

dnf clean all && dnf autoremove -y

1. Remova kernels antigos que não são mais necessários (Debian/Ubuntu):

dpkg --list | grep linux-image | awk '{ print $2 }' | sort -V | head -n -2

Atenção: nunca remova o kernel atualmente em uso. Confirme qual está ativo com uname -r antes de qualquer remoção.

1. Limpe arquivos temporários com mais de 7 dias:

find /tmp -type f -mtime +7 -delete
find /var/tmp -type f -mtime +7 -delete

1. Identifique e remova backups antigos acumulados:

find /home /root /var/backups -name "*.tar.gz" -mtime +30 -ls

Revise a lista antes de deletar. Para remover após confirmação:

find /home /root /var/backups -name "*.tar.gz" -mtime +30 -delete

1. Verifique a fila do Postfix, que pode acumular gigabytes em servidores de email:

postqueue -p | tail -1

-- 4823 Kbytes in 1247 Requests.

Se a fila estiver com mensagens presas há dias, investigue a causa antes de limpar. Para descartar mensagens com mais de 5 dias:

postsuper -d ALL deferred

Atenção: este comando descarta permanentemente todas as mensagens na fila deferred. Use apenas se tiver certeza de que são mensagens inválidas ou spam.

Problemas comuns e como resolver

Sintoma: df mostra espaço livre, mas serviços falham ao gravar arquivos

Causa: os inodes da partição estão esgotados. O sistema de arquivos Linux mantém um limite de inodes definido na formatação, e quando esse limite é atingido, nenhum novo arquivo pode ser criado mesmo que haja espaço em bytes disponível.
Solução: execute df -i para confirmar o esgotamento. Identifique o diretório com mais arquivos usando find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -10. Os culpados mais comuns são /var/lib/php/sessions, /tmp e diretórios de cache de aplicações. Limpe arquivos antigos com find /var/lib/php/sessions -type f -mtime +1 -delete.

Sintoma: espaço foi liberado mas df ainda mostra partição cheia

Causa: um processo ainda mantém o arquivo deletado aberto. No Linux, quando um arquivo é removido enquanto um processo o mantém aberto, o espaço em disco não é liberado até que o processo feche o descritor de arquivo. Isso é comum com logs de serviços como Nginx, Apache ou MySQL.
Solução: identifique processos com arquivos deletados ainda abertos usando lsof | grep deleted | sort -k7 -rn | head -20. O espaço será liberado ao reiniciar o serviço correspondente. Por exemplo: systemctl restart nginx. Confirme com df -h após o restart.

Sintoma: disco enche rapidamente após limpeza, em menos de 24 horas

Causa: um processo está gerando dados em alta velocidade — pode ser um loop de erro gerando logs massivos, um processo de backup mal configurado gravando no disco local, ou um ataque que está preenchendo o disco com arquivos.
Solução: monitore o crescimento em tempo real com watch -n 5 'df -h && du -sh /var/log/* 2>/dev/null | sort -rh | head -5'. Para identificar qual processo está escrevendo mais: iotop -ao (instale com apt install iotop ou dnf install iotop). Após identificar o processo, verifique seus logs e corrija a causa raiz antes de limpar novamente.

Sintoma: alerta de disco disparado mas partição parece normal após verificação

Causa: o script de alerta pode estar capturando sistemas de arquivos temporários como tmpfs ou overlay (comum em ambientes Docker), que têm comportamento diferente de partições físicas.
Solução: filtre o script para monitorar apenas sistemas de arquivos físicos. Adicione ao script: df -h --type=ext4 --type=xfs --output=pcent,target. Isso exclui tmpfs, devtmpfs e sistemas de arquivos virtuais do monitoramento.

Perguntas frequentes sobre disco cheio no Linux

Como saber se o disco está cheio no Linux antes de travar o servidor?

Execute df -h para ver o percentual de uso de cada partição e du -sh /* 2>/dev/null | sort -rh | head -20 para identificar os diretórios que mais consomem espaço. Quando uma partição atinge 90% ou mais, serviços como MySQL, Postfix e Nginx começam a falhar silenciosamente por não conseguirem gravar logs ou arquivos temporários. O ideal é agir ao atingir 80%, antes que qualquer serviço seja impactado.

Qual o limite seguro de uso de disco em um servidor Linux de produção?

O limite recomendado é 80% de ocupação. Acima disso, o risco de falhas em serviços que precisam gravar em disco aumenta significativamente. Partições críticas como / e /var devem ser monitoradas separadamente, pois /var concentra logs, filas de email e dados de banco de dados. Configure alertas em 80% para ter tempo de agir antes de atingir o limite crítico de 90%.

O que são inodes e por que o disco pode encher mesmo com espaço livre?

Inodes são estruturas de metadados que o sistema de arquivos Linux usa para registrar cada arquivo e diretório. É possível esgotar todos os inodes disponíveis enquanto ainda há espaço em bytes livre, impedindo a criação de novos arquivos. Isso ocorre frequentemente em servidores de email ou com muitos arquivos pequenos de sessão PHP. Verifique com df -i e identifique o diretório problemático com find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -10.

Como configurar um alerta automático quando o disco atingir 80%?

Crie um script shell que execute df -h e compare o percentual com um threshold, enviando email via mail ou notificação via curl para um webhook. Agende o script no cron com crontab -e para rodar a cada 15 ou 30 minutos. Ferramentas como Zabbix e Netdata também oferecem alertas nativos de disco com configuração visual e histórico de tendências, permitindo prever quando o disco será preenchido antes que isso aconteça.

Quais arquivos costumam consumir mais espaço inesperadamente em servidores Linux?

Os principais culpados são logs rotativos mal configurados em /var/log, arquivos de core dump em /var/crash ou /tmp, backups antigos acumulados em /home ou /root, e arquivos temporários de sessão PHP em /tmp ou /var/lib/php/sessions. Em servidores de email, a fila do Postfix em /var/spool/postfix também pode crescer rapidamente quando há problemas de entrega. Audite regularmente com du -sh /var/log/* /var/spool/* /tmp/* 2>/dev/null | sort -rh | head -20.

Conclusão

• Execute o checklist semanalmente: rode df -h e df -i toda semana para monitorar tendências de crescimento antes que qualquer partição ultrapasse 80% de uso.
• Automatize os alertas: implante o script de monitoramento no cron e configure logrotate para todos os serviços críticos — MySQL, Nginx, Apache, Postfix — garantindo que logs nunca cresçam sem controle.
• Aja nos sinais precoces: qualquer partição acima de 80% exige ação imediata de limpeza ou expansão; não espere atingir 95% para investigar, pois nesse ponto serviços já podem estar falhando silenciosamente.

Leia também

• Checklist para Otimização de VPS Linux: 15 Ajustes Essenciais
• Checklist para Migração de Servidor Linux: Guia Completo
• Guia para Configurar Monitoramento de Recursos com Prometheus no VPS Linux

Precisa de ajuda com monitoramento de disco no seu servidor?

Manter o disco sob controle em produção exige infraestrutura confiável e suporte técnico disponível quando você mais precisa. Os planos de VPS da AviraHost incluem painel de controle com métricas de uso de disco e equipe de suporte especializada em Linux para auxiliar em situações críticas.

Conheça os planos de VPS Linux da AviraHost