Резервное копирование CRM/ERP: регламент по частоте и хранению

Зачем CRM/ERP нужен регламент бэкапов

CRM/ERP хранит данные, без которых бизнес быстро встает: продажи, деньги, отгрузки, договоры, права доступа. Когда есть четкий регламент, резервное копирование CRM/ERP перестает быть разовой задачей администратора и становится понятным процессом: что копируем, как часто, где держим копии и кто отвечает.

Критичны не только заказы и проводки, но и все, что помогает системе работать предсказуемо:

• база данных (сделки, счета, платежи, остатки)
• справочники и настройки (номенклатура, контрагенты, цены, налоговые правила)
• документы и вложения (акты, договоры, сканы)
• интеграции и очереди обмена (кассы, склад, банк-клиент, EDI)
• учетные записи и роли (кто что видит и может менять)

Полезно сразу разделить два риска: потерю данных и простой системы. Потеря данных - это когда пропадает кусок истории (например, за последние 6 часов нет заказов). Простой - когда данные на месте, но работать нельзя (упало приложение, кончился диск, сломалась сеть). Регламент нужен, чтобы заранее договориться, что для вас хуже, и какие действия запускаются в каждом случае.

Бэкап без восстановления не считается защитой. Частая ситуация: копии создаются, но никто не проверял, что они открываются, что хватает ключей шифрования, и что восстановление реально укладывается в допустимое время.

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

Цели и показатели: RPO, RTO и критичность данных

Регламент начинается не с выбора инструмента, а с ответов на два вопроса: сколько данных вы готовы потерять и как быстро система должна вернуться в работу. Без этого резервное копирование CRM/ERP легко превращается в набор копий, который не совпадает с ожиданиями бизнеса.

RPO (Recovery Point Objective) - допустимая потеря данных по времени. Если RPO = 15 минут, значит в худшем случае вы теряете изменения за последние 15 минут: заказы, оплаты, статусы, переписку. RTO (Recovery Time Objective) - время на восстановление сервиса до рабочего состояния. Если RTO = 2 часа, то через 2 часа пользователи должны снова работать, даже если часть отчетов или интеграций временно недоступна.

Чтобы RPO и RTO были реалистичными, разделите данные по критичности и задайте цель для каждого уровня:

• Критично: продажи, склад, оплаты, учетные записи, права доступа
• Важно: аналитика, витрины данных, истории изменений
• Может подождать: архивы, старые вложения, тестовые среды

Пример: отдел продаж требует RPO 30 минут и RTO 1 час, а бухгалтерия согласна на RPO 24 часа, если закрытие месяца не страдает. Тогда для критичных данных вы делаете более частые копии и быстрый сценарий восстановления, а для второстепенных - редкие архивные копии.

Дальше проверьте ограничения по окнам обслуживания и нагрузке. Тяжелые операции (полные копии, консистентные снимки больших баз, выгрузка файлов) лучше планировать ночью или в периоды низкой активности. Если тихих окон нет, зафиксируйте это в регламенте и заложите технические меры: более частые инкрементальные копии, репликацию или разнос задач по времени.

Частота копирования: как выбрать режим под вашу систему

Частота бэкапов в CRM/ERP зависит не от привычки делать раз в сутки, а от того, сколько данных вы готовы потерять и как быстро должны поднять работу. Даже при одинаковой системе у отдела продаж и бухгалтерии будут разные пики нагрузки и разные риски.

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

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

Если база поддерживает журналы транзакций, их копирование позволяет снизить RPO до минут. Это важно там, где каждая заявка или платеж критичны.

Практичная схема, которую часто берут за основу для регламента бэкапов:

• полная копия 1 раз в неделю в самое тихое окно
• ежедневно дифференциальная или несколько инкрементальных в течение дня
• журналы транзакций каждые 5-15 минут для ключевых баз
• отдельный бэкап перед обновлениями, интеграциями и массовыми загрузками

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

Что именно нужно резервировать в CRM/ERP

Чтобы резервное копирование CRM/ERP действительно спасало, важно копировать не только базу данных. В аварии часто ломается не таблица, а связка: файлы, настройки, интеграции, лицензии, доработки.

Минимальный набор, без которого восстановление будет неполным

