Эксплуатация SuiteCRM без сюрпризов: бэкапы, обновления, безопасность и мониторинг

Почему self-hosted CRM ломается не там, где ждут

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы занимаемся IT-аутсорсингом компаний до 50 рабочих мест в Москве: держим собственные серверы в дата-центре МТС и годами сопровождаем клиентам self-hosted-системы, в том числе SuiteCRM. Поставить CRM — это 10% работы. Остальные 90% — прожить с ней годы и не потерять данные. Об этих девяноста процентах и статья: делюсь боевым регламентом сопровождения, а не теорией.

Первое, что нужно принять: self-hosted CRM ломается не там, где боятся новички. На старте все переживают про «хакеров, которые взломают и украдут базу». По нашей статистике сопровождения около 80% инцидентов — вообще не про взломы. Это кривые обновления, забытый или упавший cron планировщика, переполненный диск, разросшиеся служебные таблицы и — самое страшное — отсутствие рабочего бэкапа на момент аварии. То есть беда почти всегда приходит изнутри, от недосмотра, а не снаружи.

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

Пишу как техдиректор, который лично разбирал не одно «у нас всё пропало» после чужих внедрений, где систему поставили и бросили без сопровождения. Ниже — что делаем мы, чтобы такого не случилось.

Бэкапы по схеме 3-2-1: без этого дальше можно не читать

Начну с фундамента, потому что если из всей статьи вы внедрите только этот раздел — уже не зря читали. Схема 3-2-1 проста: минимум 3 копии данных, на 2 разных носителях/площадках, из них 1 — вне основного сервера (offsite). Для SuiteCRM это значит бэкапить не только базу.

Что именно бэкапим

CRM — это не только СУБД. Полный бэкап SuiteCRM — это три компонента, и пропуск любого делает восстановление неполным:

• Дамп базы данных. Через mysqldump --single-transaction — флаг снимает согласованный снимок без блокировки таблиц на всё время дампа, CRM продолжает работать.
• Каталог upload/ (в 8.x — public/legacy/upload/). Здесь лежат все вложения: сканы договоров, коммерческие предложения, приложения к письмам. Забыли его — восстановили карточки без единого файла.
• Конфиги. .env.local и легаси public/legacy/config.php — в них параметры подключения к БД, site_url, ключи. Без них восстановленная база не заведётся с полпинка.

Скрипт ночного бэкапа с ротацией

Автоматизируем всё скриптом на cron. Логика: снять дамп + упаковать файлы, сложить локально, отправить копию на внешнее хранилище (S3-совместимое облако или FTP), проредить старьё по схеме ротации 7/4/6 — 7 ежедневных, 4 еженедельных, 6 месячных копий. Каркас bash:

#!/bin/bash
set -e
DST=/backup/suitecrm; DATE=$(date +%F)
CRM=/var/www/suitecrm

# 1. дамп БД (single-transaction — без простоя)
mysqldump --single-transaction -u backup -p'ПарольБэкапа' suitecrm \
  | gzip > "$DST/db-$DATE.sql.gz"

# 2. вложения и конфиги
tar czf "$DST/files-$DATE.tgz" \
  "$CRM/public/legacy/upload" \
  "$CRM/.env.local" "$CRM/public/legacy/config.php"

# 3. копия во внешнее хранилище (offsite)
rclone copy "$DST/db-$DATE.sql.gz"    remote:crm-backup/
rclone copy "$DST/files-$DATE.tgz"    remote:crm-backup/

# 4. ротация: чистим локальные старше 7 дней
find "$DST" -type f -mtime +7 -delete

Пользователь БД для бэкапа — отдельный, с правами только на чтение (SELECT, LOCK TABLES), не root приложения. Запуск — ночью по cron, но с важной оговоркой, к которой вернусь в разделе про инциденты: не в 9 утра, когда менеджеры уже работают.

Главное правило: бэкап без теста восстановления не существует

Сколько это стоит клиенту

Клиенты часто спрашивают, дорого ли это. Нет. Внешнее S3-хранилище под бэкапы CRM небольшой компании — это единицы гигабайт, буквально десятки-сотни рублей в месяц. Настройка скрипта и ротации — разовые часы инженера. Ежеквартальный тест восстановления — 1–2 часа раз в три месяца. На фоне стоимости потери всей клиентской базы это смешные деньги, и я всегда говорю: экономить на бэкапе CRM — всё равно что экономить на страховке склада.

Обновления внутри ветки 8.x: порядок, а не героизм

Ветка 8.x развивается активно: релизы 8.8.x, 8.9.x выходят регулярно (на момент написания актуален 8.9.2 от 13 января 2026 года), закрывают баги и уязвимости. Обновляться нужно — но по регламенту, а не «нажал кнопку в пятницу вечером и пошёл домой». Наш порядок обновления внутри ветки 8.x:

