---
title: "O que está ocupando espaço na VPS: como descobrir e liberar"
description: "Descubra o que enche o disco da VPS com df, du, ncdu e find, limpe journal, apt e Docker e resolva o espaço preso por arquivo apagado ainda aberto."
url: "https://streethosting.com.br/guias/vps/descobrir-o-que-ocupa-espaco-vps"
category: "vps"
slug: "descobrir-o-que-ocupa-espaco-vps"
datePublished: "2026-09-28"
dateModified: "2026-09-28"
author: "Equipe StreetHosting"
difficulty: "iniciante"
language: "pt-BR"
keywords:
  - "o que esta ocupando espaco na vps"
  - "disco cheio vps linux"
  - "du df ncdu linux"
  - "liberar espaco servidor linux"
  - "docker ocupando espaco"
  - "journalctl vacuum"
---

# Disco cheio na VPS: encontrar os arquivos pesados e liberar espaço com segurança

Disco cheio derruba banco de dados, trava atualizações e faz aplicação falhar sem mensagem clara. Veja como achar o culpado em poucos comandos e o que dá para apagar sem quebrar nada.

> **Resposta rápida**
>
> Para descobrir **o que está ocupando espaço na VPS**, rode `df -h` para ver qual sistema de arquivos encheu, `df -i` para os inodes e `sudo du -xh --max-depth=1 / | sort -h` para descer pasta por pasta até o culpado, ou navegue com `ncdu -x /`. Os suspeitos mais comuns são journal, logs, cache do apt, imagens do Docker e backups esquecidos. Se o df acusa disco cheio e o du não acha nada, procure arquivos apagados ainda abertos com `sudo lsof +L1`.

## Comece pelo df: o que encheu

Antes de procurar arquivo, descubra qual sistema de arquivos está cheio e se o problema é espaço ou inodes:

```
df -hT
df -i

Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/vda1      ext4    39G   37G  1.6G  96% /
tmpfs          tmpfs  197M  1.1M  196M   1% /run
/dev/vda15     vfat   105M  6.1M   99M   6% /boot/efi
```

Olhe a linha montada em /, a raiz, onde o problema está em quase todos os casos. As linhas tmpfs ficam em memória e não ocupam disco. Repare que Size menos Used não bate com Avail: o ext4 reserva por padrão cerca de 5% dos blocos para o root, justamente para o sistema conseguir funcionar quando um usuário comum enche o disco.

O df -i mostra os inodes, as entradas que o sistema de arquivos usa para cada arquivo e pasta. Se a coluna IUse% está em 100% com espaço sobrando, o problema são milhões de arquivos pequenos: sessões de PHP, cache de aplicação, fila de email ou pastas de dependências repetidas. Para achar onde estão, conte inodes por pasta em vez de bytes: `sudo du --inodes -x --max-depth=1 / | sort -n`.

