История версий workflow n8n: срок хранения, доступ и проверка восстановления

После изменения workflow мало увидеть старую схему в истории. Руководителю нужно заранее знать, какая глубина истории доступна, кто вправе заменить текущую редакцию и сохранит ли старая схема работоспособность с нынешними учётными данными и внешними системами.

Практическое правило: историю workflow используйте для возврата схемы, журнал выполнений — для разбора запусков, а резервную копию — для восстановления инсталляции и её зависимостей. Срок хранения и порядок возврата устанавливайте только после проверки всех трёх уровней.

Что хранит история версий workflow

История workflow хранит прошлые редакции схемы. Например, в одной редакции может быть другой узел или другое значение параметра. Это помогает сравнить изменения и выбрать основу для возврата.

Такая история не доказывает, что сохранились или работают credentials, переменные окружения, файлы, внешние данные, API и инфраструктура. Если база экземпляра или другие необходимые компоненты утрачены, наличие когда-то созданной редакции само по себе не обеспечивает восстановление.

Поэтому план возврата должен отвечать на два разных вопроса:

1. Можно ли получить нужную редакцию схемы?
2. Можно ли безопасно запустить её с актуальными зависимостями?

Какая глубина истории доступна в редакции n8n

По официальной документации n8n, проверенной 30 октября 2026 года, версии за последние 24 часа доступны всем пользователям. Версии за последние пять дней доступны в n8n Cloud Pro. Полная история заявлена для n8n Cloud Enterprise и self-hosted Enterprise.

Это условия продукта, а не рекомендация хранить редакции именно столько времени. Тарифы и состав функций могут измениться. Перед утверждением внутреннего порядка откройте используемую среду и сверьте фактическую глубину истории с текущей документацией и условиями своего тарифа.

Какие изменения попадают в историю

Согласно документации, n8n создаёт новую версию, когда пользователь:

• сохраняет workflow;
• восстанавливает прежнюю версию — перед восстановлением n8n сохраняет текущую;
• выполняет pull из Git через Source Control; при этом версии хранятся в базе экземпляра n8n, а не в Git.

Изменение workflow settings само по себе новую версию не создаёт. Это важное исключение: факт изменения настройки нельзя выводить только из списка редакций схемы.

Документация описывает историю workflow, но не подтверждает версионирование credentials, прав доступа, переменных окружения, файлов и внешних зависимостей. До принятия регламента проверьте на контролируемом workflow те виды изменений, которые существенны именно для вашей команды.

Чем история отличается от выполнений и резервной копии

У этих механизмов разные объекты и задачи.

Возврат схемы не возвращает уже отправленное письмо, созданную запись или другое действие во внешней системе. Правила хранения запусков разбираются отдельно в материале о данных выполнений n8n, а состав восстановления инсталляции — в руководстве по резервному копированию n8n.

Как установить срок хранения редакций

Универсального числа часов, дней или версий нет. Сначала соберите условия процесса:

• как часто команда меняет workflow;
• через какой период обычно обнаруживает ошибку;
• к каким последствиям приводит неверная редакция;
• перед какими изменениями нужны контрольные точки;
• какую глубину истории предоставляет используемая редакция n8n;
• что входит в резервную копию и как проверяется её восстановление;
• кто отвечает за хранение и пересмотр правил.

Требуемое окно возврата должно перекрывать реалистичный период обнаружения ошибки. Если продуктовая глубина истории короче этого окна, одной встроенной истории недостаточно: нужно отдельно проектировать хранение и восстановление, не выдавая экспорт схемы за копию всей инсталляции.

В self-hosted n8n переменная N8N_WORKFLOW_HISTORY_PRUNE_TIME задаёт срок хранения версий до автоматического удаления в часах. Значение -1 означает хранение всех версий без автоматической очистки по сроку; это же значение указано в документации как значение по умолчанию.

Эта настройка управляет очисткой истории. Она не расширяет тариф, не назначает права пользователям и не гарантирует восстановление credentials, файлов, API или инфраструктуры. До изменения параметра оцените рост хранилища и включите наблюдение за ним в эксплуатационный порядок.

Именованные версии, очистка и внешний экспорт

Перед значимым изменением полезно создать идентифицируемую контрольную точку, если используемая редакция n8n поддерживает именование. Документация разрешает присвоить версии название и описание и указывает, что n8n не удаляет именованные версии автоматически.

Именование заявлено для n8n Cloud Pro и Enterprise, а также self-hosted Business и Enterprise. Условия проверены 30 октября 2026 года; перед применением их нужно сверить для своей среды.

