«Частичный бекап данных» - заказы после восстановления сайта на Битриксе

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

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

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

Что можно вернуть

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

Каталог, фотографии товаров, файлы и код сайта восстанавливаются отдельно — из основной копии. Данные об оплате в заказе не подтверждают фактическое состояние расчётов у банка: его сверяют отдельно.

Как сохраняются изменения

Инструмент состоит из двух PHP-скриптов: один собирает резервные данные, второй сопоставляет их с восстановленным сайтом. Состав бекапа и правила сохранения можно доработать под пожелания заказчика: выбрать нужные данные, период отбора, частоту выгрузок и срок хранения. Если нужно сохранять другие данные, их состав и порядок восстановления согласуем после проверки структуры и связей.

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

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

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

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

Сначала план — потом применение

Отчёт строится по сохранённой цепочке без записи заказов и профилей в базу. Помимо добавлений и обновлений, в нём видны пропуски и причины конфликтов.

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

• Пользователи сопоставляются с существующими учётными записями. Если идентификатор уже занят, используются правила проверки email и логина. Неоднозначное совпадение попадает в отчёт.
• У заказа проверяются номер и дата создания. Более свежая сохранённая версия может обновить существующий заказ; если версия на сайте новее, она не заменяется старой из выгрузки.
• Связи позиций с товарами проверяются по идентификаторам и внешним кодам. Отсутствующий товар или несовпадение требуют разбора до применения.
• Конфликт номера не скрывается. По умолчанию такой заказ пропускается. Другой порядок переноса выбирают после проверки причины.

Более свежая версия заказа может содержать отмену или снятую оплату. Такие изменения отмечаются в отчёте: оставлять прежний признак «оплачен» независимо от сохранённых записей об оплатах было бы неверно.

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

Как избежать повторных действий магазина

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

В процессе восстановления отключается запуск агентов и обработка почтовой очереди, блокируется добавление почтовых событий. Число записей в очереди до и после попадает в отчёт.

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

Что проверено на практике

Выгрузка использовалась на работающем магазине: в журнале разработки зафиксированы первый срез 28 сентября 2026 года и ежедневные запуски за первую неделю, до 6 октября.

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

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

Границы восстановления

• Сохраняется выбранный набор. Окно отбора и правила для дополнительных данных ограничивают содержимое среза. Это не вся история магазина. Перед восстановлением нужно проверить, покрывает ли сохранённая цепочка изменения после даты полной копии. Если основа слишком старая, выбранного набора данных может не хватить для заполнения всего промежутка.
• Можно восстановить сохранившиеся данные, даже если отдельная дельта утрачена. Для этого нужен исходный срез и доступные выгрузки изменений его цепочки. Полнота восстановления будет ограничена: изменения, которые сохранились только в пропущенной дельте, вернуть не получится. Поэтому желательно хранить цепочку целиком.
• Целостность файлов и полнота цепочки — разные проверки. Контрольные суммы выявляют повреждение найденных файлов, но не отсутствие целой папки с дельтой. Если в найденной выгрузке отсутствует заявленный файл или не совпадает его контрольная сумма, восстановление останавливается. Проверяйте, что выгрузки за нужные запуски сохранены, и проводите пробное восстановление.
• Это не зеркальная копия базы. Отметка об исчезнувшей записи исключает её из набора восстановления, но не удаляет соответствующую запись на восстановленном сайте.
• Купоны и правила скидок текущий восстановитель не переносит. Рассчитанные цены и суммы заказа сохраняются, но связанные механизмы скидок нужно проверять отдельно.
• Каталог и остатки инструмент не восстанавливает. Если товара нет в восстановленной основе или его идентификатор занят другим товаром, требуется разбор связей.
• Возврат к любой выбранной минуте не предусмотрен. Восстановитель использует последнюю найденную цепочку в указанном источнике. Работа с другим набором копий согласуется отдельно.

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

Что нужно для внедрения

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

Как подключить к вашему магазину

1. Разобрать текущие копии и нужные данные. Что уже сохраняется, что появляется между копиями и какой промежуток потери изменений допустим.
2. Адаптировать инструмент. Отбор записей, сопоставление пользователей и заказов, дополнительные поля и проектные правила.
3. Настроить запуск и получение копий. Проверить результат выгрузки и порядок её сохранения отдельно от хостинга.
4. Провести пробное восстановление. Разобрать отчёт на тестовой копии, проверить применение и сверить результат.
5. Передать порядок действий. Как проверять запуски, забирать копии и готовить данные к восстановлению.

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

Обсудить резервирование данных вашего магазина — контакты внизу страницы.