EspoCRM в бою: обновления, бэкапы, безопасность и 152-ФЗ

«Бесплатная CRM» ≠ «бесплатная эксплуатация»: считаем честно

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы занимаемся IT-аутсорсингом компаний до 50 рабочих мест в Москве, и EspoCRM — одна из систем, которые мы регулярно разворачиваем и сопровождаем у клиентов. В предыдущих статьях серии я разобрал, что это за система, как поставить её на VPS и как связать с телефонией и сайтом. Сегодня — самая недооценённая тема: что происходит с self-hosted CRM после запуска. Спойлер: она не живёт сама по себе, но и не требует выделенного администратора.

Формула, которую я повторяю на каждой встрече: open-source бесплатен как лицензия, но не как обслуживание. Когда вы платите за облачную CRM, в подписку зашиты труд девопсов вендора, его бэкапы и его дежурные инженеры. Когда вы разворачиваете систему у себя, эти обязанности никуда не исчезают — они переезжают к вам или к вашему подрядчику. Из чего состоит сопровождение на практике:

• Обновления. Релизы EspoCRM выходят регулярно, патчи ветки — практически ежемесячно. Их надо накатывать, иначе через год вы сидите на дырявой сборке.
• Бэкапы. База клиентов — самый ценный актив отдела продаж. Диск VPS умирает без предупреждения, и единственная защита — проверенные резервные копии.
• Мониторинг. Место на диске, cron-задания, сертификат TLS — всё это тихо ломается, если за ним не следить.
• Мелкие доработки. Новое поле в карточке, новая роль для стажёра, подкрутить шаблон письма — рутина, которая возникает раз в месяц-два.

Теперь цифра, ради которой пишется весь раздел. По нашей статистике сопровождение типовой инсталляции EspoCRM на компанию до 50 рабочих мест занимает 1–3 часа инженера в месяц. Не ставка администратора, не полдня в неделю — часы. Час уходит на обновление и проверку бэкапов, остальное — на мелкие просьбы пользователей. Именно поэтому self-hosted экономика сходится: труд есть, но его мало.

Обновления: релизы выходят ежемесячно — и это хорошо

Частые релизы — признак живого проекта, а не головная боль. Актуальная ветка на момент публикации — 9.3: сама версия вышла 5 февраля 2026 года, свежий патч 9.3.10 — 2 июля 2026-го. Патчи ветки выходят регулярно, и в них едут не только фиксы, но и заплатки безопасности — поэтому «обновимся когда-нибудь» я считаю плохой стратегией.

Веб-интерфейс или CLI: как правильно накатывать

Технически апгрейд доступен из веб-админки (Administration → Upgrade), но официальная документация прямо не рекомендует этот путь: обновление выполняется одним веб-процессом, и обрыв соединения или таймаут PHP посреди процесса оставит систему в полусобранном состоянии. Мы всегда обновляем из консоли:

cd /var/www/espocrm
sudo -u www-data php command.php upgrade

Команда сама находит подходящие пакеты обновления, скачивает их и последовательно применяет. Запускать её стоит внутри screen или tmux — если SSH-сессия оборвётся, процесс доживёт до конца без вас. Семантика версий у Espo честная: патч (третья цифра) безопасен, минорный переход может задеть совместимость, мажорный — почти наверняка задевает, и бэкап перед ним обязателен. Пропускать по несколько версий разработчик не советует: чем длиннее прыжок, тем менее гладко он проходит. Ещё один довод обновляться ежемесячно, а не раз в год.

Наш регламент апгрейда

Порядок, который мы отработали на десятках обновлений: сначала свежий бэкап базы и файлов, затем прогон апгрейда на тестовой копии (разворачиваем вчерашний бэкап на отдельной VM — заодно это и есть проверка восстановимости), затем прод в нерабочее время с включённым Maintenance Mode и выключенным cron. После апгрейда — smoke-чек-лист: логин, открытие карточки, отправка тестового письма, создание задачи, проверка планировщика. Пять минут кликов ловят 90% проблем до того, как их утром найдут менеджеры.

Кастомизации: почему мы никогда не правим ядро

