Восстановление каталога Airtable из snapshot: почему появляется новая база
Как подготовить снимок каталога Airtable, восстановить отдельную базу и проверить подключения, вложения и историю перед возвратом к работе.
Содержание статьи
Восстановление snapshot в Airtable создаёт отдельную базу, а не перезаписывает действующий каталог. Это позволяет сравнить состояния, но требует внимательной проверки подключений: у восстановленной базы будет новый app ID. После ошибочного импорта нельзя считать работу завершённой сразу после появления старых товаров на экране. Нужно убедиться, что команда и интеграции используют нужную базу.
Зафиксируйте состояние до исправления
Если массовая правка повредила цены или характеристики, сначала остановите связанные изменения по рабочему процессу и сохраните текущее состояние. В нём могут находиться новые заказы и полезные исправления, сделанные уже после выбранной точки восстановления. Возврат к более ранней версии не должен незаметно уничтожить сведения, которые потребуется перенести обратно.
Airtable делает автоматические снимки с частотой, зависящей от использования базы, и позволяет создавать ручные. Не воспринимайте это как гарантированный снимок перед каждой операцией. Перед крупным импортом каталога через CSV проверьте, что нужная точка действительно доступна, и зафиксируйте её время.
Восстанавливайте в понятное место
В истории базы выберите снимок, задайте понятное имя восстановленной копии и проверьте рабочее пространство. Сразу обозначьте назначение: например, «Каталог — проверка до импорта». До завершения сверки не передавайте эту копию всем сотрудникам как новую основную систему. Иначе часть команды продолжит работу в прежней базе, а часть — в восстановленной.
Идентификаторы записей, таблиц и ряда других объектов сохраняются, но идентификатор самой базы меняется. Внешняя интеграция, настроенная на старый app ID, не переключится от одного сходства названий. Составьте список потребителей каталога: выгрузка товаров, подготовка изображений, отчёты и автоматические уведомления. Для каждого определите, нужно ли переносить подключение.
Сверьте данные и файлы отдельно
Начните с числа товаров и ключей вариантов, затем сравните проблемные поля по известному списку изменений. Отдельно проверьте позиции, созданные после снимка. Для них может потребоваться перенос из текущего каталога. Не объединяйте записи только по названию, если существуют варианты одинаковой модели с разными размерами.
Откройте вложения у нескольких карточек из разных периодов. История тарифных планов и срок хранения снимков могут повлиять на доступность старых файлов. Наличие строки с именем фотографии ещё не доказывает, что изображение восстановлено и читается. Дополнительно учитывайте особенности временных ссылок на файлы.
Не переносите ожидания от истории правок на snapshot
Восстановленная база включает комментарии, но не получает прежнюю историю изменений записей. Поэтому сохраните исходную базу доступной для расследования, если нужно выяснить, кто и когда поменял цену. Снимок отвечает на вопрос «какими были данные», а журнал изменений помогает разобраться в последовательности действий.
Завершайте восстановление контрольной операцией: обновите тестовый товар по согласованному процессу, проверьте результат в подключённой системе и убедитесь, что коллеги видят правильную версию. Только после этого переводите каталог в штатную работу. В отчёте о восстановлении запишите выбранный снимок, новую базу, перенесённые поздние изменения и список проверенных интеграций.
Материал отражает сведения на указанную дату. Правила и условия работы площадок могут измениться. Редакционные принципы