Резервное копирование EspoCRM: как настроить backup правильно

Оптовая компания в Воронеже, 180 000 контактов в базе, 7 лет истории сделок. Сервер упал в пятницу вечером из-за аппаратной неисправности хостинга. Резервные копии делались, но хранились на том же физическом диске. Оказалось, что и основные данные, и резервные копии потеряны одновременно.

Восстановление заняло 11 рабочих дней, частично из старых email-переписок и Excel-таблиц. Часть данных была потеряна безвозвратно. Компания после этого случая настроила ежедневное резервное копирование в два независимых хранилища.

Настройка backup EspoCRM занимает несколько часов. Последствия его отсутствия могут быть несопоставимо большими.

Что именно нужно копировать в EspoCRM

Self-hosted EspoCRM состоит из трёх независимых частей, каждая из которых нуждается в резервном копировании.

База данных MySQL/MariaDB. Здесь хранится всё: контакты, сделки, задачи, история изменений, пользователи, настройки, Workflow, шаблоны писем. Это главная часть резервной копии. Без актуальной резервной копии базы данных всё остальное бесполезно.

Папка uploads/. Вложения к записям: документы, фотографии, файлы, загруженные пользователями. Находится по пути `[директория установки EspoCRM]/uploads/`. Объём зависит от числа вложений. У активно используемых систем папка uploads/ может занимать несколько гигабайт.

Папка custom/. Кастомные модули, расширения, изменения в логике. Находится по пути `[директория установки EspoCRM]/custom/`. Без этой папки система после восстановления будет работать, но потеряет все кастомизации.

Папка data/. Содержит пользовательские настройки и некоторые конфигурационные файлы. В паре с базой данных обеспечивает полное восстановление системы.

Файл config.php. Основной конфигурационный файл EspoCRM: параметры подключения к базе данных, ключи, хост. Находится в корне установки. Необходим для восстановления.

Для полного восстановления системы на новом сервере нужны: дамп базы данных + папки uploads/, custom/, data/ + файл config.php.

Три варианта хранения резервных копий

Хранение только на том же сервере. Неприемлемо. При аппаратном сбое, пожаре в дата-центре или уничтожении сервера злоумышленниками основные данные и резервные копии исчезают одновременно. Этот вариант создаёт ложное ощущение защищённости.

Хранение на внешнем облачном хранилище. Рекомендуемый базовый уровень. Резервные копии автоматически загружаются в отдельный сервис: Яндекс Object Storage, Selectel Cloud Storage, VK Cloud Storage, Timeweb S3-совместимое хранилище. Все перечисленные варианты находятся в России, что важно для соответствия 152-ФЗ. Стоимость хранения 50 ГБ: 100-300 рублей в месяц.

Хранение в двух независимых местах. Оптимальный уровень для компаний с критичными данными. Резервная копия отправляется одновременно в облачное хранилище и на второй сервер в другом дата-центре. Это защищает от одновременной недоступности обоих мест хранения (крайне маловероятный, но ненулевой сценарий).

Ротация резервных копий. Хранить резервные копии за каждый день в течение последних 30 дней. За каждую неделю в течение последних 3 месяцев. Это позволяет восстановиться не только после технического сбоя, но и после обнаружения случайного удаления данных спустя несколько дней.

Настройка автоматического резервного копирования

Ручное резервное копирование ненадёжно: человек забывает, болеет, уходит в отпуск. Backup должен выполняться автоматически по расписанию.

Шаг 1: дамп базы данных. Команда для MySQL/MariaDB:

``` mysqldump --single-transaction --routines --triggers \ -h localhost -u [пользователь] -p[пароль] [имя_базы] \ | gzip > /backup/espocrm-db-$(date +%Y%m%d).sql.gz ```

Ключ `--single-transaction` гарантирует консистентность дампа без блокировки таблиц. EspoCRM продолжает работать во время создания резервной копии.