Главный секрет безболезненных апгрейдов — дисциплина кастомизации. Всё, что сделано штатными средствами — поля и сущности через Entity Manager, раскладки через Layout Manager, формулы, настройки в каталоге custom, — переживает обновления без последствий: апгрейд заменяет ядро, не трогая ваш слой. А вот правки файлов ядра погибают при первом же обновлении, поэтому у нас железное правило: в application и client лезть запрещено, любая доработка — только через custom или расширение. Откат, если что-то пошло не так, тоже штатный: восстановить файлы прежней версии из бэкапа, удалить каталоги application, html, public и vendor, положить старые на место и выполнить rebuild.

Лицензия при переезде со старых веток

Если вы обновляете инсталляцию многолетней давности, учтите юридический нюанс: начиная с версии 8.1 (декабрь 2023 года) EspoCRM распространяется под AGPLv3 вместо прежней GPLv3. Для внутреннего использования в компании ничего не меняется — ограничение касается только сценария, когда вы дорабатываете систему и продаёте доступ к ней наружу как сервис. Но если у вас есть форки или вы встраивали Espo в собственный продукт, перед прыжком с 7.x или 8.0 стоит показать этот пункт юристу.

Бэкапы по схеме 3-2-1: скрипты, шифрование и тест восстановления

Бэкап — это не «на всякий случай», это единственное, что отделяет сбой диска от катастрофы бизнеса. Начнём с состава: что именно надо копировать в EspoCRM.

• Дамп базы данных — сами клиенты, сделки, письма, история. Это ядро бэкапа, копируем ежедневно.
• Каталог data — вложения, загруженные файлы, кэши. Растёт быстрее всего.
• Каталог custom (и client/custom) — все ваши сущности, поля и доработки.
• Файл конфигурации — параметры подключения и ключи инсталляции.

Базу снимаем без остановки сервиса — MariaDB умеет консистентный дамп на лету:

mariadb-dump --single-transaction --quick \
  --routines espocrm | gzip > /backup/espocrm-db-$(date +%F).sql.gz

Флаг --single-transaction даёт согласованный снимок InnoDB-таблиц без блокировки: менеджеры продолжают работать, пока идёт дамп. Полный ночной скрипт у нас выглядит примерно так (упрощённая версия без вычистки секретов):

#!/bin/bash
set -euo pipefail
D=/backup/espocrm; TS=$(date +%F)
mariadb-dump --single-transaction --quick espocrm | gzip > "$D/db-$TS.sql.gz"
tar czf "$D/files-$TS.tar.gz" -C /var/www/espocrm data custom client/custom config.php
gpg --batch --yes -e -r backup@itfresh.ru "$D/db-$TS.sql.gz"
rsync -a "$D/" backup2:/vol/espocrm/   # вторая площадка
find "$D" -mtime +30 -delete           # ротация 30 дней

Дампы с персональными данными мы шифруем GPG до отправки на внешние хранилища: резервная копия клиентской базы, лежащая открытым текстом в чужом объектном хранилище, — сама по себе инцидент с ПДн.

Правило 3-2-1 и квартальный тест

Схема хранения классическая: три копии данных, на двух разных типах носителей, одна — вне площадки. У нас это локальный диск VPS (быстрое восстановление), второй сервер в другом дата-центре (rsync ночью) и объектное S3-совместимое хранилище (недельные полные архивы). БД — ежедневно, файлы — еженедельно полностью плюс ежедневные инкременты.

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

Харденинг веб-периметра: TLS, fail2ban, 2FA и вариант «только через VPN»

CRM, торчащая в интернет, — это дверь в клиентскую базу. Ниже — слои защиты, которые мы накатываем на каждую инсталляцию, от обязательного минимума до параноидального контура.

TLS и автопродление сертификатов

Только HTTPS, только актуальные версии TLS (1.2/1.3), старые протоколы и слабые шифры выключены, HSTS включён — браузер сотрудника после первого визита просто откажется ходить в CRM по нешифрованному каналу. Сертификаты — Let's Encrypt с автопродлением, и здесь живёт классическая грабля: certbot продлевает сертификат через проверку на порту 80, а если nginx настроен строго и на :80 ничего не отвечает или редирект сделан криво, продление тихо ломается. Симптом обнаруживается через 90 дней в виде красного замка у всего отдела продаж. Поэтому срок сертификата у нас под мониторингом, а не на честном слове.

