--- title: "Pruning executions в n8n: очистка истории запусков — Nodbot" source_url: "https://nodbot.ru/hosting/pruning-executions/" canonical_url: "https://nodbot.ru/hosting/pruning-executions/" language: "ru" content_type: "HostingGuide" section: "hosting" generated_at: "2026-05-30" word_count_source: 1028 --- # Pruning executions в n8n: очистка истории запусков, размер базы и производительность ## AI summary Production-гайд «Pruning executions в n8n: очистка истории запусков»: настройка n8n, инфраструктура, мониторинг, backup, rollback и ошибки эксплуатации. ## Best used for Страница объясняет «Pruning executions в n8n: очистка истории запусков — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Что именно разрастается - Базовая политика хранения - Env-переменные для pruning - Когда не стоит хранить все успешные executions - Как понять, что база уже распухла - Binary data: отдельная зона риска - Безопасная очистка без сюрпризов - Типовые ошибки ## Source outline # Pruning executions в n8n: очистка истории запусков, размер базы и производительность Обновлено: 2026-05-29 История executions в n8n полезна для отладки, но на рабочем инстансе она быстро превращается в источник проблем: растёт PostgreSQL, заканчивается диск, замедляется список запусков, дольше идут backup и restore, а failed executions становится сложнее разбирать. Pruning executions нужен не для “красоты”, а для нормальной эксплуатации self-hosted n8n. Правильная настройка зависит от роли инстанса. Учебному n8n достаточно хранить историю несколько дней. Бизнес-инстансу с заявками, платежами и CRM нужна политика хранения: что оставляем для аудита, что удаляем, что выгружаем в отдельный лог или S3/MinIO, а что вообще нельзя писать в execution data. ## Что именно разрастается - Компонент | Почему растёт | Чем опасно - executions data | каждый запуск сохраняет input/output нод | большая база, медленный UI, долгий backup - binary data | PDF, изображения, вложения писем, файлы из webhook | быстро забивает диск или volume - failed executions | ошибки API, таймауты, 429, неправильные credentials | шум в диагностике и повторные запуски без причины - PostgreSQL bloat | удаления и обновления не сразу возвращают место ОС | нужно следить за vacuum/autovacuum и размером таблиц ## Базовая политика хранения Не начинайте с env-переменной. Сначала решите, зачем вам история: - Отладка новых workflow: хранить 7–14 дней, включать больше данных только на время разработки. - CRM и заявки: хранить техническую историю 14–30 дней, а бизнес-события писать отдельно в Postgres, CRM или audit log. - Платежи и юридически значимые события: не полагаться на execution history как на журнал учёта; сохранять payment_id, order_id, статус и подпись события в отдельную таблицу. - AI/RAG: не хранить большие prompt/context/output бесконечно; логировать минимум для расследования и стоимости. ## Env-переменные для pruning В n8n pruning включён по умолчанию, но на self-hosted инстансе параметры лучше задать явно, чтобы поведение было воспроизводимым после переезда или обновления. ``` services: n8n: environment: - EXECUTIONS_DATA_PRUNE=true - EXECUTIONS_DATA_MAX_AGE=336 - EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000 - EXECUTIONS_DATA_SAVE_ON_SUCCESS=all - EXECUTIONS_DATA_SAVE_ON_ERROR=all ``` EXECUTIONS_DATA_MAX_AGE задаётся в часах: 336 часов — это 14 дней. EXECUTIONS_DATA_PRUNE_MAX_COUNT полезен как дополнительный ограничитель, если workflows запускаются очень часто. Не ставьте значения наугад: сначала оцените частоту запусков и размер базы. ## Когда не стоит хранить все успешные executions Для потоковых workflow, которые каждые 1–5 минут проверяют API, успешные executions редко нужны полностью. В таких сценариях лучше хранить ошибки и отдельный бизнес-лог: ``` { "workflow": "sync-orders", "external_id": "order_12345", "status": "processed", "source": "tilda", "target": "bitrix24", "processed_at": "2026-05-29T10:15:00+03:00" } ``` Такой audit log можно писать в PostgreSQL, Google Sheets для малого проекта или отдельный observability-стек. Execution history тогда остаётся инструментом диагностики, а не единственным источником правды. ## Как понять, что база уже распухла Для PostgreSQL начните с размера базы и самых крупных таблиц: ``` SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size; SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) AS total_size FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 15; ``` Если вверху таблицы execution data, pruning действительно нужен. Если растут другие таблицы, причина может быть не в истории запусков, а в workflow, который пишет дубли в собственные таблицы. ## Binary data: отдельная зона риска Файлы в n8n опаснее обычного JSON: одно письмо с PDF-вложением или webhook с изображением может занимать больше места, чем сотни простых запусков. Если workflows активно работают с файлами, продумайте хранение заранее: - не держите большие вложения в execution history дольше необходимого; - перекладывайте файлы в S3/MinIO, Google Drive, Яндекс Диск или Nextcloud; - в execution data сохраняйте ссылку, hash, размер и внешний ID; - не логируйте персональные документы без причины. ## Безопасная очистка без сюрпризов - Сделайте backup PostgreSQL и volume с binary data. - Зафиксируйте текущий размер базы и диска. - Задайте retention, например 14 или 30 дней. - Перезапустите n8n. - Через несколько часов проверьте, уменьшилось ли количество старых executions. - Если место на диске не вернулось, проверьте PostgreSQL vacuum и storage на уровне провайдера. Важно: удаление строк в PostgreSQL не всегда сразу уменьшает размер файлов на диске. Это нормальное поведение. Цель pruning — остановить бесконтрольный рост и ускорить работу, а не мгновенно “сжать” базу после многомесячного накопления. ## Типовые ошибки - Симптом | Причина | Что делать - диск заполняется, хотя pruning включён | растёт binary data или backup лежит на том же диске | проверить volumes, папку backup, файлы executions - нужный запуск исчез | retention слишком короткий | увеличить срок хранения или писать бизнес-лог отдельно - UI executions тормозит | слишком много старых запусков и больших payload | уменьшить retention, убрать лишний output, проверить Postgres - backup стал огромным | execution history хранит файлы и большие JSON | вынести файлы, сократить retention, не сохранять лишние данные ## Практический минимум для рабочего инстанса - retention 14–30 дней для большинства workflows; - отдельный audit log для заявок, оплат и критичных интеграций; - алерт на свободное место диска; - еженедельная проверка размера PostgreSQL; - регулярный restore-drill, чтобы backup не был декоративным. Если n8n используется как центральный интеграционный слой бизнеса, pruning — это часть архитектуры, а не разовая уборка. Без него через несколько месяцев даже хороший VPS может начать тормозить из-за истории запусков, которую никто не читает. ## Операционный runbook для self-hosted Для темы «Pruning executions в n8n» важно разделять настройку и эксплуатацию. Настройка отвечает на вопрос “запустилось ли”, эксплуатация — “сможем ли мы восстановиться, обновиться и расследовать инцидент без потери credentials и execution history”. Перед изменениями проверьте бэкап базы, значение N8N_ENCRYPTION_KEY, состояние volume, логи web-процесса и worker-процесса. Главный риск — поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key. - Слой | Что зафиксировать | Зачем - Вход | состояние контейнеров, очередь, переменные окружения, volume и последние строки логов | позволяет повторить проблему без доступа к production-секретам - Контроль | restart_count, memory_usage, queue_depth, worker_concurrency, failed_executions | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Pruning executions в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` docker compose ps docker compose logs --tail=200 n8n docker compose logs --tail=200 n8n-worker printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_' # перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY ``` ### Критерий готовности - есть свежий backup базы и проверено значение N8N_ENCRYPTION_KEY - web, worker, queue и database используют согласованные переменные окружения - после изменения проверены логи, healthcheck и запуск критичных workflow - записан rollback-план с командами и ответственным ## Связанные материалы - PostgreSQL для n8n - Backup и restore n8n - Логи и мониторинг n8n - S3 и MinIO для файлов ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.