Удобно разделить компоненты на группы и понимать, где каждая из них лежит и как восстанавливается:

• Операционные базы данных (основная БД, журналы транзакций, служебные БД, если есть)
• Файловое хранилище CRM/ERP (вложения, сканы, документы, выгрузки, обмены с внешними системами)
• Конфигурация приложения и среды (файлы конфигурации, параметры подключения, расписания заданий, очереди)
• Интеграции и секреты (API-токены, пароли, ключи шифрования, сертификаты, параметры обмена с 1С, почтой, телефонией и т.д.)
• Пользовательские доработки (скрипты, плагины, печатные формы, отчеты, шаблоны, хранимые процедуры)

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

Инвентаризация: что где хранится и кто владелец

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

• что именно резервируем и где это физически хранится (сервер, виртуальная машина, облако, NAS)
• кто владелец данных (ИТ, бизнес-подразделение, подрядчик) и кто дает доступ
• как восстановить каждый компонент (шаги, учетные записи, лицензии, зависимости)
• где проверять результат (признаки что система работает: вход, поиск, создание сделки, открытие вложения)

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

Хранение и ротация: сроки, площадки, неизменяемые копии

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

Для резервного копирования CRM/ERP обычно работает понятная схема сроков, которую легко объяснить бизнесу и проверять:

• ежедневные копии: хранить 7 дней
• недельные копии: хранить 30 дней
• месячные копии: хранить 90 дней
• архив месяца: хранить 12 месяцев
• архив года: хранить 3-7 лет (если требуют политика и закон)

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

Ротация и очистка должны быть назначены на конкретную роль, а не на абстрактное ИТ. В регламенте фиксируют: кто следит за заполнением хранилища, кто подтверждает удаление старых копий и что делать при риске переполнения (например, приостановить второстепенные задания, расширить хранилище, перевести часть архивов на более дешевый носитель).

По площадкам полезно держаться принципа 3-2-1: три копии, на двух разных типах хранилища, одна копия вне основной площадки. Это может быть отдельный сервер, отдельное хранилище и удаленная площадка или дата-центр.

Отдельный пункт - неизменяемые копии (immutable). Они защищают от шифровальщиков и ошибок админа: даже с правами доступа нельзя тихо подчистить историю. В регламенте укажите, какие копии делаются неизменяемыми (например, недельные и месячные), на какой срок и кто имеет право менять эту настройку. Если инфраструктуру собирает системный интегратор, заранее обсудите поддержку неизменяемых репозиториев на вашем оборудовании и на удаленной площадке.

Шифрование и ключи: как не потерять доступ к бэкапам

Шифрование для бэкапов CRM/ERP нужно не для галочки. Резервные копии часто содержат больше данных, чем рабочая база: персональные данные, финансовые документы, вложения и логи. Если утечет архив, ущерб будет сопоставим со взломом продакшена.

Шифрование должно быть включено в двух местах: при передаче и при хранении. При передаче - защита канала между сервером CRM/ERP, хранилищем и площадкой репликации. При хранении - шифрование файла или тома на диске, а также шифрование в объектном хранилище, если оно используется. В политике резервного копирования CRM/ERP полезно прописать прямо: копии без шифрования считаются недействительными.

Управление ключами

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

Минимальный набор правил:

• храните ключи отдельно от бэкапов (другая система, другой доступ)
• назначьте владельца ключей (обычно ИБ) и порядок экстренного доступа
• делайте ротацию ключей по расписанию и при увольнении сотрудников
• держите резерв ключей в защищенном виде и регулярно проверяйте, что он читается

Разделение прав

Типичная ошибка: администратор CRM/ERP одновременно управляет бэкапами и ключами. Тогда один компрометированный аккаунт дает доступ ко всему. Лучше разделить роли:

• админ системы делает копии и видит статус
• ИБ управляет ключами и политиками доступа
• отдельный сотрудник или группа подтверждает операции восстановления

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

Ответственность и контроль: кто делает и кто проверяет

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

Разделите обязанности так, чтобы один человек выполнял, а другой проверял. Обычно хватает четырех ролей:

