Бэкап Битрикс24 на 115 ГБ, в котором нет ни одной сделки

Резервная копия базы весила 115 ГБ, лежала в списке копий и выглядела готовой. Когда ее попробовали развернуть на тестовом сервере, оказалось, что в ней 288 таблиц из примерно тысячи. Ни пользователей, ни сделок, ни задач, ни переписки.

Об этом никто не знал. Копия считалась рабочей до первой попытки ее восстановить.

Что было внутри

Штатное резервное копирование Битрикс24 делало файлы на 115–120 ГБ. Размер солидный, дата свежая, отметка о готовности на месте. Внутри копии не было таблиц b_user, b_crm_deal, b_im_message, b_tasks_*, b_disk_*, то есть всего, ради чего бэкап и делают.

Дамп обрывался на таблице b_crm_access_attr_dynamic_1154. Объяснение нашлось только в журнале событий, с фильтром BACKUP_ERROR:

Таблица b_crm_access_attr_dynamic_1160 разрушена в результате внутренней ошибки MySQL.

Таблица не разрушена, ее нет

Формулировка Битрикса ведет по ложному следу. Таблица b_crm_access_attr_dynamic_1160 не повреждена: ее просто не существует. SHOW CREATE TABLE отвечает ошибкой 1146, «нет такой таблицы», а в словаре данных MySQL от нее не осталось даже записи.

Механизм оказался такой:

1. В начале прогона Битрикс составляет список таблиц и дальше идет по нему.
2. На базе такого размера полный проход занимал около недели. Это видно по самому файлу: в имени дата 28 июля, а дописан он 4 августа.
3. За эту неделю на портале удалили смарт-процесс. Рядовая операция, ее делает любой администратор CRM. Вместе со смарт-процессом исчезла его служебная таблица прав.
4. Через несколько дней выгрузка дошла до этой таблицы по списку, не нашла ее и остановилась.
5. Таблицы выгружаются по алфавиту, а обрыв пришелся на начало. Все содержательное в копию не попало.

Это не разовое невезение. В нумерации смарт-процессов на этом портале больше пятнадцати пропусков: их удаляют регулярно, и любой такой пропуск во время недельного прогона снова ломает копию.

Почему этого никто не видел

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

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

Полная копия тоже может не развернуться

Следующая копия прошла целиком: 2230 таблиц. При развертывании она упала на середине:

ERROR 1062 (23000): Duplicate entry '7920399-1141386-2' for key 'b_crm_timeline_bind.PRIMARY'

Дубль первичного ключа значит, что одна и та же строка попала в выгрузку дважды. Битрикс читает таблицы порциями без транзакции, а портал в это время работает. У таблиц без числового ключа чтение идет через смещение (LIMIT смещение, N). Новая строка в середине таблицы сдвигает смещения, и часть строк выгружается повторно. Выгрузка идет часами, так что шанс на такой дубль высокий.

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

Что с этим делать

Чинить таблицу бессмысленно, чинить нечего. Варианты такие:

• Перезапустить копирование. Список таблиц соберется заново и будет верным. Но это рулетка на неделю: следующее удаление смарт-процесса или воронки снова все оборвет.
• На время прогона не удалять смарт-процессы, воронки и инфоблоки. Костыль на одну попытку, на портале с сотнями сотрудников его не удержать.
• Сократить длительность прогона. Это настоящее решение. На этом портале 182 ГБ базы занимал журнал бизнес-процессов b_bp_tracking, а рабочие данные (сделки, задачи, переписка, пользователи) весили около 15 ГБ. Без журнала копирование превращается из недельного в часовое, и окно для такого сбоя почти закрывается.

И одно правило, которое работает всегда: бэкап проверен только тогда, когда из него восстановились. Размер файла, дата и зеленая отметка не значат ничего.

Как проверить свою копию

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

grep -c '^DROP TABLE IF EXISTS `b_user`' dump.sql

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

LC_ALL=C grep -ohE '^DROP TABLE IF EXISTS `[^`]+`' dump.sql | sort -u | wc -l

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

SELECT ENTITY_TYPE_ID, TITLE FROM b_crm_dynamic_type ORDER BY ENTITY_TYPE_ID;

SELECT TABLE_NAME FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME LIKE 'b_crm_access_attr_dynamic_%';

И раз в месяц или раз в квартал разворачивать копию на отдельном сервере. Это единственная проверка, после которой можно сказать, что бэкап есть.