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

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

Штатное резервное копирование Битрикс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_%';

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

Разбор 7753 товарных строк показал обратное. 1С считает правильно. Копейки рождаются в Битрикс24, и в документации об этом нет ни слова.

Откуда берутся копейки

Смарт-счета Битрикс24 не округляют цену до копейки, когда сохраняют товарную строку. В базе лежат цены вида 805.23809523, 232.66285715, 3784.725. Из 7753 строк на этом портале цена без налога длиннее копейки у 6996, это 90%.

Как такая цена появляется:

• Менеджер вводит сумму строки, а не цену. Битрикс24 делит сумму на количество и хранит частное как есть: 4 × 1625.00000001 = 6500.00.
• Процентная скидка. Она была в 7737 строках из 7753, и почти любая скидка в процентах дает цену с хвостом.
• Ставка 5%. Цену с налогом делят на 1,05, а это почти всегда бесконечная дробь.

1С так хранить не может: в документе цена в рублях и копейках. При обмене она усекает цену до копейки, а ошибка умножается на количество. При количестве 214 одна строка дает расхождение до 43 копеек. Худший счет на портале разошелся на 94 копейки.

Битрикс24 считает один документ двумя способами

Вторая причина тоньше. Внутри одного счета Битрикс24 округляет по-разному:

• сумму счета считает от итога: сложил все строки, округлил один раз в конце;
• налог считает построчно: округлил НДС каждой строки, потом сложил.

На 405 счетах, где эти способы дают разный результат, налог совпал с построчным расчетом в 404. Формулы пришлось восстанавливать по коду ядра (CCrmProductRow::preparePrices) и проверять на всех 7753 строках: в документации REST поля цены описаны без формул.

Почему подгонять 1С нельзя

Первая мысль обычно такая: настроить округление в 1С, чтобы сходилось с Битриксом. Но 1С здесь права по закону.

• Налоговый кодекс (п. 2 ст. 168) требует считать НДС по каждой позиции. Значит, верна построчная сумма налога.
• Правила заполнения счета-фактуры (постановление № 1137) требуют рубли и копейки. Округлять до рублей нельзя.

Получается, что «чинить» 1С значит сломать ей правильный расчет ради совпадения с неправильным.

Что не помогает

Это проверено, чтобы не тратить время:

• «Правила округления цен» в Битрикс24. Это механизм торгового каталога, к товарным строкам CRM-счета он не применяется.
• Настройки точности и правка типа поля в базе. Работает только на коробке, а здесь облако: доступа к файлам и базе нет.
• Округление в 1С. Противоречит норме, см. выше.

Что передавать в 1С

Решение на стороне обмена:

1. Передавать сумму строки, а не цену. Сумма строки в Битрикс24 правильная, кривая только цена, полученная делением.
2. Итог документа считать как сумму округленных строк. Это не поле «Сумма» (opportunity) из карточки счета: оно посчитано от итога.
3. НДС считать построчно, как требует закон.
4. Если итог задан жестко, копейку разницы отнести на одну строку, с самой большой суммой. Не размазывать по всем строкам. В 1С:Управление торговлей 11 для этого есть специальный тип скидки, «СкидкаНаценкаОкругление».

Две ловушки по дороге

Метод crm.item.productrow.list отдает не больше 50 строк. Он постраничный, и без обхода страниц строки счета молча обрезаются на пятидесятой. На этом портале так обрезались 4 счета, до 58 строк в каждом. В первом проходе они дали «необъяснимый» НДС, а после дозагрузки строк сошлись. Если ваша интеграция с 1С забирает строки этим методом, проверьте, обходит ли она страницы. Иначе в 1С уходят неполные счета.

Флаг «налог включен в цену» не всегда правдив. Нашелся счет на 51 строку, где флаг снят, а цена уже с налогом: 441 при цене без налога 420, ровно 420 × 1,05. Принимающая система начислит НДС второй раз, и расхождение будет уже не копеечным, а в 5%.

Причина нашлась в логе: почти все входящие сообщения из WhatsApp приходили на портал с датой в 58520 году.

Что нашлось в логе

Для разбора взял imopenlines.log за пять суток: 57 МБ, около 30 тысяч событий. 96% трафика открытых линий на этом портале шло через Wazzup (WhatsApp).

Во входящих событиях CONNECTOR - ENTITY ADD у сообщения есть дата. В 7 111 случаях из 7 224 (98,4%) она выглядела так:

[date] => 58520-02-06 18:00:01.000000

Рядом в том же логе лежали нормальные даты: 1784705238 и 2026-07-20T06:45:25-06:00. Значит, портал умеет принимать время правильно, а ломает его один источник.