• владелец системы (бизнес): задает приоритеты, подтверждает RPO/RTO и сроки хранения, принимает риски
• администратор (ИТ): настраивает расписание, хранение, ротацию, выполняет восстановления по заявке
• ИБ: утверждает шифрование, доступы, правила хранения ключей, контролирует соблюдение
• ответственный за контроль (ИТ или внутренний аудит): регулярно проверяет отчеты, инициирует тестовые восстановления

Чтобы контроль был реальным, ведите журналы действий. В логах должно быть видно: старт задания, итог (успех/ошибка), объем и состав, место хранения, а также любые ручные операции (удаление копии, изменение политики, запуск восстановления). Важно фиксировать не только что случилось, но и кто сделал.

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

Минимальный набор документов должен быть коротким, но актуальным:

• схема бэкапов (что копируем и куда)
• расписание и сроки хранения
• перечень площадок и правила доступа
• контакты ответственных и порядок эскалации
• короткая инструкция по восстановлению и проверке

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

Пошагово: как оформить и внедрить регламент бэкапов

Чтобы резервное копирование CRM/ERP работало в реальной аварии, регламент должен быть не политикой на бумаге, а понятной инструкцией: что делаем, когда делаем, где лежит, кто отвечает и как проверяем результат.

5 шагов, которые лучше делать по порядку

1. Зафиксируйте, что именно защищаете: базы данных, файлы вложений, интеграции, ключевые отчеты. Рядом запишите цели по RPO/RTO для каждой группы данных (например, заказы - потеря не больше 1 часа, восстановление за 4 часа).

2. Выберите типы копий и расписание не в целом, а по времени и нагрузке. Обычно это сочетание полных и инкрементальных копий, плюс отдельный экспорт критичных справочников. В регламенте укажите точные окна: дни недели, часы, длительность, ограничения по трафику.

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

4. Включите шифрование и правила доступа: кто имеет право запускать бэкап, кто может читать, кто может удалять. Отдельно пропишите, где хранятся ключи, кто их меняет и как действовать при смене сотрудников. Иначе легко остаться с бэкапом без доступа.

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

После этого оформите регламент как набор рабочих артефактов: схема данных, расписание, матрица ответственности, инструкция восстановления и журнал проверок. Если внедрение делает внутренний IT-отдел вместе с интегратором, удобнее сразу закрепить правило: один выполняет операции, другой подтверждает результат по отчету и выборочной проверке.

Если вы привлекаете партнера по системной интеграции, стоит заранее согласовать не только настройку, но и дальнейшую поддержку процесса: мониторинг, тестовые восстановления, порядок доступа к ключам. В проектах GSE.kz такой формат обычно помогает избежать ситуации, когда все настроено, но никто не смотрит.

Тестовые восстановления: обязательный минимум и как проводить

Бэкап без проверки легко превращается в файл для галочки: он есть, но восстановиться нельзя. Поэтому тестовое восстановление нужно включать в регламент так же строго, как и само резервное копирование CRM/ERP.

Минимум для большинства компаний - раз в квартал. Если CRM/ERP критична для продаж, производства или финансов, тестируйте чаще: раз в месяц или после каждого крупного обновления (версии приложения, схемы базы, интеграций).

Какие тесты делать

Начните с простого и постепенно усложняйте, чтобы проверять весь путь восстановления:

• точечное восстановление: один файл, отчет, вложение, запись клиента
• восстановление базы данных на отдельный сервер или инстанс
• подъем тестового стенда CRM/ERP из бэкапа под ключ
• проверка восстановления в режиме как при аварии (с ограничением доступа, без подсказок)

После каждого теста важно замерять не только время, но и качество результата.

Что измерять и как оформить протокол

Фиксируйте метрики, чтобы видеть прогресс и находить слабые места:

• время восстановления (факт) и сравнение с целевым RTO
• точка восстановления (какие данные потеряны) и сравнение с RPO
• целостность данных: выборочная сверка документов, справочников, прав
• работоспособность интеграций: почта, телефония, 1С, ESB, API, обмен файлами

Протокол теста должен быть коротким, но однозначным: дата и версия системы, какой бэкап использовали, кто выполнял, шаги, фактические времена, что не получилось, логи ошибок (где уместно) и решение.

