Что считается сбоем в коробочном Битрикс24 и почему это не облачная история
Когда у клиента с облачным Битрикс24 падает сервер провайдера, это проблема вендора, а не ваша: он сам держит резервные копии и сам поднимает портал. С коробочной версией всё иначе. Сервер, база данных, файлы, обновления, антивирус, мониторинг — зона ответственности компании, которая купила лицензию и развернула систему на своей инфраструктуре (или на арендованном сервере). Если админ-панель перестала открываться, база данных повреждена, диск отказал или обновление положило портал, восстанавливать всё придётся вам, вашему сисадмину или подрядчику, который ведёт коробку.
Это не повод отказываться от коробочной версии: для компаний с требованиями к хранению данных внутри страны, глубокой кастомизацией или интеграцией с 1С коробка часто остаётся единственным вариантом. Но план восстановления после сбоя нужно продумать заранее, а не в момент, когда отдел продаж уже час сидит без CRM и звонит директору.
Сбоем в этом контексте можно считать несколько разных ситуаций, и для каждой сценарий восстановления немного отличается. Это может быть полная недоступность сервера (хостинг лёг, виртуальная машина не поднимается), повреждение базы данных (ошибка при обновлении, сбой диска, некорректное завершение процесса MySQL), потеря или порча файлов сайта (неудачное обновление модуля, ошибка при ручной правке кода, действия злоумышленника) или человеческий фактор: сотрудник случайно удалил критичные данные, либо бизнес-процесс, откатить который штатными средствами CRM уже нельзя.
Что должно быть готово заранее, чтобы восстановление вообще было возможно
Прежде всего: инструкция по восстановлению работает только тогда, когда есть из чего восстанавливать. Без действующей резервной копии никакому мастеру восстановления просто нечего будет распаковывать.
Модуль «Резервное копирование» в коробочной версии (он работает на том же ядре Bitrix Framework, на котором построен коробочный Битрикс24) умеет создавать архивы по расписанию и хранить их в разных местах (подробнее об этом ниже). Для реального аварийного восстановления важны три вещи одновременно:
- Копия должна лежать не только на том же сервере, который может выйти из строя целиком: если диск с сайтом и диск с бэкапом физически один и тот же, при аппаратном сбое вы теряете и то, и другое.
- Пароль от зашифрованного архива должен быть известен не только тому единственному сотруднику, который сейчас в отпуске без связи: если архив запаролен, без пароля его не распаковать.
- Копию нужно периодически пробовать восстанавливать на тестовом стенде, а не только создавать. Резервная копия, которая никогда не проверялась восстановлением, — это гипотеза, а не страховка.
Отдельно стоит держать под рукой доступы, которые понадобятся именно в момент сбоя: логин и пароль администратора портала, доступ к хостинг-панели или SSH на сервер, лицензионный ключ (он нужен при восстановлении из облачной копии), и контакты того, кто физически администрирует сервер, если это внешний подрядчик.
Из чего состоит резервная копия и где её хранить
Прежде чем говорить о восстановлении, стоит закрыть один частый источник путаницы. Bitrix Framework, на котором построен коробочный Битрикс24, поддерживает полное резервное копирование. Встроенного инкрементального или частичного бэкапа «из коробки» здесь нет. Архив создаётся в формате tar.gz, и при его создании можно вручную выбрать, что именно включить: файлы публичной части сайта, ядро платформы и дамп базы данных MySQL. Дамп базы обязателен, если целью стоит полное восстановление: без него из архива можно поднять файлы, но не данные CRM. При этом из архива можно по желанию исключить статистику посещений, поисковый индекс и журнал событий. Это не влияет на работоспособность портала после восстановления, но заметно уменьшает размер копии.
Мест для хранения архива три, и у каждого свои ограничения:
- Локально на сервере, в папке
/bitrix/backup/. Это бесплатно и быстро, но именно этот вариант уязвим к тому самому сценарию полного отказа сервера, о котором говорилось выше: если диск с сайтом и диск с бэкапом физически совпадают, при аппаратном сбое пропадает и то, и другое одновременно. - Облако 1С-Битрикс. Требует активного коммерческого лицензионного ключа. Для лицензий из России, Беларуси и Казахстана данные размещаются в Yandex Object Storage, для остальных регионов — в Amazon S3. Доступный объём зависит от тарифа лицензии (от нескольких до нескольких десятков гигабайт), и есть важное ограничение: система хранит не более трёх последних копий, более старые удаляются автоматически.
- Стороннее облако через модуль «Облачные хранилища». Подходит, если в компании уже есть корпоративная политика хранения бэкапов вне инфраструктуры вендора, но требует отдельной регистрации у провайдера и самостоятельной настройки подключения.
Автоматизация создания копий запускается одним из трёх способов: облачным сервисом резервного копирования (не требует настройки на стороне сервера), задачей cron, которая раз в минуту дёргает системный файл проверки расписания, либо прямым запуском скрипта резервного копирования через панель хостинга. Периодичность настраивается вручную: раз в день, через день, каждые три дня или раз в неделю. Для архива можно включить шифрование, а также ограничить максимальный размер одного файла архива (рекомендуемое значение — около 100 МБ, не более 200 МБ), из-за чего архив крупного портала физически разбивается на несколько частей. Именно поэтому при восстановлении, как говорилось выше, важно не забыть докачать все части архива целиком.
Восстановление через админ-панель: пошагово
Если сервер и админ-панель портала доступны (это самый частый и самый простой случай, например, база данных повредилась после неудачного обновления, но сам сервер жив), восстановление выполняется штатным инструментом.
- Зайдите в раздел Настройки → Инструменты → Резервное копирование → Список резервных копий.
- В списке доступных архивов найдите нужную резервную копию и в меню действий выберите пункт «Восстановить».
- Мастер восстановления попросит указать источник архива: это может быть локальная копия на сервере, копия в облачном хранилище (тогда потребуется ввести лицензионный ключ) или архив, загруженный вручную с диска.
- Если архив зашифрован, на этом шаге нужно ввести пароль архива: без него распаковка не начнётся.
- Мастер распаковывает архив и восстанавливает базу данных; при необходимости он может создать новую базу данных, если восстановление идёт не поверх существующей.
- После восстановления мастер удаляет служебные файлы, которые использовались в процессе. Это стандартный шаг для безопасности, чтобы файлы восстановления не остались доступны публично.
Важный нюанс для многотомных архивов (когда бэкап разбит на несколько файлов из-за размера базы или файлового хранилища): загружать нужно все части архива целиком, иначе распаковка прервётся с ошибкой. И ещё один нюанс: распаковать из архива отдельные файлы, не восстанавливая всё целиком, можно только если архив локальный и не зашифрован; для облачных или запароленных копий доступно только полное восстановление.
Когда админ-панель недоступна: восстановление через restore.php
Второй, более тяжёлый сценарий — когда портал не открывается вообще: сервер не отвечает, база данных не поднимается, или вы переносите портал на новый сервер после аппаратного сбоя старого. В этом случае восстановление через привычный интерфейс невозможно, и используется отдельный скрипт restore.php.
Ссылка на скачивание этого скрипта обычно доступна прямо в списке резервных копий, рядом с самим архивом, поэтому разумно скачать restore.php заранее, пока портал ещё жив, а не пытаться найти его в момент, когда всё уже упало. Порядок действий такой: скрипт кладётся в корневую папку сайта на новом или восстановленном сервере вместе с файлом самого архива, после чего в браузере открывается адрес вида ваш_домен/restore.php, и дальше запускается пошаговый мастер, аналогичный тому, что работает внутри админ-панели: выбор архива, ввод пароля при необходимости, распаковка, восстановление базы данных.
Перед тем как запускать restore.php на новом сервере, стоит убедиться, что версии PHP, MySQL и остальных компонентов на новом окружении совместимы с теми, что использовались на момент создания резервной копии. Расхождение версий часто становится причиной, по которой восстановленный портал поднимается, но работает нестабильно.
Разные сценарии сбоя — разная тактика
Инструкция выше покрывает механику восстановления, но реальная скорость реагирования зависит от того, что именно случилось.
Сервер полностью недоступен. Здесь восстановление через админ-панель невозможно по определению: портал физически негде открыть. Единственный путь — поднять новый сервер (или виртуальную машину) и восстановиться на нём через restore.php из офсайт-копии. Это самый долгий сценарий, и именно для него критично заранее иметь копию не на том же железе, что и сам сайт.
База данных повреждена, но сервер жив. Обычно это следствие неудачного обновления или сбоя диска на уровне файловой системы базы. Здесь чаще всего достаточно восстановления через штатный мастер в админ-панели, без переноса на новый сервер.
Ошибка при обновлении коробки. Отдельная и частая причина простоя — плановое обновление модулей или ядра, после которого портал перестаёт открываться корректно. Хорошая практика здесь — создавать резервную копию непосредственно перед любым обновлением коробочной версии, а не полагаться на последний ночной бэкап по расписанию: если обновление стартовало утром, а плановое копирование было ночью, откат вернёт вас на состояние до вчерашних изменений, а не на состояние «пять минут назад».
Человеческий фактор — случайное удаление данных. Сотрудник массово удалил сделки через фильтр, ошибочно запустил бизнес-процесс, который затронул тысячи записей, или роботизированный сценарий сработал не так, как задумывалось. Полное восстановление портала из бэкапа в этом случае — тяжёлая мера: оно откатывает вообще всё, включая корректные изменения, сделанные после момента сбоя другими сотрудниками. Прежде чем запускать полное восстановление ради одной испорченной сущности, стоит оценить, нельзя ли исправить проблему точечно, например через выгрузку затронутых данных из резервной копии в отдельную базу и ручную сверку, а не через откат всего портала.
Локальное хранилище бэкапов переполнено или недоступно. Если резервные копии годами копились в папке /bitrix/backup/ на том же сервере без ротации старых архивов, рано или поздно место на диске заканчивается, и в худшем случае это происходит одновременно с самим сбоем, а не до него: диск, забитый бэкапами, — частая скрытая причина, по которой у сервера вообще не остаётся свободного места для нормальной работы базы данных. Регулярная очистка устаревших локальных копий и перенос части архивов в облако — простая профилактика именно этого сценария.
Условный пример из практики (иллюстрация, а не описание задокументированного сценария): у производственной компании ночью зависла виртуальная машина с коробочным Битрикс24, и утром отдел продаж пришёл к «белому экрану». Резервная копия лежала в облачном хранилище отдельно от самого сервера, поэтому команда развернула новую виртуальную машину, поставила на неё нужную версию PHP и MySQL и восстановилась через restore.php за то время, что заняло разворачивание инфраструктуры. Портал вернулся в рабочее состояние до обеда, а не через несколько дней поиска причины аппаратного отказа.
Как подготовиться заранее, чтобы восстановление занимало минуты, а не часы
Большая часть боли при аварийном восстановлении коробочного Битрикс24 — это не сложность самой процедуры, а то, что к ней не готовились. Несколько практических шагов, которые стоит закрыть заранее, а не в момент сбоя:
- Настроить регулярное расписание резервного копирования и хранить хотя бы одну актуальную копию вне сервера, на котором крутится сам портал.
- Периодически (например, раз в квартал) фактически разворачивать резервную копию на тестовом сервере и проверять, что портал поднимается и данные на месте, а не просто доверять факту создания архива.
- Документировать сам процесс восстановления в виде короткого чек-листа для конкретной инфраструктуры компании: где лежат копии, кто держит пароли и лицензионный ключ, к кому обращаться по серверу, если это внешний подрядчик.
- Создавать внеплановую резервную копию перед любым обновлением коробки, миграцией на новый сервер или крупной доработкой — это дешевле, чем откатываться на вчерашний бэкап по расписанию.
- Мониторить состояние сервера (диск, память, доступность MySQL) отдельно от мониторинга самого портала: сбой Битрикс24 часто является следствием проблемы на уровне инфраструктуры, которую видно раньше, чем она долетает до пользователей CRM.
Если внутри компании нет отдельного системного администратора, который держит это всё в голове и регулярно проверяет, а коробочный Битрикс24 — критичная для продаж система, разумно передать сопровождение сервера и резервного копирования подрядчику на аутсорсе. Мы в B2BPRO.KZ ведём именно такие коробочные инсталляции: от настройки регулярного бэкапа и мониторинга сервера до аварийного восстановления, когда сбой уже случился. Если у вас сейчас нет уверенности, что портал реально можно поднять из вчерашней копии за разумное время, наши услуги по Битрикс24 закрывают именно этот разрыв: от диагностики текущей схемы бэкапов до полноценного сопровождения коробочной версии.
Ещё один момент, который часто упускают: ответственность за восстановление не должна замыкаться на одном человеке. Если единственный, кто знает, где лежит архив и как выглядит пароль от него, — это конкретный сисадмин, а он в отпуске, в дороге или просто не берёт трубку в момент сбоя, формально существующий план восстановления на практике не работает. Чек-лист восстановления стоит хранить не в переписке с одним подрядчиком, а в доступном для нескольких ответственных лиц месте, вместе с указанием, кто именно и в каком порядке предпринимает действия при разных типах сбоя: кто эскалирует проблему на хостинг, кто запускает восстановление через админ-панель, а кто принимает решение, оправдан ли полный откат портала ради исправления локальной ошибки одного сотрудника.
Отдельно стоит сказать про масштаб компаний, для которых актуальна эта тема. Если коробочный Битрикс24 используется небольшим отделом продаж на одном сервере без филиалов, план восстановления можно держать в голове у одного администратора. Но чем больше пользователей, филиалов и интеграций завязано на портал, тем дороже обходится каждый час простоя, и тем важнее, чтобы процедура восстановления была не в голове одного человека, а задокументирована и хотя бы раз проверена на практике кем-то ещё.
Частые вопросы
Сколько времени занимает восстановление коробочного Битрикс24 из резервной копии?
Зависит от сценария. Если сервер жив и нужно восстановить только базу данных через админ-панель, это может занять от нескольких минут до часа в зависимости от размера базы. Если сервер полностью недоступен и нужно разворачивать новую инфраструктуру перед восстановлением через restore.php, время растягивается на часы, большую часть которых занимает не сама распаковка архива, а подготовка нового сервера.
Можно ли восстановить только часть данных, а не весь портал целиком?
Из локального незашифрованного архива можно распаковать отдельные файлы. Но полноценное выборочное восстановление отдельных сущностей CRM (например, только удалённых сделок за конкретный день, без отката всего остального) штатными инструментами резервного копирования не предусмотрено: восстановление подразумевает откат портала целиком к состоянию на момент создания копии.
Что делать, если пароль от резервной копии утерян?
Если архив зашифрован и пароль неизвестен, распаковать его штатными средствами не получится, поэтому пароли от бэкапов стоит хранить так, чтобы к ним был доступ минимум у двух ответственных сотрудников, а не только у одного администратора.
Обязательно ли восстанавливаться на том же сервере, где был портал до сбоя?
Нет. Именно для случаев полного отказа сервера и предусмотрен скрипт restore.php: он позволяет развернуть портал из резервной копии на новом сервере, при условии совместимых версий PHP и MySQL.
Как часто нужно делать резервные копии коробочного Битрикс24?
Единого норматива нет: частота должна зависеть от того, насколько для бизнеса критична потеря данных за период между копиями. Компании с интенсивным потоком сделок обычно настраивают ежедневное копирование и дополнительно создают внеплановую копию перед любым обновлением или изменением конфигурации сервера.
Поддерживает ли коробочный Битрикс24 инкрементальное резервное копирование?
Нет, штатный модуль резервного копирования Bitrix Framework создаёт только полные архивы: выбрать можно набор компонентов (файлы, ядро, база данных), но не режим «копировать только изменения». Уменьшить размер архива можно, исключив из него статистику посещений, поисковый индекс и журнал событий. На восстановление данных CRM это не влияет.