> For the complete documentation index, see [llms.txt](https://ajuda.zdg.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ajuda.zdg.com.br/avancado-recursos-tecnicos/como-liberar-espaco-em-disco-na-vps-do-z-pro.md).

# Como liberar espaço em disco na VPS do Z-PRO

Quando a VPS está com o disco cheio (ou perto disso), o sistema pode ficar lento, travar o login ou até derrubar o backend. Este guia mostra como diagnosticar o que está ocupando espaço e como liberá-lo com segurança, cobrindo tanto a limpeza pelo terminal quanto pelo painel administrativo do Z-PRO.

{% hint style="info" %}
**Pré-requisitos:**

* Acesso root/sudo à VPS via SSH (para os comandos de terminal).
* Acesso **Super Admin** no painel (para a limpeza de dados por tenant).
* Recomendado: um snapshot/backup da VPS antes de rodar comandos de remoção.
  {% endhint %}

### Vídeo tutorial

{% embed url="<https://www.loom.com/share/c6c8d74faf834eda93f4527d9079b10f>" %}

***

### Como funciona

Espaço em disco ocupado no Z-PRO normalmente vem de três frentes: **mídias acumuladas** por tenant (pasta `public` do backend), **pastas de backup** deixadas por atualizações, e **logs do sistema** (PM2, journal, npm). As duas primeiras costumam ser as maiores — vale sempre começar por elas.

{% hint style="warning" %}
Antes de rodar qualquer comando de remoção (`rm -rf`), confirme o caminho completo. Um comando errado pode apagar pastas em uso — sempre prefira digitar o caminho exato em vez de um curinga solto (ex.: `frontend.*`).
{% endhint %}

***

### Etapa 1: Diagnóstico geral do disco

No terminal da VPS, os dois comandos essenciais são:

```bash
df -h    # espaço usado/livre por partição
df -i    # se o espaço parecer OK mas o erro persistir, cheque esgotamento de inodes
```

Se alguma partição estiver perto de 100% em "Use%", é hora de investigar o que está ocupando esse espaço.

***

### Etapa 2: Encontrar os maiores arquivos e pastas

Para listar as maiores pastas dentro do diretório da instalação, ordenadas da maior para a menor:

```bash
sudo du -h --max-depth=1 /home/deployzdg | sort -rh | head -20
```

Para listar os maiores arquivos individuais em toda a VPS (top 20):

```bash
sudo du -ah / 2>/dev/null | sort -rh | head -n 20
```

{% hint style="info" %}
Se algum volume externo (ex.: um HD separado usado só para backup) aparecer nessa lista, normalmente não faz parte do disco principal do sistema e pode ser desconsiderado da análise.
{% endhint %}

No caso do Z-PRO, o maior consumo costuma estar na **pasta `public` do backend**, onde ficam as mídias recebidas/enviadas por todos os tenants. É possível ver o consumo por tenant (pela pasta correspondente ao ID) para identificar qual cliente está usando mais espaço.

***

### Etapa 3: Limpar mídias por tenant (painel Super Admin)

Em vez de mexer direto nos arquivos pelo terminal, o painel permite sanitizar os dados de um tenant específico:

1. Acesse **Superadmin → Tenants e Licenciamento → Tenants**.
2. Localize o tenant identificado na Etapa 2 e clique no menu de **três pontos** ao lado dele.
3. Use **Calcular tamanho dos dados** para confirmar o quanto aquele tenant está ocupando.
4. Use **Limpeza por filtro** para remover mensagens/mídias antigas — é possível filtrar por:
   * Apenas por **tempo** (ex.: tudo com mais de 60 dias).
   * Apenas por **tamanho** (ex.: tudo acima de 200 MB).
   * Ou pelos dois critérios combinados.
5. Para remover todas as mídias já armazenadas daquele tenant, use **Apagar arquivos da empresa**.

{% hint style="danger" %}
**Importante:** confirme o tenant certo antes de aplicar a limpeza — a ação remove dados permanentemente e não pode ser desfeita.
{% endhint %}

***

### Etapa 4: Limpar pastas de backup deixadas por atualizações

Toda atualização feita pelo autoinstalador cria uma pasta de backup (padrão de nome `frontend.bak.<timestamp>` / `backend.bak.<timestamp>`) como segurança — se a atualização falhar, o autoinstalador consegue reverter para essa cópia. Depois de confirmar que uma atualização funcionou, essas pastas só ocupam espaço e podem ser removidas.

```bash
cd /home/deployzdg/zpro.io
ls -la                              # identifique as pastas de backup pelo nome completo
rm -rf frontend.bak.1720000000      # apague pelo nome exato, uma de cada vez
```

{% hint style="danger" %}
**Nunca** use um curinga solto como `rm -rf frontend.*` — isso pode remover também a pasta `frontend` em produção. Sempre digite (ou copie) o nome completo da pasta de backup.
{% endhint %}

Se você tem uma **instalação secundária** (multi-servidor), confira também lá — as pastas de backup são geradas a cada atualização em cada instalação.

***

### Etapa 5: Limpar logs do sistema

**Logs do PM2** (processos do Z-PRO):

```bash
pm2 flush
```

**Cache do npm:**

```bash
npm cache clean --force
```

**Logs do sistema (journal):**

```bash
journalctl --disk-usage           # veja quanto espaço o journal está ocupando
sudo journalctl --vacuum-size=500M   # reduz o journal para até 500 MB
```

{% hint style="info" %}
Os logs ajudam a diagnosticar problemas caso algo dê errado depois — evite apagá-los por completo. Uma rotina de limpeza semanal (reduzindo para um tamanho como 500 MB) é suficiente para manter o disco sob controle sem perder o histórico recente.
{% endhint %}

***

### Alternativa definitiva: Storage externo (S3)

Se o disco enche recorrentemente por causa de mídias, a solução definitiva é mover o armazenamento para um provedor externo (AWS, Cloudflare R2, Wasabi, MinIO), em vez de ficar sanitizando manualmente. Veja o guia completo: Storage S3.

Se tiver dúvidas de como configurar seu tipo específico de storage, abra um chamado no suporte com os detalhes do que já tentou — a equipe orienta o restante.

***

### Resumo das Funcionalidades

| Funcionalidade                          | Onde acessar                                                                                 |
| --------------------------------------- | -------------------------------------------------------------------------------------------- |
| Diagnóstico geral de disco              | Terminal SSH — `df -h`                                                                       |
| Maiores arquivos/pastas                 | Terminal SSH — `du`                                                                          |
| Limpar mídias de um tenant              | Superadmin → Tenants → menu de três pontos → Limpeza por filtro / Apagar arquivos da empresa |
| Limpar pastas de backup pós-atualização | Terminal SSH — pasta da instalação (`frontend.bak.*` / `backend.bak.*`)                      |
| Limpar logs do PM2                      | Terminal SSH — `pm2 flush`                                                                   |
| Limpar logs do sistema (journal)        | Terminal SSH — `journalctl --vacuum-size`                                                    |
| Solução definitiva para mídias          | Superadmin → Sistema → Storage S3                                                            |

***

### Encerramento

Com o disco liberado, o servidor volta a operar normalmente — sem risco de travar o recebimento de mídias grandes ou interromper o backup noturno. Repetir esse checklist periodicamente (ou migrar para Storage S3) evita que o problema volte a se acumular.

***

### Possíveis Erros e Soluções

#### O disco voltou a encher pouco tempo depois da limpeza

**Causa:** o que ocupa o disco é mídia acumulada em uso ativo, não backup ou log. **Solução:** migre o armazenamento para Storage S3 em vez de sanitizar manualmente com frequência.

#### Apaguei a pasta errada por engano com um curinga (`rm -rf frontend.*`)

**Causa:** curinga solto pegou também a pasta em produção, não só a de backup. **Solução:** restaure a partir do backup/snapshot da VPS — por isso a recomendação de snapshot antes de qualquer remoção em massa.

#### `df -h` mostra espaço livre, mas o sistema ainda acusa disco cheio

**Causa:** esgotamento de **inodes**, não de espaço em bytes. **Solução:** rode `df -i` para confirmar e localize diretórios com excesso de arquivos pequenos (ex.: muitos arquivos de sessão/cache).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ajuda.zdg.com.br/avancado-recursos-tecnicos/como-liberar-espaco-em-disco-na-vps-do-z-pro.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