Шаг 2: архивирование файлов. Файлы uploads/, custom/, data/ и config.php:

``` tar -czf /backup/espocrm-files-$(date +%Y%m%d).tar.gz \ /var/www/espocrm/uploads \ /var/www/espocrm/custom \ /var/www/espocrm/data \ /var/www/espocrm/config.php ```

Шаг 3: загрузка в облачное хранилище. Утилита rclone поддерживает S3-совместимые хранилища (Яндекс, Selectel, VK). После настройки:

``` rclone copy /backup/ remote:espocrm-backups/$(date +%Y%m%d)/ ```

Шаг 4: cron-задание. Добавляется через `crontab -e`:

``` 0 3 * /scripts/espocrm-backup.sh >> /var/log/espocrm-backup.log 2>&1 ```

Запуск ежедневно в 3:00 ночи. Время выбрано с учётом минимальной активности пользователей.

Шаг 5: очистка старых резервных копий. После загрузки в облако локальные копии можно удалять, оставляя только последние 7 дней:

``` find /backup/ -name "espocrm-*" -mtime +7 -delete ```

Резервное копирование через панель администратора EspoCRM

EspoCRM имеет встроенный инструмент создания резервных копий в разделе «Управление», пункт «Backup». Он создаёт архив базы данных и файлов системы прямо через интерфейс без доступа к серверу по SSH.

Ограничения встроенного инструмента. Архив создаётся на том же сервере в папке `data/backup/`. После создания нужно вручную скачать его и перенести на внешнее хранилище. Автоматизировать этот процесс через встроенный интерфейс нельзя — только через cron и скрипты.

Когда встроенный инструмент полезен. Перед обновлением EspoCRM на новую версию. Перед установкой нового кастомного модуля. Как разовый «контрольный снимок» состояния системы в нужный момент.

Для автоматического backup нужны скрипты. Встроенный инструмент не заменяет настроенный cron. Для компаний, где нет системного администратора, это работа, которую выполняет интегратор при внедрении EspoCRM.

Как настроить Workflow в EspoCRM для уведомления о статусе backup

Парадокс в том, что EspoCRM сам может информировать о состоянии своего резервного копирования. Это делается через Workflow с триггером по расписанию или через внешний скрипт, который создаёт запись в EspoCRM при успешном или неуспешном завершении backup.

Практическая схема: bash-скрипт после создания резервной копии делает HTTP-запрос к API EspoCRM и создаёт запись в кастомном модуле «Системные события» с полями: дата, статус (успех/ошибка), размер архива, место хранения. Администратор открывает этот модуль и видит историю backup за любой период.

Альтернатива проще: скрипт отправляет письмо или Telegram-сообщение с результатом. При успехе: «Backup 2026-07-06 выполнен, размер 2.3 ГБ». При ошибке: «ОШИБКА backup 2026-07-06: код выхода 1, проверьте лог».

Как проверить, что резервное копирование работает

Резервная копия, которую никогда не тестировали, может оказаться нерабочей в критический момент. Частые проблемы: файл создаётся, но с ошибкой внутри; пароль от базы данных изменился, скрипт не обновили; дамп прерывается по таймауту при большой базе.

Ежемесячная проверка. Раз в месяц восстанавливать резервную копию на тестовую среду (отдельный VPS или Docker-контейнер) и проверять, что система работает. Убедиться, что данные актуальны (видны последние сделки), кастомные модули работают, пользователи могут войти.

Мониторинг выполнения backup. Добавить в скрипт отправку уведомления после успешного завершения: письмо на email администратора или сообщение в Telegram-бот. Если уведомление не пришло в ожидаемое время, нужно проверить, что пошло не так.

Проверка целостности архивов. После создания архива проверять его целостность: ``` gzip -t /backup/espocrm-db-$(date +%Y%m%d).sql.gz && echo "OK" || echo "ERROR" ```

Восстановление EspoCRM из резервной копии

При необходимости восстановления данных последовательность действий следующая.

