Резервная копия есть. А магазин из неё восстановится?

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

Резервная копия есть. А магазин из неё восстановится?

«У нас ежедневный бэкап» — полезный ответ на вопрос, сохраняются ли данные. Но сможет ли магазин после сбоя принимать заказы, а менеджер — видеть, что покупатели уже оплатили?

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

Почему зелёной галочки недостаточно

Копирование может завершиться успешно, но сохранить не всё, что вы подразумеваете под магазином. Например, базу данных без загруженных файлов или файлы без базы заказов. В 1С-Битрикс состав архива зависит от настроек: отдельные каталоги и файлы можно исключить. Поэтому за словами «полный бэкап» должен стоять список того, что действительно сохраняется.

Даже проверка целостности архива — ещё не проверка магазина. В Битрикс она выполняет «виртуальную» распаковку без создания файлов, но не проверяет оформление заказа и наличие фотографий товаров на восстановленном сайте.

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

Что должно вернуться вместе с сайтом

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

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

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

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

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

Корпоративную почту и учётную базу 1С обсудите отдельно. Ящики у другого сервиса не входят в бэкап сайта автоматически, а настройки отправки писем — не сохранённая переписка. Копия интернет-магазина также не заменяет копию всей бухгалтерии и склада.

Что будет с заказами после последней копии

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

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

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

Заранее договоритесь, кто разберёт промежуток между копией и сбоем: соберёт доступные сведения у платёжного сервиса, в 1С, CRM и других системах, сопоставит заказы и проверит статусы. Эти сведения помогут при сверке, но могут сохраниться не полностью.

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

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

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

До первого запуска приложения на копии нужно заблокировать реальные платежи, письма и СМС покупателям, обмен с рабочей 1С, CRM, складом и доставкой. Это касается и фоновых заданий, которые работают без посетителей. Если для проверки нужна копия самой 1С, её тоже следует изолировать: восстановление не должно запускать вторую рабочую 1С или второй источник обмена с ней.

На безопасно подготовленном стенде попросите показать, что:

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

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

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

Достанете ли вы копию, если недоступен хостинг

Архив в папке сайта удобен, пока доступен сам сервер. На случай недоступности хостинга нужен другой способ получить данные и восстановить магазин. У локального и облачного хранения Битрикс разные условия доступа — одного знания, что «копия где-то есть», недостаточно.

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

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

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

О чём договориться с подрядчиком сейчас

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

Шаблон обращения

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

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

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

Стоимость тоже разделите: хранение копий, настройка, тест и аварийное восстановление. Что-то может входить в тариф или договор, что-то — оплачиваться отдельно. Слово «бэкап» в описании услуги не означает, что весь процесс бесплатен.

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

404.by / Хостинг для бизнеса

Ваш сайт может работать быстрее

Обсудим задачи проекта и поможем подобрать конфигурацию для вашего сайта на 1С-Битрикс.

Обсудить проект