Вам нужен работающий сайт, а вместо него — недоступный сервер и переписка о восстановлении. Разработчик говорит, что на его компьютере есть код. Менеджеры уверены, что заказы остались в CRM. В почте лежат уведомления об оплате. Но можно ли из этого снова собрать проект — пока непонятно.
После сообщения Beget от 6 ноября вопрос стал особенно острым. По уточнённой оценке провайдера, файловые копии сможет получить только половина пользователей VPS. Это оценка для группы клиентов, а не ответ о состоянии конкретного сервера. Наличие вашего архива нужно выяснять отдельно. Официальное сообщение
Отсутствие полного бэкапа не всегда означает потерю всего проекта. Но оно меняет задачу: сначала нужно установить, что сохранилось, а затем решить, какие функции из этого можно восстановить. Покупка нового VPS, установка CMS или смена DNS сами по себе потерянные записи не вернут.
Эта инструкция — для ситуации, когда готовой проверенной копии у вас нет. Здесь разберём поиск данных, работу с неполными источниками, восстановление страниц и обязательств перед клиентами. Текущий статус услуг и общая последовательность переноса собраны в основной статье о сбое Beget.
Сначала уточните, что именно означает «бэкапа нет»
За этой фразой скрываются разные ситуации. От них зависит, стоит ли ждать конкретный архив, продолжать поиск или уже планировать пересборку.
| Что известно | Как это понимать | Следующий шаг |
|---|---|---|
| Панель недоступна, архив скачать нельзя | Состояние копии ещё не установлено | Запросить сведения по конкретной услуге |
| Поддержка подтвердила архив, но пока не выдала его | Источник найден, использовать его ещё нельзя | Уточнить дату, состав и порядок получения; собрать данные за недостающий период |
| В панели нет вашего сервера | По одному интерфейсу нельзя определить судьбу данных | Сверить ресурс по прежнему ID, IP, договору и аккаунту |
| Полного архива нет, но есть файлы, выгрузки или старый стенд | Возможно частичное восстановление | Проверить каждый источник и составить список недостающего |
| Провайдер подтвердил отсутствие пригодной копии | Из его резервов восстановиться пока не из чего | Искать независимые источники и оценивать пересборку |
Не считайте общую формулировку «копии сохранились» ответом по своему проекту. Нужны идентификатор ресурса, дата архива и сведения о его составе. То же относится к словам подрядчика «всё есть в Git»: репозиторий может содержать только программный код.
Отправьте в поддержку короткое уточнение:
По ресурсу [ID услуги, прежний IP, домен] в аккаунте [логин или номер договора] прошу подтвердить состояние резервной копии: найдена, поиск продолжается или восстановление из ваших копий невозможно.
Если архив найден, прошу указать его дату, состав и формат базы данных. Если ресурс не отображается в панели, подскажите, какие сведения нужны для его сопоставления с аккаунтом. Предыдущий номер обращения: [номер].
Не включайте в обращение пароли и секретные ключи. Сохраните ответ целиком вместе с датой: позже он поможет отличить новую информацию от повторения прежнего статуса.
Сохраните найденное до любых экспериментов
При отсутствии полного бэкапа особенно опасно потерять последний фрагмент: локальную базу, рабочую папку разработчика или выгрузку, которая ещё не успела обновиться пустыми данными.
Попросите участников работ пока не переустанавливать сохранившиеся окружения, не очищать архивы и не запускать синхронизацию без проверки её направления. Сначала скопируйте доступные данные в отдельное защищённое место. Для исследования используйте дубликаты; исходный набор оставьте неизменным.
Это не призыв остановить все системы компании. Нужно временно ограничить операции, которые могут перезаписать ценный источник. Например, старую копию магазина нельзя сразу подключать к двустороннему обмену с актуальной учётной системой: устаревшие статусы могут уйти наружу.
Назначьте одного человека, который собирает материалы и ведёт список изменений. Ему не обязательно самому восстанавливать базу, но он должен знать, кто сейчас работает с какой версией. Ситуация, когда два исполнителя параллельно правят разные копии и называют обе «последней», заметно усложняет объединение.
Архивы могут содержать сведения о клиентах и действующие доступы. Передавайте их через закрытое хранилище с ограниченным кругом участников. Если для диагностики достаточно схемы таблиц или обезличенного примера, полный массив данных передавать не нужно.
Где искать данные, если основного архива нет
Ищите не только файл с названием backup. Полезная информация может находиться в разных системах и под именами, которые не связывают с резервированием: выгрузка перед обновлением, тестовая база, архив передачи проекта, сборка последнего релиза.
Разработчик, прежний подрядчик и тестовые окружения
Попросите проверить рабочие компьютеры, переданные архивы, старые серверы разработки, тестовые стенды и материалы обслуживания. Уточните, когда каждый экземпляр в последний раз сверялся с рабочим сайтом.
Запрос «пришлите сайт» слишком расплывчатый. Используйте конкретный список:
Нужны все доступные версии проекта: код и история изменений, выгрузки базы, пользовательские загрузки, конфигурация без публикации секретов, сведения о версиях программ и инструкция запуска. Для каждого набора укажите дату и происхождение. Отдельно напишите, каких частей у вас нет.
Проверяйте и работу прежних исполнителей. Архив при передаче проекта может быть старым, но полезным для восстановления структуры каталога или исходных шаблонов. Его возраст нужно учесть, а не скрыть за словом «копия».
Репозиторий и материалы сборки
В репозитории могут быть исходники, шаблоны, настройки сборки и история разработки. В системе сборки — готовые файлы выпуска или образ приложения. Это помогает вернуть программную часть, но не доказывает сохранность рабочих данных.
Попросите разработчика проверить, доступны ли все необходимые части: дополнительные репозитории, большие файлы, зависимости и версии пакетов. Если использовался Git LFS, одних ссылок на большие файлы недостаточно — нужны сами объекты. GitHub отдельно описывает их получение при резервировании репозитория. Документация GitHub
Образ приложения тоже не обязательно содержит базу. Изменяемые данные могли лежать на отдельном диске, в томе контейнера или во внешнем сервисе. Спросите исполнителя, где именно хранились записи пользователей, заказы и загрузки.
CRM, учётная система, платёжный сервис и доставка
Сохранившиеся внешние системы помогают восстановить часть операций бизнеса. Выгрузите данные за нужный период, прежде чем включать обмен с новой версией сайта.
| Источник | Что в нём искать | Чего может не хватать |
|---|---|---|
| CRM | Обращения, сделки, контакты, комментарии сотрудников | Состава корзины, всех оплат и событий до создания сделки |
| Учётная система | Товары, артикулы, остатки, документы, отгрузки | Описаний страниц, фотографий, личных кабинетов |
| Платёжный сервис | Операции, статусы, суммы, идентификаторы | Полного состава заказа и условий доставки |
| Служба доставки | Отправления, получатели, трек-номера | Неотправленных заказов и полной истории оплаты |
| Почта компании | Уведомления, согласования, вложения | Писем, которые не были доставлены или сохранялись только на утраченном сервере |
| Каталожные выгрузки | Артикулы, названия, цены, ссылки на изображения | Актуальности цен, наличия самих файлов изображений |
| Документы сотрудников | Прайсы, тексты, договорённости, макеты | Единой версии и связи с текущей структурой сайта |
Ссылка на изображение в товарной выгрузке — ещё не само изображение. Проверьте, открывается ли файл и где физически хранится. То же относится к прикреплённым документам в CRM: интерфейс может показывать имя вложения, которое фактически лежало на пострадавшем сервере.
Выгрузки CMS и отдельные копии базы
Проверьте файлы, сделанные перед обновлением модулей, переносом сайта или массовым изменением каталога. Иногда база сохранена отдельно от файлового архива, поэтому поиск только «полного бэкапа» её пропускает.
У WordPress база и файлы — отдельные части восстановления. В базе обычно находятся материалы, пользователи и настройки, а среди файлов — темы, плагины и загрузки. Наличие папки с изображениями не возвращает записи, которые связывают изображения с карточками. Руководство WordPress
Если уцелели копия базы и журналы её изменений, попросите администратора оценить восстановление на более поздний момент. Например, MySQL описывает применение бинарных журналов после базовой копии. Это специальный сценарий с требованиями к полноте и совместимости данных; наличие случайного файла журнала не гарантирует результат. Документация MySQL
Бинарный журнал базы данных и бинарный бэкап VPS — разные вещи. Из сообщения об утрате образов виртуальных серверов нельзя сделать вывод о наличии журналов конкретной базы во внешнем хранилище. Это отдельный вопрос администратору, который настраивал её резервирование.
Составьте реестр источников: что найдено и насколько этому можно доверять
Не объединяйте найденное сразу. Сначала опишите каждый источник. Для небольшой команды достаточно одной таблицы с ограниченным доступом.
| Поле | Что записать |
|---|---|
| Источник | Кто передал данные и откуда они получены |
| Дата состояния | На какой момент отражены сведения; часовой пояс, если он известен |
| Состав | Какие файлы, таблицы, записи и вложения присутствуют |
| Ограничения | Что отсутствует, повреждено или пока не проверено |
| Идентификаторы | Артикул, ID клиента, номер заказа, ID платежа — по чему можно связать записи |
| Проверка | Как проверяли читаемость, полноту и принадлежность проекту |
| Ответственный | Кто подтвердит содержание и примет решение при расхождении |
| Место хранения | Ссылка на защищённую копию, доступную участникам работ |
Дата изменения файла на диске не всегда равна дате состояния данных: она могла поменяться при копировании или распаковке. Ищите подтверждение внутри архива, в журнале выгрузки и в самих записях. Если точное время неизвестно, так и запишите.
Разделяйте три оценки: файл читается, относится к нужному проекту, содержит актуальные сведения. Успешно открывшаяся таблица может быть старой выгрузкой другого магазина. По нескольким контрольным строкам проверьте товары, пользователей или документы, которые команда хорошо знает.
Для дальнейшего объединения удобно помечать сведения как подтверждённые, требующие сверки и неподтверждённые. Не превращайте предположение в факт только потому, что оно попало в новую базу.
Результат поиска — список доступных источников и пробелов. Пока в нём есть неизвестные, исполнитель должен учитывать их в оценке работ. Обещание восстановить всё до изучения этой таблицы проверить невозможно.
Определите, какую часть проекта можно вернуть
Один найденный источник редко закрывает все задачи. Составьте карту функций: что необходимо для каждой из них и достаточно ли найденного набора.
Есть код, но нет рабочей базы
Разработчик может собрать интерфейс и программную логику. Однако пустая схема базы не содержит прежних товаров, заказов, пользователей и выданных прав доступа. Восстановить структуру таблиц и восстановить их содержимое — разные работы.
Для сайта услуг может оказаться достаточным вернуть тексты, контакты и рабочую форму. Для магазина придётся отдельно загрузить проверенный каталог и решить, откуда брать остатки. Для сервиса с личными кабинетами работающий экран входа почти ничего не говорит о готовности.
Есть база, но нет загрузок и нужной версии кода
Проверьте, к какому выпуску приложения относится база. Новый код может ожидать другие поля и связи. Исполнитель должен установить совместимость на отдельной копии, а не экспериментировать на единственном исходнике.
Список имён загруженных документов не заменяет сами документы. Отметьте отсутствующие файлы и решите, откуда их получить повторно. Если это документы клиентов, запрос должен быть адресным и понятным: какой файл отсутствует, зачем он нужен и через какой защищённый канал его передать.
Есть публичные страницы, но нет серверной части
Можно восстановить представление компании: тексты, иллюстрации, часть структуры и контакты. Формы, поиск, корзина и кабинет потребуют отдельной реализации или подключения к работающим сервисам.
Показывайте только те функции, которые действительно доступны. Кнопка «Оплатить» на визуально восстановленной странице не должна вести в недоделанный процесс. Если пока принимаете обращения вручную, объясните это рядом с действием.
Есть зашифрованные данные, но нет ключей
Отдельно проверьте, что требуется для их чтения: ключи шифрования, пароли архивов, настройки сервиса управления ключами. Они могли храниться вне сервера, но могли быть утрачены вместе с ним.
Не передавайте архив исполнителю с ожиданием, что любой пароль можно «обойти». Пусть он объяснит, какой источник ключей существует и что можно проверить. Если нужного ключа нет, наличие зашифрованного файла само по себе не означает доступность содержимого.
Как использовать веб-архив для восстановления публичных страниц
Веб-архив полезен, если нужно вернуть тексты, структуру и часть изображений. Он не является полной резервной копией приложения. Internet Archive не гарантирует, что нужный сайт или страница были сохранены. Справка Wayback Machine
Начните с важных адресов:
- Соберите URL услуг, категорий, товаров и статей из аналитики, sitemap, рекламных кампаний и рабочих документов.
- Откройте каждый адрес в Wayback Machine и проверьте доступные снимки до инцидента.
- Сохраните пригодные тексты и материалы вместе с исходным URL и датой снимка.
- Отдельно проверьте изображения и файлы: открытая страница не подтверждает наличие всех её ресурсов.
- Сравните версии и выберите данные, которые можно подтвердить сейчас.
Не ограничивайтесь главной страницей: у внутренних URL может быть собственная история сохранений. Если снимок выглядит пустым или неполным, это не повод автоматически считать все связанные материалы утраченными. Но и обещать, что они обязательно найдутся, нельзя.
Интерактивные функции, которым нужны ввод пользователя и обращение к исходному серверу, обычно не работают в архивной версии. Открытая карточка товара не означает, что сохранились корзина или база заказов. Пояснения Archive-It
Что проверить перед возвращением старых материалов на сайт
Архив показывает прошлое состояние. Перед публикацией подтвердите цены, наличие, контакты, адреса, условия доставки и актуальность документов. Устаревшее предложение нельзя возвращать автоматически только потому, что другого текста пока нет.
Разработчику нужно очистить ссылки и служебную разметку архивного просмотра, убрать неработающие обращения к прежним системам и проверить подключаемые скрипты. Копировать целую страницу вместе со всеми сторонними подключениями без разбора не стоит.
Не дописывайте утраченные отзывы, историю заказов и характеристики товаров по догадке. Генерация текста может помочь отредактировать подтверждённые сведения, но не создаёт доказательств того, что покупка состоялась или характеристика верна.
Как собрать каталог и не выдать старые данные за актуальные
Выберите основной источник для каждого типа сведений. Например, названия и артикулы можно брать из учётной системы, описания — из проверенной выгрузки CMS, фотографии — из папки поставщика, которую компания вправе использовать. Это пример распределения, а не универсальная схема.
Связывайте записи по устойчивым идентификаторам. Название товара может меняться, сокращаться или совпадать у разных вариантов. Артикул тоже нужно проверить: некоторые компании повторно используют его или ведут несколько каталогов с одинаковой нумерацией.
До массовой загрузки возьмите небольшую выборку разных случаев: обычный товар, товар с вариантами, снятая с продажи позиция, комплект, позиция без изображения. Покажите результат сотруднику, который ведёт каталог. Если ошибки проявляются на этой выборке, увеличивать объём импорта рано.
Для каждой карточки полезно знать не только источник текста, но и статус проверки цены, остатка и варианта товара. Недостающие поля не следует незаметно заполнять нулями или случайными значениями. Нулевая цена и нулевой остаток — уже конкретные сведения, по которым система может принять решение.
Если актуальные остатки подтвердить невозможно, запустите каталог с запросом наличия. Не включайте автоматическую покупку на основании старой выгрузки. После восстановления обмена сначала проверьте его направление и контрольные позиции, затем разрешайте обновление всего каталога.
Как восстановить заказы, оплаты и обязательства перед клиентами
Здесь задача шире технического наполнения базы. Нужно понять, кто уже заплатил, что компания должна выполнить и какие действия были выполнены до сбоя.
Соберите единый реестр проблемных операций
Для каждой операции сохраняйте источник и исходный идентификатор. Если готовой базы заказов нет, начните с выгрузок платёжного сервиса, CRM, учётной системы и доставки.
| Что фиксировать | Зачем |
|---|---|
| ID платежа и его подтверждённый статус | Найти операцию и не считать одно поступление дважды |
| Номер заказа из каждого источника | Сопоставить разные системы, не потеряв исходные номера |
| Сумма, валюта и время | Выявить расхождения и сузить поиск |
| Состав покупки | Понять, что именно нужно выполнить |
| Отгрузка или выдача доступа | Не исполнить обязательство повторно |
| Возврат или отмена | Не отправить товар после возврата денег |
| Ответственный и статус сверки | Не оставить спорный случай между сотрудниками |
Связку между платёжным идентификатором и новым заказом сохраните явно. Прежняя нумерация могла начаться заново после пересборки. Совпадение номера само по себе не доказывает, что перед вами одна операция.
Не заполняйте пробелы предположениями
Допустим, в кабинете платёжного сервиса есть успешная операция, а в CRM — обращение с похожей суммой. Этого недостаточно, чтобы уверенно связать записи: у разных покупателей могли быть одинаковые суммы.
Ищите идентификаторы заказа, дату, доступные сведения о клиенте и переписку. Если подтверждения не хватает, оставьте случай на ручной проверке. Клиенту можно написать:
Платёж по вашей покупке найден. Мы восстанавливаем сведения о заказе и уточняем его состав. Пожалуйста, укажите номер заказа и товары в нём, если эти сведения сохранились. Повторная оплата не требуется. Реквизиты карты и пароль присылать не нужно.
Этот текст подходит только после фактической проверки платежа. Если операция ещё не найдена, честно сообщите, что сверка продолжается, и попросите минимальные сведения для поиска.
Импортируйте данные без повторного исполнения
При создании исторических заказов новая система не должна автоматически списывать деньги, отправлять товары, выдавать доступ или повторно запускать уведомления. Перед импортом разработчик должен отключить соответствующие действия либо использовать предусмотренный системой безопасный режим.
Одновременно договоритесь, где принимаются новые заказы. Старую историю сверяйте отдельно, сохраняя связь с новыми идентификаторами. Если смешать восстановление прошлого и текущую обработку без этих правил, станет трудно понять, какой заказ реальный новый, а какой перенесён из старой выгрузки.
Не рассчитывайте только на повторную доставку уведомлений от платёжного сервиса. У таких повторов есть ограничения; например, ЮKassa описывает повторную отправку в течение 24 часов при отсутствии успешного подтверждения. Для более долгого простоя нужна отдельная сверка. Документация ЮKassa
Что делать с личными кабинетами и доступом к оплаченным материалам
Нельзя восстанавливать права доступа только по похожему имени, скриншоту страницы или заявлению человека «я здесь покупал». Нужны подтверждённая покупка и надёжное сопоставление с владельцем учётной записи.
Если данные авторизации утрачены, разработчик должен организовать повторное создание или подтверждение аккаунта с учётом устройства сервиса. Не назначайте всем клиентам одинаковый временный пароль и не рассылайте открытые пароли в письмах. Доступ к истории покупок разрешайте после проверки связи между аккаунтом и заказами.
Отдельно проверьте роли сотрудников, администраторов и внешних исполнителей. Старый список пользователей мог не учитывать увольнение или изменение полномочий. Возвращать всем прежний доступ автоматически опасно, даже если их записи нашлись в архиве.
Если документы, переписка или пользовательские загрузки не восстановлены, обозначьте это точно. Пустой кабинет с надписью «всё работает» создаёт ложное ожидание. Сообщите, какие разделы доступны и как обратиться по конкретным отсутствующим данным.
Какую версию сайта запускать первой
Первая версия должна выполнять понятную задачу и опираться на проверенные сведения. Не обязательно ждать восстановления каждой старой страницы, если можно безопасно вернуть основные функции.
| Тип проекта | Что можно рассмотреть для первого запуска | Что нельзя считать готовым автоматически |
|---|---|---|
| Сайт услуг | Основные услуги, контакты, подтверждённые материалы, рабочий приём заявок | Старые цены, формы и адреса доставки писем |
| Интернет-магазин | Проверенный каталог и ручное подтверждение заказа | Остатки, автоматическую оплату и историю покупателей |
| Подписка или онлайн-сервис | Страницу состояния, поддержку, проверенные функции для подтверждённых пользователей | Права доступа, баланс, подписку и пользовательские данные |
| Контентный проект | Приоритетные статьи и разделы, восстановленные из проверенных источников | Полноту публикаций, комментариев и вложений |
Выбирайте приоритеты по данным бизнеса: какие страницы приводили обращения, какие покупки нужно обслужить, какие функции нужны сотрудникам. Если аналитики нет, начните с подтверждённых обязательств и основных предложений компании. Не называйте это списком «самых трафиковых страниц», пока цифр нет.
Разделите работы на три очереди: необходимое для запуска, необходимое для обслуживания прежних клиентов и остальной архив. Для каждой функции укажите источник данных, ограничение и критерий готовности. Так исполнитель сможет оценивать конкретные задачи, а владелец — принимать результат по частям.
Как сохранить адреса страниц и не усложнить восстановление SEO
До пересборки создайте список прежних URL. Источниками могут быть сохранённый sitemap, аналитика, панели поисковых систем, рекламные ссылки, документы и веб-архив. У списка будет разная полнота — отмечайте, откуда взят каждый адрес.
Рядом с URL укажите дальнейшее действие:
| Состояние страницы | Решение |
|---|---|
| Содержание восстановлено и актуально | Вернуть его по прежнему адресу |
| Есть полноценная страница-замена по тому же вопросу | Согласовать постоянное перенаправление на неё |
| Страница временно недоступна, её восстановление запланировано | Выбрать временный режим с разработчиком и SEO-специалистом |
| Страница окончательно удалена и подходящей замены нет | Корректно сообщить об отсутствии страницы |
Не перенаправляйте все потерянные адреса на главную. Не выдавайте пустую карточку или одинаковую заглушку с ответом 200 за восстановленный контент. Google может воспринимать такие ответы как soft 404. Для действительно отсутствующих страниц используются соответствующие коды; временный 503 не гарантирует сохранение индексации при длительном простое. Документация Google
Сохраняйте полезное содержание и смысл страницы, а не только её адрес. Если у прежней услуги изменились условия, проверьте текст с владельцем. Если товар больше не существует, решение по его URL должно учитывать наличие подходящей замены.
После запуска проверьте title, H1, canonical, внутренние ссылки и разрешение индексации. В sitemap должны попасть готовые индексируемые страницы. Зафиксируйте дату пересборки и состав возвращённых разделов: это поможет сопоставлять изменения обхода, показов и обращений. Переобход можно запросить, но обещать возврат прежнего трафика к определённой дате нельзя.
Как поставить задачу исполнителю и оценить предложение
Попросите сначала провести обследование источников. Его результат — перечень найденного, подтверждённые пробелы, возможные варианты запуска и список зависимостей. Стоимость и срок пересборки обсуждают уже для выбранного объёма, а неизвестные указывают отдельно.
В техническом задании полезны такие формулировки:
Цель первого запуска: [какое действие должен выполнять клиент или сотрудник].
Доступные источники: [перечень, даты, ограничения].
Восстанавливаем в первую очередь: [страницы, данные, функции].
Пока недоступно: [функции и данные, для которых нет подтверждённого источника].
Исторические записи импортируются без повторных оплат, отгрузок и уведомлений. Новые обращения учитываются отдельно и сохраняются при последующих обновлениях.
Результат принимаем по: [контрольным данным и действиям]. Исходные материалы сохраняются неизменными. Изменения домена, структуры адресов и интеграций согласуются отдельно.
На обещание «восстановим всё» задайте три вопроса: из каких источников, что именно входит в результат и как это будет проверено. Предложение вернуть только внешний вид не равно восстановлению магазина с историей покупателей.
Попросите показать небольшой работающий фрагмент на тестовом адресе: несколько страниц, контрольные записи, одну необходимую функцию. Это поможет раньше обнаружить, что исполнитель и заказчик по-разному понимают слово «восстановление».
Не объединяйте аварийную пересборку с большим редизайном без необходимости. Если смена CMS действительно требуется, исполнитель должен объяснить причину и отдельные последствия для данных, интеграций и URL. Новая система должна решать подтверждённую задачу, а не просто заменять неизвестную старую.
Если позже Beget всё-таки выдаст копию
К этому моменту новый сайт может уже принимать заявки и заказы. Поэтому полученный архив нельзя просто восстановить поверх работающего проекта: он способен заменить свежие данные более старым состоянием.
Сохраните выданную копию отдельно, проверьте её состав и разверните в изолированном окружении. Сравните её с тем, что удалось собрать самостоятельно. Возможно, из архива нужны только отсутствующие документы, часть карточек или история определённого периода.
Перед объединением составьте правила: по каким идентификаторам сопоставляются записи, какой источник считается основным при конфликте и что остаётся на ручной проверке. Сделайте копию уже работающей системы. Сначала проверьте перенос на ограниченной выборке, затем выполняйте согласованный импорт.
Не забудьте сохранить происхождение добавленных сведений. Через месяц сотрудникам должно быть понятно, почему у заказа такой статус и откуда взялась его связь с платёжной операцией.
Чек-лист: что должно быть готово перед запуском
Этот список помогает принять именно пересобранный проект, в котором данные возвращались из разных источников.
- По каждому источнику известны происхождение, дата или степень неопределённости и ограничения.
- Исходные архивы и выгрузки сохранены отдельно от рабочих копий.
- Определено, какие данные подтверждены, а какие ещё требуют сверки.
- Для каждого вида данных выбран основной источник при расхождениях.
- Контрольная выборка каталога проверена ответственным сотрудником.
- Неизвестные цены, остатки и свойства не подменены случайными значениями.
- Платежи связаны с заказами по проверяемым признакам; спорные случаи выделены отдельно.
- Импорт истории не запускает повторные списания, отгрузки и выдачу доступа.
- Новые обращения и заказы не будут затёрты очередным восстановлением.
- Права пользователей и сотрудников проверены перед возвращением доступа.
- На сайте ясно обозначены доступные и временно ограниченные действия.
- Для прежних URL составлена карта восстановления, замены или удаления.
- Проверен путь от обращения клиента до записи в рабочей системе и ответа сотрудника.
- Зафиксировано, что осталось невосстановленным и как об этом сообщают клиентам.
- Создана независимая копия новой рабочей версии и проверен способ её восстановления.
Если пункт не готов, это не всегда запрещает запуск всего сайта. Но связанная с ним функция должна оставаться ограниченной до проверки. Например, публичные страницы услуг могут работать, пока история личного кабинета ещё восстанавливается.
Начните с реестра источников и списка обязательств перед клиентами. Они покажут, какой результат достижим сейчас, чего не хватает и какую работу имеет смысл оплачивать. Если требуется техническая оценка проекта и его SEO, передайте G-land описание ситуации: тип сайта, найденные материалы и функции, которые нужно вернуть первыми. Секретные доступы и клиентские базы в первое сообщение прикладывать не нужно.