В названии и описании контрольной точки можно зафиксировать:

• причину изменения;
• связанную задачу;
• ожидаемый результат;
• ответственного за решение.

Не помещайте туда секреты и клиентские данные. Временная очистка через N8N_WORKFLOW_HISTORY_PRUNE_TIME и исключение именованных версий из автоматической очистки — разные правила. Их нужно учитывать отдельно.

Выбранную редакцию можно скачать как JSON. Такой файл помогает сохранить схему или перенести из неё нужные изменения, но не является полной резервной копией: в нём нельзя предполагать наличие всех учётных данных, файлов, переменных, базы и инфраструктуры.

Кто может просматривать и восстанавливать версии

Документация подтверждает операции с прошлыми редакциями, но не задаёт универсальную матрицу полномочий для всех тарифов, ролей и способов размещения. Поэтому требования к доступу нужно спроектировать, а затем фактически проверить в используемой среде.

Для каждой строки назначьте роль, основание операции, способ фиксации решения и проверку реального ограничения. Не рассчитывайте без проверки, что нужное разделение полномочий обеспечено n8n по умолчанию. Общий подход к ролям можно сверить с руководством о доступе команды к n8n.

Как проверить восстановление до инцидента

Проверяйте возврат на контролируемом workflow и разрешённых тестовых данных. Безопасная последовательность выглядит так:

1. Выберите контрольную редакцию и зафиксируйте текущее состояние.
2. Откройте прежнюю версию для сравнения с текущей.
3. Если условия среды позволяют, создайте отдельный workflow на её основе вместо немедленной замены рабочего.
4. Сверьте узлы, параметры, credentials, переменные, входные данные и внешние зависимости.
5. Подайте разрешённые тестовые входы без рабочих писем, записей и других нежелательных последствий.
6. Проверьте ожидаемый результат, обработку ошибки и возможность вернуться к исходному состоянию.
7. Зафиксируйте результат и решение уполномоченного сотрудника.

В состав проверки включите ситуации, которые могут сделать старую схему неработоспособной: учётная запись недоступна, API изменился, вход получил новую структуру, а внешнее действие уже было выполнено. Количество проверок определяйте по ветвлениям, зависимостям и последствиям ошибки, а не по произвольной норме.

Синтетический пример: возврат workflow обработки обращений

Это условная демонстрация будущей процедуры, а не клиентский кейс, файл или выполненный Switch On AI тест.

Команда добавляет в workflow обязательное поле и новый маршрут ошибки. Перед выпуском она записывает назначение текущей редакции и, если используемая редакция n8n поддерживает именованные версии, создаёт понятную контрольную точку.

После обнаружения ошибки ответственный сотрудник открывает прежнюю версию рядом с текущей. По возможности он создаёт на её основе отдельный workflow, чтобы не заменять рабочую схему до проверки.

Команда проводит разрешённое тестовое обращение, сравнивает результат с ожидаемым и документирует расхождения. Только после решения уполномоченного сотрудника она восстанавливает прежнюю редакцию либо переносит из неё нужные изменения. Пример показывает порядок проверки, но не подтверждает совместимость с конкретной системой заказчика.

Ограничения и подготовка задачи на внедрение

Перед утверждением правил зафиксируйте ограничения:

• история зависит от редакции, тарифа и сохранности экземпляра n8n;
• доступная глубина, временная очистка и исключение для именованных версий — разные условия;
• старая схема может ссылаться на изменившиеся credentials, переменные, файлы, узлы и API;
• возврат редакции не отменяет уже выполненные внешние действия;
• история, именованная версия и JSON-экспорт не заменяют резервную копию.

Для постановки задачи подготовьте:

• перечень workflow и их владельцев;
• критичность каждого процесса по последствиям ошибки;
• виды изменений и требуемое окно возврата;
• фактическую глубину истории в используемой среде;
• значение и порядок изменения настройки очистки;
• перечень именованных контрольных версий;
• права участников на просмотр, экспорт, копирование и восстановление;
• состав резервной копии;
• безопасные тестовые входы и запрещённые последствия;
• порядок принятия и фиксации решения о возврате.

Switch On AI помогает разбирать процессы и проектировать автоматизацию с проверяемыми требованиями. В рамках разработки и внедрения автоматизации можно обсудить правила хранения и восстановления workflow n8n, отделить доступные функции продукта от требований проекта и определить состав работ. Для разговора подготовьте сведения о размещении и редакции n8n, критичных workflow, глубине истории, очистке, ролях и резервном копировании. Стоимость, сроки, сопровождение и текущие расходы согласуются отдельно после разбора задачи.