Пример: при поднятии стенда из ночной копии база восстановилась за 40 минут, но интеграция с почтовым сервером не стартовала из-за просроченного сертификата. Дальше действия простые: обновить сертификат, добавить проверку сроков в мониторинг, повторить тест в течение недели и закрыть пункт только после успешного повторного восстановления.

Типичные ошибки, из-за которых бэкап не спасает

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

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

Не менее частая ошибка - есть архивы, но нет доступа. Ключи шифрования хранились у одного человека, пароль ушел вместе с уволившимся админом, права на хранилище изменили, учетку заблокировали. Формально бэкап есть, фактически восстановить его нельзя.

Опасно держать бэкапы рядом с продом (на том же сервере, в той же виртуализации, в том же домене). При шифровальщике или компрометации учетных записей часто шифруется и основная система, и резервные копии, потому что доступ к ним одинаковый.

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

И наконец, ручное удаление копий. Когда ротация не автоматизирована, кто-то освобождает место и случайно стирает именно тот период, который нужен для расследования или отката (например, до массового удаления данных).

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

Пример сценария: авария и восстановление по регламенту

Филиальная компания ведет продажи в CRM, а в ERP держит склад и отгрузки. Днем менеджеры оформляют сделки, вечером склад закрывает остатки и печатает накладные. Потерять данные за день неприятно, но потерять неделю уже критично.

Инцидент происходит утром в понедельник: после планового обновления база ERP не стартует, журнал ошибок указывает на повреждение файлов. CRM работает, но интеграция с ERP встала, склад не может отгружать. По регламенту у системы есть целевые RPO 4 часа и RTO 2 часа.

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

Дальше действия идут по чеклисту:

• зафиксировать время отказа и выбрать точку восстановления: последняя успешная полная копия + последняя инкрементальная до сбоя
• поднять восстановление на выделенном сервере или виртуальной площадке (часто быстрее, чем чинить как есть)
• проверить целостность базы и запуск сервисов ERP, затем проверить обмен с CRM
• провести бизнес-проверки: открыть 5-10 типовых документов (заказ, счет, приход, списание), сверить остатки по контрольным позициям
• переключить пользователей и зафиксировать фактическое RTO и объем потерь (фактическое RPO)

Коммуникация тоже часть регламента. ИТ уведомляет бизнес в первые 10-15 минут: что сломалось, что делаем, когда следующий статус. Руководитель ИТ подтверждает прогноз времени, а владелец процесса (например, директор по продажам или начальник склада) принимает результат: система работает, проверки пройдены, расхождения понятны и зафиксированы.

Быстрый чеклист и следующие шаги

Чтобы резервное копирование CRM/ERP работало в аварии, важны не только настройки, но и регулярная проверка.

• зафиксированы RPO и RTO для CRM/ERP и приоритеты данных (что восстанавливаем в первую очередь)
• настроено расписание бэкапов и ротация: сколько хранить ежедневные, недельные, месячные копии
• определены площадки хранения: минимум две, плюс защита от удаления (неизменяемые копии, где это возможно)
• включено шифрование, описано где лежат ключи, кто имеет доступ, как действовать при смене сотрудников
• назначены роли: кто делает, кто проверяет, кто принимает результат; есть уведомления об ошибках и регулярный контроль успешности

Дальше проверьте, что есть следы практики, а не только правила. Должны быть протоколы тестовых восстановлений: дата, что именно восстанавливали (база, файлы, интеграции), сколько заняло времени, какие были проблемы и что изменили после.

Если нужно быстро привести ситуацию в порядок, начните с трех шагов:

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

2. Проведите пробное восстановление на отдельной среде. Например, восстановите систему на состояние вчера 18:00 и проверьте вход пользователей, отчеты, обмен с 1С, почтой и телефонией.

3. Зафиксируйте улучшения и сроки: что поправить в расписании, хранении, доступах, и когда повторить тест.

Если для этого нужна надежная инфраструктура и внедрение под ключ, имеет смысл обсуждать вариант на отечественном оборудовании с системной интеграцией и поддержкой 24/7. Например, GSE.kz (gse.kz) производит серверы и помогает собирать инфраструктуру для резервного копирования и восстановления, в том числе на стойках S200 Series."}