1. Свежий бэкап прямо перед обновлением. Не вчерашний ночной, а снятый только что. Обновление — самая частая причина аварий, откатываться будем на состояние «за минуту до».
2. Maintenance-окно. Предупреждаем пользователей, выбираем время минимальной нагрузки. Обновление — не фоновая операция, на время апгрейда система недоступна.
3. Обновление. В 8.x идём через официальную процедуру апгрейда (CLI-инструмент SuiteCRM / штатный upgrade-пакет под конкретный релиз). Всегда сверяемся с release notes целевой версии — иногда меняются требования к PHP.
4. Quick Repair and Rebuild. Admin → Repair → Quick Repair and Rebuild — пересобирает кэш метаданных и языковых файлов. Пропустить — получить «Undefined index» и половину интерфейса на английском.
5. Переустановка русского пакета под новую версию. Частая и обидная грабля: после апгрейда язык «слетает» или частично возвращается к английскому. Русификация — общественный языковой пакет (проект likhobory на GitHub), ставим/обновляем его версию под новый релиз через Module Loader и снова делаем Quick Repair.
6. Smoke-тест по чек-листу из 8 пунктов. Быстрая проверка, что живое осталось живым.

Наш smoke-тест после обновления

Прошёл чек-лист — обновление принято. Что-то отвалилось — откатываемся из свежего бэкапа и разбираемся на стенде, а не на боевой системе с работающими менеджерами.

Переход 7.14 → 8.x: это миграция, а не кнопка

Отдельно и жирным: переход с седьмой ветки на восьмую — это не обновление, а миграция. Кто ждёт «нажать Upgrade и всё» — сильно разочаруется. SuiteCRM 8 архитектурно другой: поверх легаси-ядра семёрки навешен Angular-фронт, изменилась структура каталогов и конфигов. Официальная процедура миграции существует и описана в документации (миграция 7.14.x → 8.7.0+), но у неё есть предусловия и ручная доводка.

Что важно знать до старта

• Сначала на свежую семёрку. Мигрировать можно только с актуальной 7.14.x — сперва догоняете свою инсталляцию до последнего релиза 7-й ветки, потом идёте на 8.x. Прыжок со старой семёрки напрямую не поддерживается.
• PHP придётся поднять. Восьмёрка требует PHP 8.x (для 8.8/8.9 — 8.2/8.3), тогда как многие старые семёрки жили на 7.4. Апгрейд PHP — часть проекта миграции.
• Кастом переезжает руками. Модули, созданные в Studio, кастомные темы, сторонние аддоны — переносятся с ручной проверкой и доводкой. Чем больше кастома накопила семёрка, тем дороже миграция.

Параллельный стенд — обязательное условие

Мы никогда не мигрируем боевую семёрку «на месте». Схема всегда такая: поднимаем параллельный стенд восьмёрки, переносим на него копию данных, доводим кастом, гоняем приёмку с реальными пользователями — и только когда стенд признан рабочим, делаем cutover. Боевая семёрка при этом живёт до последнего и остаётся точкой отката. Миграция «поверх прода» без стенда — это как менять двигатель на ходу.

Когда правильнее остаться на 7.x

И честный вывод, который не любят слышать: иногда не надо мигрировать вовсе. У седьмой ветки есть расширенная поддержка — релиз 7.15 ESR вышел в декабре 2025 года и продлевает жизнь семёрки как минимум на пару лет (примерно до конца 2027-го). Это классическое монолитное PHP-приложение без Angular: проще, стабильнее, без нового интерфейса. Если клиента всё устраивает, кастома много, а бюджета на миграцию нет — мы прямо рекомендуем спокойно сидеть на свежей 7.15 до конца её поддержки, обновляясь внутри семёрки, и планировать переход на восьмёрку заранее, а не в панике за месяц до EOL. Гнать на 8.x ради «новизны» без бизнес-причины — плохая идея.

Безопасность публично торчащей CRM

Теперь про те 20% инцидентов, что всё-таки про безопасность. CRM с клиентской базой, доступная из интернета, — лакомая цель. Защищаем её слоями, от сети к приложению.

Сетевой контур

• HTTPS everywhere. Только шифрованный доступ, редирект с 80 на 443, HSTS. Сертификат Let's Encrypt с автопродлением.
• Админка — за VPN. Наш стандарт: доступ к административному разделу CRM открыт только из внутренней сети или через WireGuard. Публичный интернет видит форму входа пользователей, но не путь в админку. Как минимум — ограничение админ-раздела по списку IP.
• fail2ban на форму логина. Автобан по перебору паролей — самая частая автоматическая атака по всему, что торчит в сеть.

Внутри приложения

• Парольные политики. Включаем требования к длине и сложности, запрет очевидных паролей.
• Двухфакторная аутентификация (2FA). В ветке 8.x есть поддержка TOTP — включаем для админов обязательно, для менеджеров с доступом ко всей базе — крайне желательно.
• Security Groups и роли по минимуму прав. Менеджер видит только своих клиентов, экспорт данных — только у руководителя. Это не только про удобство — это про защиту от утечки (см. ниже).
• Module Loader — только админам. Отключаем возможность ставить модули не-администраторам: Module Loader — потенциальный вектор загрузки вредоносного кода.