Откуда 58520 год

При тех настройках интеграции, что стояли на портале, Wazzup отдавал время сообщения в миллисекундах: 1784705238000, тринадцать цифр. Коннектор на стороне Битрикс24 читает это число как секунды. 1 784 705 238 000 секунд от 1970 года как раз дают 58 520 год.

Правильное значение в секундах, 1784705238, это 20 июля 2026. Ошибка в три нуля.

Почему это не косметика

Неверная дата в карточке сообщения выглядит как мелочь. На деле она выключает уборку.

Агенты открытых линий закрывают и чистят сессии по простому условию: последнее изменение было раньше, чем «сейчас минус таймаут». Сессия, у которой дата в 58520 году, под это условие не попадет никогда. Она остается открытой навсегда, и вместе с ней остается все, что к ней привязано:

• чат и его участники;
• счетчики непрочитанного у операторов;
• служебные записи сессии, индексы, статистика по ответам;
• место в списке недавних диалогов у каждого оператора: портал перебирает их при каждом открытии чатов.

Индексы по дате теряют смысл, когда в таблице есть записи «из будущего», и выборки по истории начинают читать больше, чем нужно. В том же логе 81 ошибка NO LAST SESSION: портал не может найти последнюю сессию клиента. Скорее всего, это тоже следствие битых дат.

Масштаб такой: открытые линии на этом портале создавали 83% всех сообщений, около 4 тысяч в сутки, полтора миллиона в год. Каждая сессия, которая не закрылась, оставляет след в базе навсегда.

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

Интеграцию проверяют так: написали в WhatsApp, сообщение пришло в Битрикс24, оператор ответил, клиент получил ответ. Все работает, задачу закрывают.

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

Это типичная история с интеграциями. Проверяют, что данные дошли. Не проверяют, в каком виде они легли и что с ними будет через полгода.

Что сделали

Чинили в три шага, и порядок тут важен. Потом поставили контроль на будущее.

Сначала остановили поток битых дат. Пока новые сообщения приходят из 58520 года, любая уборка бесполезна: через час появятся новые вечные сессии. Чинить стали там, где ошибка рождается, на стороне Wazzup: настроили отправку даты в том формате, который ждет Битрикс24. Код портала при этом не трогали, так что обновление Битрикс24 правку не откатит.

Проверить результат просто. В imopenlines.log у новых событий CONNECTOR - ENTITY ADD дата снова сегодняшняя, а число сообщений из будущего (первый запрос в конце статьи) перестает расти. После смены настройки дата начала приходить в нужном формате.

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

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

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

Напоследок поставили сторожа. Настройку интеграции могут случайно поменять, а Wazzup может обновить свою сторону, и тогда даты снова поедут. Узнавать об этом через полгода по тормозам портала не хочется, поэтому добавили простой контроль через списки Битрикс24. Каждое входящее сообщение создает элемент списка, записи живут один день. Если год в дате сообщения отличается от текущего, уведомление сразу уходит администратору Битрикс24 и директору IT-департамента. Теперь о такой аварии узнают сразу и успевают отреагировать до того, как база снова разрастется.

Попутно в том же логе нашлась вторая причина висящих сессий, уже не техническая. Сотрудники подхватывали чужие диалоги, но у их роли не было права «закрывать чужие диалоги». Попытка закрыть падала с ошибкой ERROR_USER_NOT_OPERATOR, 60–90 раз в сутки, и диалог оставался открытым. Это лечится одной галочкой в правах линии.

Как проверить у себя

Если на коробочном портале открытые линии работают через Wazzup или другой коннектор мессенджеров, эти запросы покажут, есть ли проблема:

-- сообщения и сессии с датой больше чем на год вперед
SELECT COUNT(*) FROM b_im_message          WHERE DATE_CREATE > NOW() + INTERVAL 1 YEAR;
SELECT COUNT(*) FROM b_imopenlines_session WHERE DATE_CREATE > NOW() + INTERVAL 1 YEAR;

-- сколько сессий сейчас открыто
SELECT COUNT(*) FROM b_imopenlines_session WHERE CLOSED = 'N';

Если MySQL работает не в строгом режиме, вместо даты из будущего может лежать 0000-00-00. Ищите и ее.

Если открытых сессий тысячи, а операторы ведут десятки диалогов, стоит посмотреть в imopenlines.log поле [message][date] в событиях CONNECTOR - ENTITY ADD. И заодно проверить в настройках линии, могут ли сотрудники закрывать диалоги, которые взяли у коллег.