Облачные сервисы часто воспринимаются как данные, которые уже защищены поставщиком. Это опасное упрощение. Провайдер отвечает за свою платформу, но компания все равно отвечает за то, какие данные использует, кто имеет доступ, как обнаруживается ошибка и можно ли восстановить нужную версию в нужный срок.
План резервного копирования должен включать не только серверы и файлы в офисе, но и рабочие облачные сервисы: почту, документы, облачные диски, CRM, телефонию, чаты, таск-трекеры, базы знаний, бухгалтерские выгрузки, интеграции и настройки. Иначе самый важный контур может оказаться вне восстановления.
Какие облачные данные искать
Начинать стоит с инвентаризации, а не с выбора инструмента backup. В разных компаниях критичные данные могут жить в неожиданных местах: коммерческие предложения в облачном диске, история клиента в CRM, записи звонков в телефонии, согласования в чате, регламенты в базе знаний, выгрузки из учетной системы в общем хранилище.
| Сервис | Какие данные могут быть критичными | Типовой риск |
|---|---|---|
| Почта и календарь | Переписка, вложения, встречи, контакты | Удаление, компрометация ящика, потеря истории при миграции |
| Облачные документы | Договоры, таблицы, регламенты, совместные папки | Ошибочное удаление, неверные права, потеря версии |
| CRM | Сделки, клиенты, задачи, коммуникации | Массовая правка, ошибка интеграции, сложный экспорт |
| Телефония | Записи звонков, маршруты, история обращений | Короткий срок хранения, потеря доказательной записи |
| Чаты и задачи | Решения, файлы, история согласований | Нет понятного восстановления отдельного обсуждения |
| Облачные настройки | Права, шаблоны, интеграции, вебхуки | Сервис работает, но процессы нарушены после сброса настроек |
Разделить ответственность с поставщиком
Надежность облачной платформы не равна восстановимости данных компании. Поставщик может обеспечивать доступность сервиса, репликацию и защиту от отказа своего оборудования, но это не всегда покрывает ошибочное удаление, злонамеренное действие пользователя, массовую синхронизацию неверных данных, истечение срока хранения корзины или необходимость выгрузить историю при смене системы.
Поэтому для каждого сервиса нужно ответить на пять вопросов: кто владелец данных, кто управляет доступами, какие версии можно вернуть, сколько хранится удаленное, как получить полный экспорт и кто проверял восстановление. Если на эти вопросы нет ответа, сервис нельзя считать покрытым планом backup.
Сценарии потери важнее названия сервиса
Один и тот же SaaS может быть некритичным справочником или центральной системой продаж. Поэтому план строится от сценариев: удалили папку, испортили таблицу, потеряли доступ администратора, интеграция перезаписала поля, сотрудник ушел и забрал владение документами, сервис меняет тариф или становится недоступным.
Для каждого сценария нужно определить, как быстро его обнаружат. Если ошибку в CRM находят через две недели, короткая корзина или недельный экспорт не помогут. Если записи звонков нужны для разбора споров, срок хранения должен соответствовать реальному периоду, когда такие споры возникают.
| Сценарий | Что проверить заранее |
|---|---|
| Ошибочное удаление | Корзина, версии, права восстановления, срок хранения |
| Массовая неверная правка | История изменений, экспорт до интеграции, откат полей |
| Потеря доступа | Резервный администратор, владелец домена, процедура подтверждения |
| Смена сервиса | Полный экспорт, формат данных, вложения, история и связи |
| Сбой интеграции | Границы синхронизации, журнал изменений, точка возврата |
Экспорт нужно проверять, а не просто находить в меню
Наличие кнопки экспорта не гарантирует восстановление. Экспорт может выгружать только часть полей, терять вложения, не сохранять связи между объектами, требовать прав администратора или занимать больше времени, чем допустимо для бизнеса.
Минимальная проверка для критичных сервисов - получить тестовый экспорт, открыть его вне исходной платформы, понять состав данных и зафиксировать ограничения. Для части систем достаточно регулярной выгрузки отчетов и документов. Для других нужен специализированный backup или отдельная процедура архивации. Выбор зависит от критичности, объема, скорости изменений и сценариев восстановления.
Облачные сервисы в общей карте backup
Облачные данные должны попасть в ту же карту резервного копирования, где описаны серверы и файловые ресурсы. В карте указывают сервис, владельца, тип данных, критичность, способ восстановления, срок хранения, частоту экспорта или backup, место хранения, доступы и дату последней проверки.
Важно не смешивать backup и удобную синхронизацию. Облачный диск, синхронизированный на компьютеры, может быстро распространить ошибочное удаление или повреждение. Синхронизация помогает доступности, но не заменяет независимую точку восстановления, если нужно вернуться к состоянию до ошибки.
Граница ответственности подрядчика
IT-подрядчик может помочь провести инвентаризацию облачных сервисов, описать сценарии потери, настроить регулярные проверки, включить облачные данные в карту backup и контролировать уведомления. Но владелец бизнеса или сервиса должен подтвердить критичность данных, допустимую потерю, срок хранения и право доступа к экспорту.
Один ответственный подрядчик с командой снижает риск разрозненных решений, потому что серверы, облака, доступы и восстановление рассматриваются вместе. Это не означает, что вся ответственность переносится с компании: решения о ценности данных и допустимых сроках остаются управленческими.
Итог: облачный сервис нужно включать в план резервного копирования, если в нем есть рабочие данные, история, настройки или доказательства, без которых компания не сможет нормально восстановить процесс. Проверяйте не обещание облака, а конкретные сценарии потери, экспорт, сроки хранения и владельцев восстановления.