Обновления безопасности и CVE

SuiteCRM — форк SugarCRM, и у этой родословной богатая история уязвимостей. За исправлениями следим по advisories SalesAgility и ставим security-релизы без промедления — тянуть с патчами публичной CRM нельзя. Это ещё один аргумент против «поставил и забыл»: непропатченная CRM в интернете рано или поздно найдётся сканерами.

Аудит: главный канал утечки — уволившийся менеджер

Мониторинг и производительность

Чтобы инциденты не превращались в аварии, за CRM надо наблюдать. Мы выносим в мониторинг несколько простых, но критичных метрик:

Когда SuiteCRM начинает тормозить

Со временем «внезапно поумневшая» CRM почти всегда упирается в две вещи. Первое — разрастание служебных таблиц: журнал изменений (*_audit) и лог кампаний (campaign_log) пухнут месяцами и тормозят выборки. Лечение — регламентная чистка старых записей аудита по политике хранения (например, глубже года не держим). Второе — не включённые ускорители: OPcache для PHP (без него код перекомпилируется на каждый запрос) и Redis под сессии/кэш вместо файлов. Это база производительности, которую мы включаем сразу.

Когда оптимизация исчерпана, а база и число пользователей растут — честно идём в вертикальный рост VPS: добавляем vCPU и RAM. SuiteCRM 8 с Angular-фронтом и легаси-ядром — это два приложения в одном, оно любит память. Пытаться удержать растущую компанию на минимальном тарифе «из принципа» — ложная экономия, которая выливается в тормоза и раздражение продавцов.

Пять типовых инцидентов из нашей практики

Теория — теорией, а вот пять реальных сценариев, которые мы разбирали не раз. Формат: симптом → что случилось → как чиним. Узнаете свою ситуацию — сэкономите часы паники.

1. «После обновления белый экран»

Классика. Почти всегда — права на каталоги и кэш: после апгрейда файлы получили не того владельца, и www-data не может писать в cache/. Лечение: пересобрать владельца (chown -R www-data), дать групповую запись служебным каталогам, очистить cache/, сделать Quick Repair and Rebuild.

2. «Пропали письма из карточек»

Менеджеры замечают, что новая переписка перестала подтягиваться. Причина — упал IMAP-коннект Inbound Email, и никто не заметил: система выглядела живой. Именно поэтому доступность забора почты у нас в мониторинге. Лечение: восстановить коннект (сменился пароль ящика/сертификат/адрес сервера), проверить cron, догнать пропущенное.

3. «CRM тормозит по утрам»

Каждое утро система еле шевелится, к обеду отпускает. Диагноз из практики — бэкап запущен в рабочее время: тяжёлый mysqldump в 9:00 душит базу как раз когда менеджеры массово заходят. Лечение: перенести бэкап на глубокую ночь, добавить --single-transaction, при необходимости — на реплику.

4. «Слетел русский язык»

После очередного обновления часть интерфейса вернулась к английскому или вылезли «Undefined index». Причина — не переустановлен/не совпал по версии русский языковой пакет после апгрейда. Лечение: поставить актуальную версию пакета likhobory через Module Loader (при обновлении — сначала Uninstall старого), затем Quick Repair and Rebuild.

5. «Менеджер удалил 2000 контактов»

Самый нервный кейс: сотрудник (по ошибке или назло) снёс тысячи записей. Вот ради этого и существует ночной бэкап. Лечение: поднимаем вчерашний дамп на отдельной VM, выборочно достаём удалённые записи и связи и заливаем обратно через API — не перезатирая работу, сделанную остальными за день. Именно поэтому восстановление мы отрабатываем заранее на тесте: в момент такой аварии импровизировать некогда.

Регламент сопровождения: чек-лист день/неделя/квартал

Сведу всё в готовую таблицу-регламент. Её можно отдать своему системному администратору как инструкцию или использовать как список требований к аутсорсеру: «вы это делаете?». Если на большинство пунктов ответ «нет» — ваша CRM живёт на удаче.

Сколько это часов в месяц

Финальный, самый частый вопрос: «и во сколько нам обойдётся вся эта возня?». Спойлер приятный: при налаженных регламентах на сопровождение SuiteCRM у типовой компании до 50 рабочих мест реально уходит 2–4 часа в месяц. Львиную долю рутины (бэкапы, мониторинг) делает автоматика — человеку остаётся раз в неделю посмотреть на дашборд и логи, раз в квартал провести обновление и тест восстановления. Дорогими становятся не регламенты, а их отсутствие: несколько часов в месяц против аврала на выходных с потерянной базой — выбор очевиден.

Именно так мы обслуживаем self-hosted CRM клиентов: ноль рублей за лицензии, предсказуемые несколько часов сопровождения в месяц и спокойный сон, потому что бэкап есть и он проверен. Не хотите держать это в голове сами — берём CRM на сопровождение под ключ.