fail2ban против перебора паролей

Форму логина в открытой инсталляции начинают брутфорсить боты в первые же сутки — это видно по access-логу. Лечится штатно: fail2ban читает лог веб-сервера и банит IP после нескольких неудачных попыток входа. Примерная связка jail и фильтра:

# /etc/fail2ban/jail.d/espocrm.conf
[espocrm]
enabled  = true
port     = http,https
filter   = espocrm
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 10m
bantime  = 1h

# /etc/fail2ban/filter.d/espocrm.conf
[Definition]
failregex = ^<HOST> .* "POST /api/v1/App/user.*" 401

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

2FA, ограничение по IP и VPN-контур

Встроенную двухфакторную аутентификацию по TOTP (одноразовые коды из приложения) мы включаем всем администраторам обязательно, менеджерам — настойчиво рекомендуем. Пароль утекает легко — код из приложения без телефона не утекает. Следующий слой — ограничение доступа к админке по IP офиса на уровне веб-сервера: даже с украденным паролем админа снаружи в настройки не попасть.

А для клиентов, которые не хотят светить CRM в интернет вообще, мы строим контур «только через VPN»: система слушает только внутренний интерфейс, а сотрудники ходят в неё через WireGuard-туннель до офисного роутера. Снаружи не существует ни формы логина, ни самого сайта — сканерам и ботам просто нечего перебирать. Удалёнка при этом работает: WireGuard-клиент есть под все платформы, а на современных офисных роутерах туннель поднимается штатными средствами. Из минусов — чуть больше поддержки: новый сотрудник получает не ссылку, а конфиг туннеля.

Роли и права внутри CRM: минимальные привилегии на практике

Периметр — это полдела: не менее важно, что сотрудник может сделать внутри системы. Здесь EspoCRM даёт всё нужное бесплатно, надо только не полениться настроить.

Базовый принцип — минимальные привилегии. В ролях Espo у каждого действия есть область видимости: свои записи (own), записи команды (team) или все (all). Типовая настройка отдела продаж: менеджер видит и редактирует свои сделки и сделки своей команды, руководитель отдела — всё по отделу, и только директор с админом видят базу целиком. Так увольнение одного менеджера не превращается в утечку всей клиентской базы — он физически не мог её выгрузить.

Второй инструмент — Field Level Security: права на уровне отдельных полей. Классика — суммы договоров и комментарии руководства в карточке компании видят только руководители, а стажёры даже не знают, что такие поля существуют. Настраивается в той же роли, парой кликов.

Третий — аудит. Лента Stream пишет историю изменений по записи: кто поменял стадию сделки, кто удалил контакт, кто переназначил клиента. Когда прилетает вопрос «куда делся контакт Иванова», разбор занимает минуту, а не день перекрёстных допросов. Для чувствительных сущностей мы включаем аудит изменений по ключевым полям сразу при внедрении.

Мониторинг и топ-3 инцидента из нашей практики

Всё, что не мониторится, ломается тихо и обнаруживается в понедельник утром звонком «у нас CRM не открывается». Наш стандартный набор проверок для инсталляции EspoCRM:

• Доступность HTTPS — внешняя проверка, что система отвечает и сертификат валиден;
• Место на диске — вложения писем растут незаметно и быстрее всего;
• Выполнение cron-заданий — на планировщике в Espo держится почта, напоминания и вся фоновая работа;
• Размер таблиц БД — аномальный рост служебных таблиц это ранний симптом проблем;
• Срок сертификата TLS — та самая грабля автопродления из раздела про харденинг.

Алерты уходят инженерам в Telegram: от срабатывания до реакции проходят минуты, а не «до следующего планового визита». Теперь три инцидента, которые мы разбирали чаще всего, — в формате «симптом → причина → лечение»:

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

152-ФЗ и персональные данные: что self-hosted решает, а что нет

Сразу дисклеймер: мы инженеры, а не юристы. Всё ниже — технический взгляд на комплаенс, а не юридическая консультация; политику обработки ПДн и договорную часть согласуйте с профильным специалистом.

