Разбор кейса. Когда резервное копирование есть, а восстановиться всё равно нельзя

Этот материал — подробный разбор ситуации, в которой формально резервное копирование существовало, но в момент аварии восстановление оказалось невозможным. Кейс основан на реальном опыте нашего клиента.

Речь идёт о компании среднего размера, где основная операционная нагрузка была завязана на 1С и SQL-базу. Через эти системы проходили продажи, документооборот и управленческий учёт. Остановка сервисов означала фактическую остановку бизнеса.

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

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

Естественной реакцией стало восстановление из резервной копии. Именно на этом этапе и вскрылась ключевая проблема.

Файлы резервных копий были на месте. Размер архивов соответствовал ожиданиям, внешне они выглядели корректно. Однако при попытке восстановления процесс либо завершался ошибкой, либо останавливался на раннем этапе.

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

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

1. Копирование «на живую»
   Бэкапы делались на работающую систему. В момент создания копий пользователи продолжали работать в 1С, транзакции не завершались, база находилась в изменяющемся состоянии. Формально процесс копирования завершался успешно, но логическая целостность данных не гарантировалась.
2. Логическая порча данных
   Файлы существовали физически, но были логически повреждены. Это один из самых опасных сценариев: бэкапы есть, отчёты зелёные, а восстановление невозможно. До аварии такая проблема никак себя не проявляет.
3. Нулевое тестирование восстановления
   За всё время эксплуатации инфраструктуры ни разу не выполнялось тестовое разворачивание резервной копии в отдельной среде. Вопрос «сколько времени займёт восстановление» не задавался ни IT-командой, ни бизнесом.

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

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

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

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

Хранилище резервных копий было вынесено в отдельный контур, независимый от основной инфраструктуры. Это снизило риск одновременной потери и рабочих данных, и самих бэкапов.

Ключевым изменением стало регулярное тестирование восстановления. Резервная копия перестала считаться «хорошей» по факту создания — теперь она признавалась рабочей только после успешного разворачивания и запуска сервисов в тестовой среде.

Впервые были зафиксированы параметры допустимого времени простоя и допустимой потери данных. Это позволило связать технические решения с реальными бизнес-рисками, а не абстрактными представлениями о надёжности.

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

В практике ESTT мы регулярно сталкиваемся с ситуациями, когда резервное копирование формально настроено, но сценарии восстановления либо не проверялись, либо не соответствуют реальным требованиям бизнеса по времени и потерям данных. До первого серьёзного сбоя это остаётся незаметным.

В ближайшие дни мы опубликуем отдельный материал, в котором разберём, почему резервное копирование и аварийное восстановление — это разные задачи, какие архитектурные подходы применяются для DR на практике и какие ошибки чаще всего делают инфраструктуру уязвимой именно в критический момент.

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

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

Надёжная инфраструктура начинается не с вопроса «куда копируются данные», а с вопроса «через сколько бизнес должен вернуться к работе и что он готов потерять».