Топ-5 реальных способов восстановить данные после сбоя: инструкция для бизнеса

Резервное копирование виртуальной машины — самый надежный способ защитить данные ВМ на длительный срок.

Резервная копия ВМ — это копия содержимого виртуальной машины, которая изолирована от основной ВМ. Согласно правилу «3-2-1», для надежного хранения и защиты данных следует иметь три резервные копии, которые нужно хранить на двух различных устройствах, причем одна из копий должна находиться вне офиса или дома, например, в облаке.

В случае сбоя виртуальной машины, хранилища или потери данных восстановить ВМ можно как из полной (Full), так и из инкрементальной (Increment) резервной копии. В обоих случаях восстановить ВМ можно либо в исходную виртуальную машину с прежним именем и настройками, либо в новую, а также на последнее состояние или на любую точку восстановления.

Полезно: Резервные копии подходят для долгосрочного хранения, не зависят от исходной ВМ, а файлы в резервной копии доступны не только для чтения, но и для изменения. Чем больше резервная копия, тем дольше по времени будет длиться процесс восстановления ВМ.

Когда эффективно: вирус, кибератака, катастрофа, уничтожение или повреждение данных.

Для защиты данных виртуальных машин можно использовать и снапшоты (snapshot). Это точная копия состояния виртуальной машины на определённый момент времени, включая данные, настройки, память и состояние дисков. Она позволяет в любой момент вернуть систему к сохраненной конфигурации. Важно понимать, что снапшот — это не резервная копия, а средство быстро и удобно вернуть ВМ в то состояние, в котором машина находилась до обновления ОС или установки нового ПО.

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

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

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

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

Для реализации Active-Active DR используются различные технологии, включая репликацию виртуальных машин. Это позволяет создать точные копии в облачном сервисе, синхронизировать их и быстро восстановить работу на резервной площадке. Копии также можно хранить в независимых друг от друга ЦОДах в разных локациях.

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

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

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

Just-in-Time Recovery — способ восстановления, при котором доступ к данным или сервисам из резервной копии предоставляется по мере запроса, а не после полного завершения. Идея аналогична концепции JIT в производстве: не всё сразу, а ровно столько, сколько нужно — и когда необходимо. Пользователь получает доступ к востребованным данным сразу, пока все остальные файлы бэкапа восстанавливаются в фоновом режиме.

Чтобы реализовать этот сценарий, компании нужно подготовить инфраструктуру, выбрать подходящее ПО и внедрить регламент работы. В первую очередь, нужно использовать системы резервного копирования с функцией монтирования резервных копий, поддерживающие подключение образов как виртуальных дисков, например «Кибер Бэкап Облачный» (intent-based networking). Это позволит «поднять» необходимые файлы или данные прямо из бэкапа и дать пользователям к ним доступ.

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

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

Ленточная библиотека подойдет компаниям, которым важна стоимость хранения и не так важна оперативность восстановления всех данных и инфраструктуры, например, когда допустим даунтайм в 24-48 часов. А вот компаниям, которым важно получить бэкап всей своей инфраструктуры за секунды, подойдут высокопроизводительные MVNe-накопители с повышенной емкостью.

Когда эффективно: подход с архивным пулом – это резерв на случай катастрофы. Он дает возможность вернуть систему к «чистой» точке, не затронутой атакой, пусть и с задержкой в несколько часов, а также потерей самых свежих данных. Но в условиях полной компрометации — это иногда единственный шанс на восстановление.

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