1. Развернуть чистую установку EspoCRM на новом сервере. Установить PHP, веб-сервер, MySQL той же версии, что и в резервной копии.

2. Восстановить базу данных: ``` gunzip < /backup/espocrm-db-YYYYMMDD.sql.gz | mysql -u [пользователь] -p[пароль] [имя_базы] ```

3. Восстановить файлы: ``` tar -xzf /backup/espocrm-files-YYYYMMDD.tar.gz -C / ```

4. Проверить config.php. Если новый сервер имеет другие параметры MySQL (другое имя базы, пользователь, пароль), обновить config.php.

5. Пересоздать кэш. В разделе «Управление», пункт «Перестроить» запустить очистку кэша и пересборку.

6. Проверить работоспособность. Войти в систему, убедиться, что данные на месте, Workflow активны, интеграции работают.

Полное восстановление при наличии актуальной резервной копии занимает 1-3 часа в зависимости от объёма данных и скорости нового сервера.

Резервное копирование и требования 152-ФЗ

Для компаний, работающих с персональными данными, резервное копирование является не только технической, но и юридической задачей.

Статья 19 152-ФЗ требует принятия мер по предотвращению уничтожения или изменения персональных данных. Регулятор трактует это как обязанность иметь процедуры, обеспечивающие восстановление данных при инцидентах.

Практические требования:

• Резервные копии должны храниться на серверах в России (если в CRM хранятся персональные данные российских граждан)
• Хранилище резервных копий должно быть защищено не хуже основного сервера
• Необходимо документировать процедуру резервного копирования как часть политики информационной безопасности

Яндекс Object Storage, Selectel, VK Cloud Storage как российские провайдеры соответствуют требованиям хранения в РФ. При выборе хранилища сохраняйте договор с указанием расположения серверов.

Типичные ошибки при настройке backup EspoCRM

Резервная копия только базы данных без файлов. Восстановление системы без папки uploads/ означает потерю всех прикреплённых документов. Без папки custom/ кастомные модули нужно восстанавливать вручную. Всегда включайте в backup все три компонента.

Хранение в одном месте. Описано выше. Даже один дополнительный внешний destination кратно снижает риск полной потери данных.

Скрипт без обработки ошибок. Если MySQL недоступен или диск заполнен, скрипт завершается тихо. Добавьте проверку кода возврата и уведомление при ошибке.

Нет ротации старых копий. Диск постепенно заполняется, сервер падает уже по другой причине. Настройте удаление копий старше N дней автоматически. Проверяйте заполненность диска после каждого backup: добавьте в скрипт проверку свободного места и уведомление, если оно упало ниже 20%.

Время создания backup не учитывает пиковую нагрузку. Если backup запускается в 12:00, а в это время команда активно работает, дамп базы данных может замедлить систему. Оптимальное время: 2:00-4:00 ночи, когда пользователи не активны. При использовании ключа `--single-transaction` нагрузка минимальна, но всё равно лучше выбирать время с низкой активностью.

Backup не включает кастомные модули. Разработчик доработал EspoCRM, изменения в папке custom/. При восстановлении базы данных оказывается, что модуль ссылается на поля, которых нет в установке по умолчанию. Восстановление без custom/ приводит к ошибкам.

Кейс: производственное предприятие, Тула

Производитель металлоконструкций, 34 менеджера и инженера в EspoCRM. Система активно кастомизирована: модуль «Производственный заказ», интеграция с 1С:УНФ, кастомные отчёты. В системе 4,5 года истории взаимодействий с клиентами.

До инцидента backup настроен формально: скрипт запускался, но проверка работоспособности не проводилась 8 месяцев. Оказалось, что скрипт падал с ошибкой после смены пароля MySQL 6 месяцев назад. Резервные копии за последние 6 месяцев отсутствовали.

