Как сделать резервную копию проекта в AI-конструкторе

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

Такое разделение выглядит сложнее, чем «нажать бэкап», но оно честнее отражает устройство: собранный проект это не один файл. Ниже разберём каждый слой, порядок действий на пятнадцать минут и то, чего резервная копия не решает.

Что вообще нужно копировать в таком проекте?

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

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

Как сделать полную копию кода?

Через экспорт в GitHub. Он отдаёт настоящий репозиторий с исходниками: структура проекта, зависимости, конфигурация сборки. Это не архив с готовой страницей, а рабочий проект, который открывается в любом редакторе.

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

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

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

Как сохранить данные, если подключена база?

Через дашборд Supabase, потому что база принадлежит вам, а не конструктору. Коннектор подключает ваш собственный проект Postgres, и это ключевое отличие: доступ к данным не зависит от того, откроете ли вы конструктор ещё раз.

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

Отдельно проверьте, что вы понимаете, какие таблицы содержат персональные данные. Резервная копия базы с личными данными это тоже личные данные, и хранить её на рабочем столе не лучшая идея. Как устроено само подключение, разобрано в материале про AI-приложение с Supabase.

Что делать с картинками и файлами?

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

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

Разумный минимум это папка с оригиналами всех своих фотографий в исходном разрешении, где-то вне рабочего ноутбука. Сжатые версии, которые стоят на сайте, всегда можно сделать заново из оригиналов, а обратный путь не работает.

Как часто имеет смысл делать копию?

По событиям, а не по календарю. Расписание «раз в месяц» люди нарушают, а привязка к действию работает.

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

Отдельная привычка, которая стоит ноль: держите файл с описанием проекта и списком удачных промптов рядом с репозиторием. Это самый дешёвый слой резервной копии и самый забытый.

Как перенести проект на свой хостинг?

Через коннектор Vercel или через выгруженный репозиторий. Первый путь короче: вы привязываете свой аккаунт Vercel, и проект разворачивается там, под вашим управлением и на вашем домене.

Второй путь универсальнее. Репозиторий из экспорта это обычный проект, который разворачивается любым способом, каким вы вообще разворачиваете фронтенд. Смысл у обоих путей один: адрес вида vash-proekt.zugo.run перестаёт быть единственным местом, где живёт ваш сайт.

Для темы резервных копий это важнее, чем кажется. Копия кода отвечает на вопрос «чем восстанавливать», а перенос на свой хостинг отвечает на вопрос «где это будет работать, если что-то пойдёт не так». Полноценная страховка это оба ответа сразу, а не один из них.

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

Что записать помимо файлов?

Три вещи, которые не занимают места и экономят больше всего времени.

Первое: список подключённых коннекторов и того, какой аккаунт к какому привязан. Через полгода вопрос «какой именно проект Supabase здесь используется» становится настоящим, особенно если проектов несколько.

Второе: где лежат ключи и доступы. Не сами ключи в репозитории, а указание на менеджер паролей, в котором они хранятся. Секреты в резервной копии это не бэкап, а утечка с отложенным сроком.

Третье: две-три строки о том, почему проект устроен так, а не иначе. Эту часть нельзя восстановить ни из кода, ни из базы, и теряется она первой.

Что резервная копия не спасёт?

Три вещи, и о них честнее знать заранее.

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

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

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

Порядок действий на пятнадцать минут

Короткий прогон, который закрывает большую часть риска:

1. Сделайте экспорт кода в GitHub и убедитесь, что репозиторий приватный.
2. Клонируйте его к себе на машину, чтобы копия была не только в облаке.
3. Если подключён Supabase, выгрузите ключевые таблицы из дашборда.
4. Соберите оригиналы своих изображений в одну папку.
5. Заведите текстовый файл: описание проекта, список удачных промптов, какие коннекторы подключены.
6. Запишите, где лежат ключи и доступы, но не кладите их в тот же репозиторий.

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

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

Если вы ещё не проверяли, как выглядит выгрузка на вашем проекте, сделайте это сегодня, пока копия не нужна срочно. Откройте Zugo, выгрузите код в репозиторий и посмотрите, что именно вам отдали.