С технической стороны вопроса в большинстве случаев процедура переноса Битрикс24 из облака в коробку совершенно стандартна и ничем не отличается от обычного восстановления из резервной копии. Но иногда бывают ситуации, когда восстановление штатными средствами может быть затруднительным.
Ситуация
Например, так было с одним нашим клиентом, использующим облачный Битрикс24. Им перестало хватать функционала, который может предложить облако и они хотели переехать в коробку, чтобы дорабатывать и модифицировать корпортал под свои нужды. Вместе с тем им хотелось, чтобы сервер с Битрикс24 и всеми данными находился на территории предприятия.
Для коробочного Битрикс24 не принципиально местонахождение сервера, лишь бы он отвечал предъявляемым техническим требованиям. В нашем случае по плану нужно было поставить корпортал на виртуальную машину имевшегося сервера, по соседству с центральной 1С, контроллером домена и другими важными сервисами. Поскольку к моменту создания виртуалки сервер уже много лет использовался — у системного администратора получилось выделить только 125 Гб на подключённом к нему SSD-диске.
Этого было недостаточно для компании, в которой работает около 100 сотрудников. В таких случаях мы обычно предлагаем воспользоваться услугами облачного хранилища для выгрузки файлов из /upload/, но в текущей ситуации это тоже был исключённый вариант, так как файлы загрузок — тоже данные, которые должны остаться на территории клиента.
По итогам обсуждений системный администратор клиента всё же смог найти неиспользуемый NAS с HDD-дисками, который тоже можно было подключить к серверу. К сожалению, мы не могли использовать его в качестве основного, т.к. это бы привело к медленной работе портала, но для директории /upload/ той скорости чтения и записи, которую он предоставляет вполне хватало.
Ограничения
Время
После того, как мы заказываем в Битрикс24 создание резервной копии – начинается рассинхронизация между текущим облачным корпорталом и тем корпорталом, который мы сможем восстановить из бэкапа. Последствия этой рассинхронизации потом приходится устранять, и чем больший период прошёл с момента создания бэкапа, тем их меньше.
Мы не можем влиять на неспешную работу сотрудников Битрикс24, которым нужно несколько дней на создание бэкапа, но со своей стороны можем сделать так, чтобы восстановление прошло максимально быстро.
Размер диска
Полная копия их портала по предварительной оценке должна была составить около 250 Гб. Совместно с клиентом мы смогли почистить некоторые ненужные данные и немного освободить место, но размер особо не изменился и составил 221 Гб, что всё равно больше, чем наш основной диск. Не говоря о том, что при развёртывании нам понадобится как минимум в три раза больше места, чем размер бэкапа.
Решили, что пойдём обходным путём:
– При установке примонтируем NAS как корневую директорию Битрикса
– Скачаем и восстановим резервную копию
– Перенесём файлы ядра Битрикса на SSD
– Перемонтируем NAS к директории /upload/
Скорость интернета
При подготовке к переносу мы замеряли скорость интернета, к которому подключен сервер, получалось около 60 Мбит/с. Хотя зная этого провайдера — были определённые подозрения в том, что скорость всё время будет высокой, но нам повезло и они не оправдались.
С нашей стороны было бы также некрасиво, если бы мы забили весь входящий в офис канал скачиванием бэкапа. Достоверно неизвестно, какие сервисы находятся в локальной сети клиента и как мы можем на них повлиять, поэтому договорились, что мы ограничим скорость скачивания и будем использовать только 40 МБит/с.
Дальше в дело вступает математика. Чтобы скачать 221 Гб на скорости 40 МБит/с, нужно потратить 12 часов. Это вообще говоря долго, даже если бы мы не ограничивали скорость канала.
В какой-то момент мы прикидывали, какая скорость передачи данных у нас получится, если распределить части архива между сотрудниками отдела разработки, отправить их домой, чтобы каждый из них на домашнем интернете загрузил порученные ему части и привёз бы на флешке в офис клиента. В теории на всё ушло бы около 4-х часов, но на практике это был бы не самый надёжный способ, поэтому не стали им пользоваться.
Восстановление бэкапа
Стандартный способ восстановить сайт из резервной копии — скачать с официального сайта restore.php, открыть скрипт в браузере и следовать дальнейшим инструкциям. Способ прекрасно работает для небольших интернет-магазинов, но при восстановлении бэкапа большого размера им пользоваться довольно неудобно.
Во-первых, нам нужно скачать 2 271 часть архива, каждая по 100 Мб. Если при скачивании очередной части произойдет сбой (например, на сервере на минуту ляжет сеть) — то процесс начинается заново. Учитывая, что нам качать 12 часов — это было бы довольно рискованно.
Во-вторых, скрипт скачивает части архива по одной, что в конечном счёте выходит медленнее, чем если бы в нём было реализовано многопоточное скачивание.
И в-третьих, использование мастера по восстановлению предполагает исключительно графический интерфейс, с которым нужно работать в браузере. Если случайно закрыть вкладку, в которой происходит разворачивание, весь процесс придётся начинать заново.
Распаковку и дешифровку файлов всё равно придётся делать с помощью restore.php, но хотя бы скачивание бэкапа на сервер мы можем сделать самостоятельно. Тогда при запуске мастера восстановления скрипт увидит, что файлы уже на месте и перейдёт сразу к следующему шагу.
Процесс переноса
Настраиваем сервер
Заранее устанавливаем на сервер CentOS 7.5 и последнюю версию веб-окружения Битрикс24. Настраиваем все компоненты и сервисы, которые нам в дальнейшем понадобятся: Apache, Nginx, Mysql, Memcached, Sphinx, NodeJS RTC. Выписываем SSL-сертификаты и конфигурируем их автоматическое продление, подключаем сервер к мониторингу.
Также ставим два пакета, которые нам пригодятся для восстановления бэкапа:
– aria2, чтобы скачивать файлы в многопоточном режиме
– tmux, чтобы можно было в любой момент подключаться или отключаться от сервера
[/bp_code]
Запрашиваем создание резервной копии
Для этого пишем в Битрикс24 и ждём, когда они её сделают. Когда резервная копия готова, нам приходит письмо со ссылкой на её скачивание.
Из него же узнаём точное количество частей в архиве: их получилось 2 271.
Скачиваем резервную копию
Сначала формируем файл с перечислением всех файлов, которые нужно скачать:
[bp_code background=””] # Первая часть архива$ echo ‘http://migration-share-box.bx24.net/cloud/20190226_203923/20190226_203923_full_93b858c5.enc’ > /home/bitrix/www/files.txt
# Последующие части архива
$ for i in `seq 1 2270`; do echo “http://migration-share-box.bx24.net/cloud/20190226_203923/20190226_203923_full_93b858c5.enc.$i” >> /home/bitrix/www/files.txt; done
[/bp_code]
Затем открываем сессию в tmux’е и инициируем скачивание такой командой:
[bp_code background=””]
$ aria2c –max-overall-download-limit 6M –max-connection-per-server 10
–max-concurrent-downloads 10 –continue –input-file /home/bitrix/www/files.txt
–dir /home/bitrix/www/files.txt
[/bp_code]
Пару минут смотрим, как идёт процесс, всё работает без перебоев. Теперь отключаемся от сервера на 12 часов и ждём, когда все файлы скачаются.
Восстанавливаем резервную копию
Спустя 11 часов 43 минуты скачивание успешно завершается и мы можем продолжить работу.
Скачиваем в корневую директорию Битрикса на сервер скрипт restore.php:
[bp_code background=””] $ curl -sL https://www.1c-bitrix.ru/download/files/scripts/restore.php -o /home/bitrix/www/restore.php[/bp_code]
После чего обращаемся к нему из браузера и следуем стандартному мастеру установки. Ускорить этот процесс уже не получится, поэтому просто ждём, когда он закончится.
Полное восстановление всех данных из архива заняло 5 часов 13 минут. Ещё около 20 минут ушло на проверку целостности распакованного ядра и около 15 минут на восстановление базы данных. Итого, спустя 5 часов 48 минут после начала восстановления портал начал работать.
Донастраиваем Битрикс24
Теперь можно отписаться клиенту, что они могут начинать пользоваться новой версией своего корпортала и продолжить настройку сервера и Битрикс24 по штатной процедуре установки на сервер. Как минимум, нужно удалить файлы резервной копии и служебные скрипты.
Итоги
Как бы штатная система резервного копирования не рекламировалась, как максимально упрощённый способ держать данные в целости и сохранности — не всегда её использование является оптимальным способом снимать бэкапы. В некоторых случаях вплоть до полной невозможности снять бэкап проекта с её помощью.
Зачастую в момент обсуждения с клиентом технических требований к серверу коробочной версии Битрикс24 не воспринимается, как сложный софт, которому для работы требуется достаточно много ресурсов. В итоге бюджет, выделяемый на комплектующие сервера или параметры VPS формируется по остаточному принципу. Это может приводить к сложностям при интеграции или дальнейшей работе, которых можно было бы легко избежать в самом начале.