Vale agir cedo. Com o disco cheio, o banco de dados para de gravar, aplicações falham ao criar arquivos temporários e atualizações do apt quebram no meio, deixando pacotes pela metade. Se você ainda está tentando entender se a lentidão é disco ou outro recurso, o roteiro completo está em [verificar CPU, RAM, disco e rede no Linux](https://streethosting.com.br/guias/vps/verificar-cpu-ram-disco-rede-linux).

## As pastas pesadas com du e ncdu

O du soma o tamanho de cada pasta. O truque é olhar um nível por vez e descer sempre pela maior:

```
sudo du -xh --max-depth=1 / 2>/dev/null | sort -h
sudo du -xh --max-depth=1 /var 2>/dev/null | sort -h
sudo du -xh --max-depth=1 /var/lib 2>/dev/null | sort -h
```

O `-x` impede o du de entrar em outros sistemas de arquivos, como /proc e discos montados, que só atrapalhariam a conta. O `-h` mostra tamanhos legíveis, o `--max-depth=1` limita a um nível e o sort -h ordena, com a maior pasta por último. O redirecionamento para /dev/null esconde avisos de permissão de pastas virtuais.

Se você vai investigar várias pastas, o ncdu economiza tempo: ele faz a varredura uma vez e deixa você navegar pelo resultado com as setas.

```
sudo apt install -y ncdu
sudo ncdu -x /
```

Enter entra na pasta, a seta para a esquerda volta, a tecla d apaga o item selecionado (depois de pedir confirmação) e q sai. As pastas aparecem ordenadas por tamanho, então o culpado costuma estar no topo.

> **Atenção**
>
> Não apague nada dentro de /var/lib/mysql, /var/lib/postgresql ou /var/lib/docker pelo ncdu ou com rm. Esses diretórios têm estrutura interna controlada pelo próprio programa, e remover arquivos na mão corrompe o banco ou o Docker. A limpeza deles é feita pelos comandos de cada ferramenta, mostrados mais abaixo.

## Arquivos grandes com find

Às vezes o culpado não é uma pasta cheia de coisas pequenas, e sim um arquivo gigante perdido: um dump de banco de 8 GB na pasta do root, um backup compactado que ninguém tirou dali, um log de debug esquecido. O find acha esses arquivos direto:

```
# arquivos acima de 500 MB, do maior para o menor
sudo find / -xdev -type f -size +500M -exec du -h {} + 2>/dev/null | sort -rh | head -n 20

# arquivos acima de 100 MB alterados nos últimos 7 dias
sudo find / -xdev -type f -size +100M -mtime -7 -exec ls -lh {} + 2>/dev/null

# dumps e backups compactados esquecidos
sudo find / -xdev -type f \( -name "*.sql" -o -name "*.sql.gz" -o -name "*.tar.gz" -o -name "*.zip" \) -size +100M -exec du -h {} + 2>/dev/null | sort -rh
```

O `-xdev` faz o mesmo papel do -x do du. O `-size +500M` filtra por tamanho e o `-mtime -7` por data de modificação. Esse segundo comando é o melhor quando o disco encheu de repente: o culpado quase sempre é recente.

## Os suspeitos de sempre

Em VPS de aplicação, o espaço costuma sumir sempre nos mesmos lugares. Confira nesta ordem:

| Onde | O que acumula | Limpeza segura |
| --- | --- | --- |
| /var/log/journal | Journal do systemd, que pode passar de 1 GB | Vacuum por tamanho ou por tempo e limite permanente no journald.conf |
| /var/log | Logs em texto e versões rotacionadas | Apagar os .gz antigos e esvaziar com truncate o log em uso |
| /var/cache/apt | Pacotes .deb baixados nas atualizações | apt clean |
| /boot e /usr/lib/modules | Kernels antigos que ficaram instalados | apt autoremove com purge |
| /var/lib/snapd | Revisões antigas de snaps | Remover revisões desativadas e reter só duas |
| /var/lib/docker | Imagens, containers parados, volumes, cache de build e logs | Comandos prune do próprio Docker |
| /home e /root | Backups, dumps de banco e downloads esquecidos | Mover para fora da VPS e apagar |
| /var/crash | Relatórios de falha de programas | Apagar depois de analisar |
| /var/lib/mysql | Binlogs do MySQL ou MariaDB | PURGE BINARY LOGS e prazo de expiração configurado |

Os comandos de limpeza para os três primeiros grupos e para os snaps:

```
# journal
journalctl --disk-usage
sudo journalctl --vacuum-size=200M
sudo journalctl --vacuum-time=2weeks

# cache do apt e kernels antigos
sudo apt clean
sudo apt autoremove --purge

# snaps: listar revisões desativadas e manter só duas daqui em diante
snap list --all | awk '/disabled/{print $1, $3}'
sudo snap remove NOME_DO_SNAP --revision=NUMERO
sudo snap set system refresh.retain=2
```

O vacuum do journal resolve na hora, mas ele volta a crescer até o limite padrão. Para fixar um teto, defina SystemMaxUse no journald.conf; a configuração, junto com o logrotate para os logs em texto, está em [como analisar logs de uma VPS Linux](https://streethosting.com.br/guias/vps/analisar-logs-vps-linux).

> **Atenção**
>
> Evite comandos como rm em /var/log inteiro ou em /var/cache inteiro. Alguns serviços esperam que as pastas existam, e o Nginx, por exemplo, nem inicia se a pasta de log dele sumir. Apague arquivos, não a estrutura.

## Docker: imagens, volumes e logs

Em VPS que roda aplicações em containers, o Docker é o culpado mais frequente, porque acumula em silêncio. Cada deploy baixa uma imagem nova e a antiga fica lá. O cache de build cresce a cada construção. Containers parados guardam suas camadas. E o log de cada container cresce sem limite na configuração padrão.

```
docker system df
docker system df -v
```

A saída separa Images, Containers, Local Volumes e Build Cache, e a coluna RECLAIMABLE mostra quanto dá para recuperar em cada grupo. Com isso em mãos, limpe por partes:

```
docker container prune   # containers parados
docker image prune -a    # imagens que nenhum container usa
docker builder prune     # cache de build
docker system prune      # containers parados, redes sem uso, imagens órfãs e cache de build
```

Volumes merecem cuidado à parte: é neles que ficam os dados de banco, uploads e configurações dos containers. Liste com docker volume ls, confira a quem cada um pertence e só então remova o que for lixo de verdade. Nunca rode prune de volumes no automático sem saber o que existe ali.

Os logs dos containers ficam em arquivos JSON dentro de /var/lib/docker/containers. Para ver os maiores e impor um limite:

```
sudo sh -c 'du -sh /var/lib/docker/containers/*/*-json.log' | sort -h | tail

# /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

sudo systemctl restart docker
```

O limite vale só para containers criados depois da mudança. Recrie os existentes, por exemplo com `docker compose up -d --force-recreate`, para que eles passem a respeitar os 10 MB por arquivo. Se você está começando com containers, a base está em [instalar Docker no Ubuntu da VPS](https://streethosting.com.br/guias/vps/instalar-docker-ubuntu-vps).

## Arquivo apagado ainda aberto

O caso mais confuso de disco cheio: o df diz 100%, o du soma bem menos e nenhum arquivo grande aparece. A causa mais comum é um arquivo apagado que continua aberto por algum processo. Alguém removeu um log de 10 GB com rm enquanto o serviço ainda escrevia nele; o nome sumiu, mas o Linux só libera os blocos quando o último processo fecha o arquivo.

```
sudo lsof +L1
```

O comando lista arquivos abertos cujo nome não existe mais, marcados como deleted, com o processo (COMMAND e PID), o descritor (FD) e o tamanho. A solução mais limpa é reiniciar o serviço dono do processo com systemctl restart: ao fechar o arquivo, o espaço volta na hora. Se não dá para reiniciar agora, esvazie o arquivo pelo descritor, usando o número da coluna FD sem a letra:

```
# exemplo: PID 1234 e FD 3w na saída do lsof
sudo truncate -s 0 /proc/1234/fd/3
```

Há mais dois motivos para df e du discordarem. Arquivos gravados numa pasta antes de um disco ser montado nela ficam escondidos embaixo da montagem, ocupando espaço sem aparecer. E a reserva de blocos do ext4, citada no começo, entra no Used do df mas não em nenhuma pasta.

> **Dica**
>
> Para nunca cair nessa armadilha de novo, troque o hábito: em vez de apagar um log em uso, esvazie com `sudo truncate -s 0 /caminho/arquivo.log`. O processo continua escrevendo no mesmo arquivo, agora vazio, e o espaço é liberado imediatamente.

## Evitar que o disco encha de novo

Limpar resolve hoje. Estas medidas evitam que você repita o processo no mês que vem:

- [ ] Alerta quando o disco passar de 80% e quando os inodes passarem de 80%
- [ ] Limite do journal definido no journald.conf
- [ ] Regra de logrotate para cada log de aplicação
- [ ] Limite de tamanho de log nos containers Docker
- [ ] Backups enviados para fora da VPS em vez de guardados nela
- [ ] Rotina mensal com apt autoremove e limpeza de imagens antigas do Docker

O item dos backups merece destaque, porque é a forma mais comum de a própria pessoa encher o disco: um script que gera um dump por dia na mesma VPS e nunca apaga nenhum. Além de ocupar espaço, esse backup não protege contra a perda da VPS. O jeito certo, com envio para fora e retenção automática, está em [backup automático com restic e cron](https://streethosting.com.br/guias/vps/automatizar-backup-vps-restic-cron). E para o alerta de disco chegar antes do problema, veja [como monitorar uma VPS 24 horas por dia](https://streethosting.com.br/guias/vps/monitorar-vps-24-horas).

## Quando limpar não basta

Se depois de uma boa limpeza o disco volta a passar de 80% em poucas semanas, os dados estão crescendo de forma legítima: banco de dados, uploads de usuários, mundos de servidor de jogo. Nesse ponto, a resposta é mais disco, não mais faxina.

Nas VPS da StreetHosting, todas com NVMe, o disco cresce junto com o plano: cada degrau traz 10 GB de NVMe para cada GB de RAM, de 20 GB no plano de entrada a 640 GB no maior, nas duas linhas. O upgrade é feito pelo painel, cobra só a diferença proporcional do ciclo e exige um reinício da VM. Depois dele, pode ser preciso crescer a partição e o sistema de arquivos, como mostra [como expandir o disco de uma VPS Linux](https://streethosting.com.br/guias/vps/expandir-disco-vps-linux). Como reduzir disco nem sempre é possível, suba em degraus em vez de pular direto para o maior.

| NVMe | VPS Xeon | VPS Ryzen 9 9950X |
| --- | --- | --- |
| 40 GB | R$ 40,00 (3 vCPU, 4 GB) | R$ 64,00 (2 vCPU, 4 GB) |
| 80 GB | R$ 74,00 (6 vCPU, 8 GB) | R$ 114,00 (4 vCPU, 8 GB) |
| 160 GB | R$ 142,00 (9 vCPU, 16 GB) | R$ 214,00 (6 vCPU, 16 GB) |
| 320 GB | R$ 278,00 (15 vCPU, 32 GB) | R$ 414,00 (10 vCPU, 32 GB) |
| 640 GB | R$ 550,00 (24 vCPU, 64 GB) | R$ 814,00 (14 vCPU, 64 GB) |

Quando o volume de dados passa de 640 GB, a próxima opção são os [servidores dedicados](https://streethosting.com.br/dedicated), com NVMe de 2 TB a partir de R$ 1.489,00 por mês. Para comparar todos os degraus de VPS, com preço mensal e especificação, veja a [página de VPS](https://streethosting.com.br/vps).

## Perguntas frequentes

### Qual comando mostra o espaço em disco no Linux?

O df -h mostra tamanho, uso e espaço livre de cada sistema de arquivos. Para descobrir quais pastas ocupam esse espaço, rode sudo du -xh -d 1 / e desça pela pasta maior, ou navegue de forma interativa com o ncdu.

### Por que o df mostra disco cheio e o du não encontra os arquivos?

Quase sempre é um arquivo apagado que continua aberto por algum processo, como um log removido com rm enquanto o serviço ainda gravava nele. Rode sudo lsof +L1 para achar o processo e reinicie o serviço para liberar o espaço.

### Posso apagar a pasta /var/log inteira?

Não. Alguns serviços, como o Nginx, nem iniciam se a pasta de log deles sumir. Apague só os arquivos rotacionados antigos, esvazie o log em uso com truncate e limite o tamanho do journal pelo parâmetro SystemMaxUse.

### Como liberar o espaço usado pelo Docker?

Veja o que pode ser recuperado com docker system df e use docker image prune, docker builder prune e docker container prune. Cuidado com volumes, que guardam dados de banco. Para os logs dos containers não crescerem sem limite, defina um tamanho máximo de log no daemon.json.

### O que são inodes e por que eles acabam?

Inode é a entrada que o sistema de arquivos usa para cada arquivo e pasta. Milhões de arquivos pequenos, como sessões, cache ou fila de email, podem esgotar os inodes antes do espaço. O df -i mostra o uso, e o erro que aparece é o mesmo de disco cheio.

## Guias relacionados

- [Como expandir o disco de uma VPS Linux depois do upgrade](https://streethosting.com.br/guias/vps/expandir-disco-vps-linux.md)
- [Como analisar logs de uma VPS Linux com journalctl e grep](https://streethosting.com.br/guias/vps/analisar-logs-vps-linux.md)
- [Como instalar Docker no Ubuntu 22.04 ou 24.04 em VPS (guia direto ao ponto)](https://streethosting.com.br/guias/vps/instalar-docker-ubuntu-vps.md)
- [Como configurar backup automático da VPS com restic e cron](https://streethosting.com.br/guias/vps/automatizar-backup-vps-restic-cron.md)
- [Como verificar CPU, RAM, disco e rede no Linux por comando](https://streethosting.com.br/guias/vps/verificar-cpu-ram-disco-rede-linux.md)

## Produtos citados

- https://streethosting.com.br/vps
- https://streethosting.com.br/vps/xeon

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "Disco cheio na VPS: encontrar os arquivos pesados e liberar espaço com segurança",
    "name": "O que está ocupando espaço na VPS: como descobrir e liberar",
    "abstract": "Disco cheio derruba banco de dados, trava atualizações e faz aplicação falhar sem mensagem clara. Veja como achar o culpado em poucos comandos e o que dá para apagar sem quebrar nada.",
    "description": "Descubra o que enche o disco da VPS com df, du, ncdu e find, limpe journal, apt e Docker e resolva o espaço preso por arquivo apagado ainda aberto.",
    "datePublished": "2026-09-28",
    "dateModified": "2026-09-28",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/vps/descobrir-o-que-ocupa-espaco-vps"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Qual comando mostra o espaço em disco no Linux?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "O df -h mostra tamanho, uso e espaço livre de cada sistema de arquivos. Para descobrir quais pastas ocupam esse espaço, rode sudo du -xh -d 1 / e desça pela pasta maior, ou navegue de forma interativa com o ncdu."
        }
      },
      {
        "@type": "Question",
        "name": "Por que o df mostra disco cheio e o du não encontra os arquivos?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Quase sempre é um arquivo apagado que continua aberto por algum processo, como um log removido com rm enquanto o serviço ainda gravava nele. Rode sudo lsof +L1 para achar o processo e reinicie o serviço para liberar o espaço."
        }
      },
      {
        "@type": "Question",
        "name": "Posso apagar a pasta /var/log inteira?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Não. Alguns serviços, como o Nginx, nem iniciam se a pasta de log deles sumir. Apague só os arquivos rotacionados antigos, esvazie o log em uso com truncate e limite o tamanho do journal pelo parâmetro SystemMaxUse."
        }
      },
      {
        "@type": "Question",
        "name": "Como liberar o espaço usado pelo Docker?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Veja o que pode ser recuperado com docker system df e use docker image prune, docker builder prune e docker container prune. Cuidado com volumes, que guardam dados de banco. Para os logs dos containers não crescerem sem limite, defina um tamanho máximo de log no daemon.json."
        }
      },
      {
        "@type": "Question",
        "name": "O que são inodes e por que eles acabam?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Inode é a entrada que o sistema de arquivos usa para cada arquivo e pasta. Milhões de arquivos pequenos, como sessões, cache ou fila de email, podem esgotar os inodes antes do espaço. O df -i mostra o uso, e o erro que aparece é o mesmo de disco cheio."
        }
      }
    ]
  }
]
```