Disk full в n8n: runbook очистки и восстановления ¶

Обновлено: 2026-05-29

Intent: runbook disk full: n8n, Postgres, binary data, logs, Docker volumes, безопасная очистка диска
H1: Disk full в n8n: как восстановить self-hosted инстанс без потери данных
Schema: TechArticle, HowTo, FAQPage, BreadcrumbList
Old word count: 656
New word count: 747

Короткий ответ ¶

Если на сервере n8n закончился диск, не начинайте с удаления случайных Docker volumes. Сначала выясните, что заняло место: Postgres, binary data, logs, Docker images, backups или временные файлы. Затем освободите безопасный минимум, чтобы база и n8n снова могли писать данные, а уже потом настройте retention, log rotation, pruning и мониторинг. Самая опасная ошибка — удалить volume с Postgres или папку .n8n, пытаясь быстро «почистить Docker».

Симптомы ¶

Disk full редко выглядит как одна понятная ошибка. Чаще появляется набор странных проблем:

• n8n UI открывается, но workflow не сохраняется;
• executions падают без понятной причины;
• Postgres пишет No space left on device;
• Docker не может создать контейнер или записать layer;
• webhook отвечает 500;
• бинарные файлы не сохраняются;
• backup не создаётся;
• логи перестают писаться или сервисы перезапускаются.

Если сервер обслуживает ещё и reverse proxy, Redis, мониторинг и backup-agent, симптомы могут появляться сразу в нескольких местах.

1. Сначала понять, где закончилось место ¶

Проверьте общий диск и inode:

df -h
df -ih

Если свободные гигабайты есть, но закончились inode, проблема может быть в огромном количестве мелких файлов: logs, temp, binary data, backups.

Найдите крупные директории:

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

Для compose-проекта полезно проверить volumes:

docker system df
docker volume ls

Не удаляйте volumes, пока не знаете, где Postgres, n8n user data и binary data.

2. Быстро освободить безопасный минимум ¶

Цель первого этапа — вернуть системе возможность писать. Обычно достаточно освободить 1–5 ГБ, чтобы сервисы перестали падать и можно было спокойно разбираться.

Относительно безопасные кандидаты:

• старые compressed logs в /var/log, если они не нужны для расследования;
• старые Docker images, которые не используются;
• старые build cache;
• временные файлы;
• дубли backup-архивов, которые уже скопированы во внешнее хранилище.

Команды требуют осторожности:

docker image prune
# только если понимаете последствия:
docker builder prune

Избегайте команд вида docker system prune -a --volumes на production без плана. Флаг --volumes может удалить данные, которые вы считали постоянными.

3. Проверить Postgres и n8n после очистки ¶

После освобождения места не считайте инцидент закрытым. База могла не записать часть транзакций, n8n мог оборвать executions, backup мог оказаться пустым.

Проверьте:

• Postgres container running;
• n8n может сохранить тестовый workflow или настройку;
• новые executions создаются;
• failed executions за период инцидента;
• последние backup-файлы не нулевого размера;
• disk usage не возвращается к 100% за минуты.

Для Postgres-подхода важно не делать агрессивный VACUUM FULL в панике. Он может требовать дополнительное место и блокировки. Сначала восстановите нормальную работу, затем планируйте maintenance.

4. Найти реальный источник роста ¶

После стабилизации разберите причину. У n8n часто растут четыре зоны.

Если сайт обрабатывает файлы, изображения, PDF или выгрузки из CRM, binary data может расти быстрее execution logs.

5. Настроить retention и мониторинг ¶

Профилактика важнее ручной чистки. Минимальный набор:

• alert на 80%, 90%, 95% disk usage;
• отдельный alert на inode usage;
• log rotation для Docker и системных logs;
• retention policy для execution data;
• контроль размера backup-директории;
• регулярная проверка restore, чтобы backup не был просто мусором на диске;
• отдельный volume/storage для больших binary payload, если они есть.

Для n8n стоит отдельно определить: сколько хранить successful executions, сколько failed, нужно ли сохранять full execution data, где лежат binary files и кто имеет право их удалять.

6. Что нельзя делать ¶

• Не удаляйте volume Postgres «для очистки».
• Не удаляйте .n8n или encryption key.
• Не запускайте массовый prune с volumes без понимания схемы хранения.
• Не очищайте failed executions, пока не решено, какие нужно переиграть.
• Не оставляйте backup только на том же диске, который уже переполнялся.

FAQ ¶

Что чистить первым?
Сначала то, что точно не содержит уникальные production-данные: старые images, build cache, временные logs, дубли backup после проверки копии.

Почему disk full ломает webhooks?
Webhook может принять запрос, но n8n или база не смогут записать execution, payload, binary data или status. В итоге внешний провайдер увидит ошибку или событие потеряет обработку.

Можно ли просто увеличить диск?
Да, это быстрый mitigation. Но без retention и алертов новый диск тоже заполнится.

Нужно ли удалять execution history?
Можно, если есть политика хранения и понимание последствий. Для расследования инцидентов failed executions часто нужны дольше, чем successful.

{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}