бэкаплю n8n и litellm, а сами разговоры и логи как хранить чтоб не разрослось

Собрал у себя связку: n8n + ollama + litellm как шлюз. Дошли руки до бэкапа — воркфлоу и креды n8n понятно, дамплю. А вот с логами и историей вопрос: litellm пишет обращения, n8n копит выполнения, и это всё пухнет. Хочется и бэкапить полезное (чтоб при переезде не потерять сценарии и настройки), и не тащить в бэкап гигабайты логов, которые через месяц не нужны. Как разделяете «ценное сохранить» и «мусор чистить»? Ротация логов + дамп конфигов, или есть подход поумнее?

leo_msk раздели по природе данных, а не по сервисам. ценное и маленькое (воркфлоу n8n, конфиги litellm, .env) — в дамп, версионируй, оно копейки весит. история выполнений и логи — это операционное, ему ротация (logrotate/встроенная в docker json-file с max-size), а не бэкап. history n8n чисти по расписанию, тебе выполнение трёхнедельной давности не нужно. не бэкапь то, что не жалко потерять — иначе бэкап пухнет и его перестают делать.

leo_msk если n8n на postgres (а не sqlite) — там история в таблице execution_entity, она и пухнет. Настрой в n8n EXECUTIONS_DATA_PRUNE и максимальный возраст, оно само подчистит, и база не растёт. Дампь pg_dump'ом уже подчищенную. Я недавно тут ловил oom как раз потому что «всё копилось», nesterov меня носом ткнул в проверку дампа, кстати.

leo_msk правило, которое отвечает на весь ваш вопрос: бэкапьте то, что нельзя воссоздать, и не бэкапьте то, что можно. воркфлоу, конфиги, ключи — нельзя, их в дамп и в другое место. логи и история выполнений — операционный мусор, ему ротация и prune, kate_ekb и mike_pg верно сказали. и не путайте бэкап с архивом: если история вам зачем-то нужна юридически — это отдельная задача, отдельное хранилище, не «на всякий случай в тот же дамп». дамп раз в месяц разворачивайте на пустое и проверяйте, что n8n из него встаёт. непроверенный дамп конфигов — это вера, что вы ничего не забыли, а вы забыли.

nesterov «бэкапьте то, что нельзя воссоздать» — вот это и есть ответ, спасибо, у меня в голове щёлкнуло. mike_pg про EXECUTIONS_DATA_PRUNE — у меня как раз postgres и как раз пухнет, включаю сегодня. kate_ekb docker json-file с max-size поставил, а то логи контейнеров отдельно разрастались. Пойду проверять, что из дампа реально поднимается, а не «лежит и ладно».

leo_msk раз n8n на postgres — не забудь, что EXECUTIONS_DATA_PRUNE чистит историю, но саму базу тоже надо дампить (pg_dump), а не только конфиги. я на этом попадал: конфиги в гите, а данные workflow только в базе, которую oom killer чуть не унёс. дамп базы + prune истории = и не пухнет, и не теряется.

mike_pg да, pg_dump n8n-базы поставил в дамп рядом с конфигами, prune истории отдельно. Теперь ценное (workflow, креды, база) бэкапится, мусор (логи, старые выполнения) чистится. nesterov «бэкапь то, что нельзя воссоздать» разложило всё по полкам. Проверил, что из дампа n8n поднимается — поднимается.

leo_msk раз уж проверил, что n8n из дампа встаёт — заведи это в привычку раз в месяц, а не «проверил один раз и забыл». дампы имеют свойство тихо ломаться от смены версии postgres или полного диска. ритуал разворота дампа скучный, но именно он отличает бэкап от папки, в которую страшно заглянуть.

leo_msk вернулся спросить, как обещал в таких случаях: дамп n8n, который ты проверил разворотом, — ты его с тех пор ещё раз разворачивал, или «один раз проверил и успокоился»? версии меняются, диск заполняется, дамп тихо портится. проверка не разовая. раз в месяц на пустое — и тогда это бэкап, а не отметка в календаре.

Для n8n проверьте ещё ключ шифрования credentials. Дамп базы и workflows без соответствующего ключа — неполный комплект для восстановления подключений. Ключ хранить отдельно и с ограниченным доступом, не выкладывать вместе с примером compose.

quiet_fox спасибо, это точное замечание. В своей проверке я поднимал базу рядом со старой конфигурацией, поэтому ключ уже был под рукой. В следующий прогон включу восстановление на пустом окружении по списку файлов, без доступа к старому серверу.

leo_msk и запускайте копию без рабочих расписаний и внешних отправок. Проверка восстановления не должна внезапно второй раз выполнять вчерашние операции. Для проверки подключения достаточно заранее подготовленного безопасного сценария.

leo_msk по самим разговорам и логам: в n8n проще всего держать их в той же базе, но с жёстким retention — в настройках executions выставить сохранение только последних N дней или N штук, а старое резать штатной очисткой по cron. Логи контейнеров лучше вообще не хранить вечно: ограничить max-size и max-file в docker logging driver, чтобы диск не съедался молча. Так ценное остаётся в бэкапе, а болото само себя подстригает.

kostya_gw, удаление старых executions и уменьшение занимаемого места — разные проверки. В PostgreSQL обычный VACUUM в основном делает место доступным для повторного использования, а не обязательно уменьшает файл на диске. Поэтому отсутствие мгновенного уменьшения размера ещё не означает, что очистка не работает. Полезно смотреть число старых записей, работу autovacuum и дальнейший рост таблицы.