Теперь по существу. База CRM — это фамилии, телефоны, почта и история общения с людьми, то есть обработка персональных данных по 152-ФЗ со всеми вытекающими. И здесь self-hosted даёт осязаемое преимущество: требование локализации ПДн граждан РФ решается просто выбором российской площадки. Наши клиентские серверы стоят в дата-центре МТС — российское юрлицо, российская юрисдикция, физическое расположение баз известно с точностью до стойки. Сравните с зарубежным SaaS, где на вопрос регулятора «где физически лежит база» ответить внятно бывает затруднительно.

Технические меры защиты, которые требует закон, закрываются тем самым харденингом из этой статьи: разграничение доступа — роли и Field Level Security, защита каналов — TLS, журналирование — аудит Stream и логи сервера, защита от несанкционированного доступа — fail2ban, 2FA и VPN-контур, сохранность — бэкапы с шифрованием. То есть добросовестная эксплуатация и комплаенс — это во многом один и тот же список работ.

Итоговая позиция такая: с собственным сервером в российском ЦОД разговор с регулятором аргументировать заметно проще, чем с зарубежным облаком, — но разговор всё равно надо готовить.

Производительность на дистанции: когда 2 vCPU перестаёт хватать

Свежепоставленная Espo на 2 vCPU и 4 ГБ памяти летает. Вопрос в том, что будет через два года, когда в базе сотни тысяч записей, десятки гигабайт почты и полсотни активных пользователей. Признаки, что сервер пора расширять или тюнить: списки открываются по несколько секунд, отчёты считаются минутами, поиск «задумывается», а утренний пик логинов кладёт систему в задумчивость.

Прежде чем покупать железо, проходимся по настройкам — чаще всего узкое место там:

• Индексы на кастомные поля. Поля, созданные через Entity Manager, по которым менеджеры фильтруют списки, должны быть проиндексированы — иначе каждый фильтр это полный проход по таблице. Самая частая причина «CRM стала тормозить» на выросшей базе.
• Opcache PHP. Должен быть включён с адекватным объёмом памяти — без него PHP перекомпилирует код на каждый запрос.
• innodb_buffer_pool_size. Дефолт MariaDB рассчитан на калькулятор, а не на CRM. Поднимаем до 50–60% памяти сервера БД, чтобы рабочий набор данных жил в оперативке, а не читался с диска.
• Регулярная чистка. Отработавшие записи очереди заданий, старые логи и почтовые вложения многолетней давности — всё это раздувает базу и бэкапы. Чистка раз в квартал входит в наш регламент.

Если после тюнинга всё равно тесно — вертикальный рост: у любого нормального хостера VPS расширяется до 8–16 vCPU и десятков гигабайт памяти за минуты и небольшую доплату. На нашей целевой аудитории — компании до 50 рабочих мест — этого пути хватает с запасом. Шардинг, кластеры БД и горизонтальное масштабирование на этих объёмах не нужны вовсе; если подрядчик предлагает вам кластер «для надёжности» на 30 пользователей — он продаёт вам свою почасовку, а не решение.

Итог: регламент сопровождения одним списком

Сведу всю статью в одну таблицу — это фактически наш внутренний регламент сопровождения EspoCRM, по которому работают инженеры ITfresh. Забирайте как есть.

Что из этого клиент может делать сам? Честный ответ: всё — если есть кому. Ежедневный блок автоматизируется скриптами один раз и дальше требует только реакции на алерты. Ежемесячные обновления и квартальные восстановления — это те самые 1–3 часа инженера, и вот их я советую отдать тому, кто делает это на потоке: цена ошибки в апгрейде или невосстановимом бэкапе несопоставима со стоимостью абонентки.

На этом эксплуатационная часть серии закрыта: у вас есть регламент обновлений, схема бэкапов 3-2-1, слои харденинга и список типовых инцидентов с лечением. Осталась финальная статья — живой кейс: как мы внедряли EspoCRM бухгалтерской фирме, с цифрами, граблями и результатом в сделках. А если ждать её некогда и вам нужен тот, кто возьмёт вашу CRM на сопровождение уже сейчас, — контакты ниже.