Будни техподдержки — реанимация Битрикс24

Бывало ли у вас, что купленная игрушка разваливалась в руках? Тогда вы понимаете чувства нашего клиента, который купил коробочную версию Битрикс24, но через некоторое время (где-то ремонтировали кабель) увидел на экране лишь одинокую фразу на английском.
В вольном переводе на русский это означает «Что-то случилось, попробуйте обратиться позже». Представители заказчика были единодушны в выражении мнения «никто ничего не трогал, оно само так». Для более глубокой диагностики проблемы был организован прямой доступ через протокол SSH до сервера, на котором размещался «Битрикс24». Быстрая диагностика показала, что SQL сервер не работоспособен, а при попытке принудительного запуска сообщает, что у него испорчены файлы базы данных. Счетчик времени работы сервера показывал очень маленькие значения: буквально несколько часов. Дальнейший опрос клиента выявил, что в момент установки в здании «мигал свет», а сервер был подключен без защиты в виде бесперебойных источников питания.
Самым разумным решением в данном случае было бы восстановиться с резервной копии. Однако быстрый просмотр стандартных мест хранения резервных файлов дал однозначный результат: резервного копирования не производилось. Заранее огорчив заказчика («готовьтесь к тому, что будет потеряно все»), было принято решение попробовать восстановить базу данных вручную.
В самом начале для сохранения первоначального состояния был скопирован текущий каталог с файлами базы данных. Затем путем модификаций конфигурационного файла сервера было последовательно предпринято несколько попыток запустить сервер, разрешая ему не реагировать на все большее и большее число ошибок, и игнорируя остальные проблемы.
В конце концов сервер запустился с потерей доступа к маловажным таблицам. Тут же была сделана резервная копия всех доступных таблиц.
Затем была создана база данных «с нуля» и в нее были залита полученная резервная копия. После добавления потерянных таблиц «битрикс» запустился штатно и прошел все внутренние тесты без замечаний.
Управление сервером было возвращено заказчику с рекомендациями по организации резервного копирования. Затраченное время на устранение проблемы составило около 6 часов.