После инцидента (аппаратный сбой VPS, хостинг восстановил сервер, но с потерей части данных) компания смогла восстановить данные только за первые 2,5 года. 2 года истории потеряны.

Что изменили:

• Bash-скрипт с обработкой ошибок и уведомлением в Telegram при любой ошибке
• Хранение в Selectel Object Storage (Россия) и на отдельном VPS в другом дата-центре
• Ротация: 30 ежедневных копий + 12 ежемесячных
• Ежемесячная проверка восстановления на тестовой среде в Docker-контейнере
• Мониторинг: если уведомление об успешном backup не пришло до 4:30 утра, в 9:00 системный администратор получает задачу в EspoCRM

Стоимость настройки надёжного backup: 18 000 рублей (работа разработчика 2 дня). Ежемесячные расходы на хранение: 640 рублей (два хранилища, 80 ГБ данных). Цена вопроса по сравнению с потерянными 2 годами истории выглядит иначе.

Через 3 месяца после настройки backup произошёл ещё один инцидент: случайное удаление крупного раздела контактов одним из менеджеров (ошибка при массовом удалении фильтрованной выборки). Благодаря наличию ежедневной резервной копии данные восстановили за 90 минут. Руководитель оценил это как «окупаемость всей настройки за один случай».

Вопросы о резервном копировании EspoCRM

Как часто нужно делать резервные копии?

Для большинства B2B-компаний достаточно ежедневного резервного копирования. Если команда активно вносит данные в течение дня и потеря даже нескольких часов работы критична, можно настроить резервное копирование дважды в день: в 3:00 и в 15:00. Для компаний с очень интенсивной работой есть вариант репликации базы данных в реальном времени, но это значительно сложнее в настройке.

Сколько места занимают резервные копии?

Зависит от объёма данных и числа вложений. База данных 5 000 контактов + 2 года истории: обычно 200-500 МБ в сжатом виде. Папка uploads/ с активным использованием вложений может занимать 5-20 ГБ. С учётом ротации за 30 дней: хранилище 30-50 ГБ покрывает большинство компаний до 50 пользователей.

Нужно ли резервное копирование при использовании EspoCRM Cloud?

При использовании EspoCRM Cloud резервное копирование выполняет провайдер. Однако рекомендуется периодически делать экспорт ключевых данных (контакты, сделки) через встроенный инструмент экспорта EspoCRM в формате CSV. Это страхует от смены условий провайдера или необходимости срочной миграции на self-hosted.

Что если объём данных очень большой и дамп занимает несколько часов?

При больших базах (несколько ГБ) используют инкрементальное резервное копирование с помощью Percona XtraBackup: копируются только изменения с момента последнего полного дампа. Первый полный дамп делается раз в неделю, ежедневно добавляются только дельта-изменения. Это снижает время создания резервной копии с нескольких часов до 10-15 минут.

Как восстановить только одну запись, которую случайно удалили?

В EspoCRM нет встроенного механизма восстановления отдельных записей. При случайном удалении нужно: развернуть тестовую среду из резервной копии, найти нужную запись, скопировать данные вручную. Для защиты от случайного удаления важных данных настраивается ограничение прав доступа: менеджеры не могут удалять контакты и сделки, только руководитель или администратор.

Наличие работающего backup меняет характер аварий. Без резервных копий авария означает катастрофу: потеря данных, дни или недели восстановления, репутационные потери перед клиентами. С правильно настроенным backup авария означает неудобство: 2-4 часа на восстановление системы, максимальная потеря данных за сутки. Разница принципиальная для любого бизнеса.

Резервное копирование в EspoCRM не требует дорогостоящих решений. Правильно настроенный bash-скрипт, cron и S3-совместимое российское хранилище обеспечивают надёжную защиту данных за несколько тысяч рублей в год. Главное: делать это не «когда-нибудь», а до первого инцидента.

Получить консультацию: поможем настроить надёжное резервное копирование с мониторингом и автоматической проверкой восстановления под вашу инфраструктуру и требования.