Резервное копирование виртуальных машин: правило 3-2-1 и как защитить данные

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

Материал подготовлен специалистами КРЕДО-С — системного интегратора с лицензиями ФСТЭК России и опытом с 1993 года. Мы внедряем резервное копирование под ключ на российских решениях, поэтому делимся практикой.

Зачем бэкапить виртуальные машины отдельно

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

• Высокая концентрация риска. На одном физическом хосте работают десятки виртуальных машин. Отказ хоста или хранилища выводит из строя сразу все — потеря масштабнее, чем при отказе одного физического сервера.
• Базы данных внутри ВМ. Простое копирование файла работающей виртуальной машины с активной базой даёт «грязную» копию, из которой база может не подняться. Нужно копирование с учётом состояния приложений.
• Шифровальщики целятся в виртуальную инфраструктуру. Современные атаки сначала ищут и уничтожают резервные копии, а потом шифруют рабочие машины — чтобы не оставить пути к восстановлению без выкупа.
• Скорость восстановления критична. Когда встал хост с десятком ВМ, важно не просто иметь копию, а быстро развернуть машины обратно. Это требует продуманной схемы, а не разовых снимков.

Грамотное резервное копирование снимает эти риски: при любом сбое — от отказа диска до атаки — вы восстанавливаете виртуальные машины из проверенных копий за предсказуемое время.

Какие сбои угрожают виртуальным машинам

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

• Атака шифровальщика. Вредонос проникает в сеть, шифрует файловые серверы, базы 1С и виртуальные машины. Без изолированной копии остаётся либо платить выкуп без гарантий, либо терять данные, накопленные годами.
• Отказ хоста или хранилища. Выходит из строя сервер виртуализации или система хранения, на которой лежат виртуальные машины. Если копий нет или они на том же хранилище — теряются все машины разом.
• Ошибка администратора. Случайное удаление виртуальной машины, неудачное обновление, перезапись конфигурации. Человеческий фактор — одна из самых частых причин потери данных.
• Повреждение базы данных. База внутри виртуальной машины повреждается из-за сбоя или некорректной операции. Нужна не просто копия машины, а возможность откатить базу на точку времени до повреждения.
• Физическая авария. Пожар, затопление или обесточивание серверной. Если все копии в одном помещении — они гибнут вместе с оборудованием.

Каждый из этих сценариев закрывается разными элементами схемы резервного копирования. Поэтому копирование проектируют не «вообще», а под конкретный набор угроз для вашей инфраструктуры.

Что такое правило 3-2-1

Правило 3-2-1 — это базовый отраслевой стандарт надёжного резервного копирования. Расшифровывается просто:

• 3 копии данных — оригинал плюс две резервные копии. Одна копия — это не резервирование, а иллюзия защиты.
• 2 разных типа носителей — копии хранятся на разных устройствах или технологиях (например, дисковый массив и сетевое хранилище). Отказ одного типа не уничтожает все копии разом.
• 1 копия вне основной площадки — хотя бы одна копия хранится отдельно: в другом ЦОДе, облаке или изолированном хранилище. Это спасает при пожаре, затоплении серверной или атаке, охватившей всю локальную сеть.

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

Правило 3-2-1 — это минимум, а не максимум. Для критичных систем схему усиливают: добавляют больше копий, разносят их по нескольким площадкам, применяют неизменяемое хранение. Но даже базовое соблюдение 3-2-1 кардинально снижает риск безвозвратной потери данных.

RPO и RTO простыми словами

Прежде чем настраивать копирование, нужно ответить на два вопроса бизнеса. Их формализуют через параметры RPO и RTO:

• RPO (Recovery Point Objective) — сколько данных вы готовы потерять. Если копии делаются раз в сутки, при сбое потеряется до суток работы. Для базы 1С торговой компании это неприемлемо — там RPO измеряют часами, и копии делают несколько раз в день.
• RTO (Recovery Time Objective) — за какое время нужно восстановить работу. Если простой критичной системы дольше нескольких часов означает серьёзные потери, схема резервного копирования и оборудование подбираются так, чтобы уложиться в это время.

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

Способы резервного копирования виртуальных машин

Виртуальные машины копируют по-разному, в зависимости от того, что именно нужно защитить и как быстро восстанавливать:

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

На практике способы комбинируют: образ машины для аварийного восстановления плюс копирование баз с журналами для точного отката. Конкретную схему подбирают под критичность каждой системы и требования к RPO и RTO.

Защита резервных копий от шифровальщиков

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

Поэтому защищают сами копии:

• Изоляция от продуктивной сети. Копия по правилу 3-2-1 хранится отдельно — в облаке или на изолированном хранилище, до которого шифровальщик из рабочей сети не дотянется.
• Неизменяемые (иммутабельные) копии. Настраивается хранение, при котором копию нельзя удалить или перезаписать до истечения срока — даже с правами администратора. Вредонос не сотрёт бэкап, даже захватив сервер.
• Ограничение доступа. Доступ к хранилищу копий отделяется от обычных учётных записей, чтобы скомпрометированный аккаунт не открыл путь к резервным копиям.
• Шифрование копий. Сами копии шифруются, чтобы при краже носителя или доступа к хранилищу данные не утекли.

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

Где хранить резервные копии: облако или локально

Правило 3-2-1 требует копию вне основной площадки, и здесь у компаний два пути — они часто комбинируются:

• Локальное хранилище (NAS или СХД). Копии хранятся на отдельном устройстве в периметре компании. Плюс — данные не покидают контур, восстановление идёт быстро по локальной сети. Минус — нужно своё оборудование, а при физической аварии в той же серверной под угрозой и копии. Поэтому локальное хранилище дополняют второй копией вне площадки.
• Облачное хранилище. Копии уходят в защищённый ЦОД. Плюс — копия вне площадки появляется автоматически, без вложений в собственное оборудование, и переживает локальную аварию. Подходит как раз для выполнения условия «1 копия вне площадки» по правилу 3-2-1.

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

Российские решения вместо ушедшего Veeam

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

• Кибер Бэкап (Киберпротект) — резервное копирование физических и виртуальных серверов, баз данных, рабочих станций. Поддерживает централизованное управление, шифрование, дедупликацию.
• РуБэкап (RuBackup) — система резервного копирования корпоративного уровня для гетерогенных сред, включая российские ОС и СУБД.

Оба решения входят в реестр отечественного ПО, что закрывает требования импортозамещения для госзаказчиков и объектов критической инфраструктуры. Если у вас сейчас Veeam или Acronis, миграцию на российское решение проводят без потери истории копий. Резервное копирование при этом логично увязать с миграцией виртуализации с VMware, если вы меняете и платформу.

Резервное копирование и требования закона

Для многих компаний резервное копирование — не только техническая мера, но и требование регуляторов. 152-ФЗ «О персональных данных» требует сохранности персональных данных и непрерывности их обработки, а проверяющие нередко запрашивают регламент резервного копирования. Для финансового сектора, госструктур и объектов критической информационной инфраструктуры наличие плана резервного копирования и восстановления — часть обязательных требований к непрерывности.

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

Почему «бэкап есть» не значит «бэкап работает»

Самая опасная иллюзия в резервном копировании — уверенность, что раз задания выполняются, то всё под защитой. На практике в момент аварии выясняется неприятное: копии есть, а восстановиться не удаётся. Причины типичны:

• Копии никто не проверял. Задания горят «зелёным», но архивы повреждены или неполны. Без регулярных тестовых восстановлений бэкап — это вера, а не защита.
• Копируется не всё. За кадром остались отдельные базы, конфигурации или виртуальные машины. Восстановили часть — бизнес всё равно стоит.
• Все копии в одном месте. Нет копии вне площадки — и шифровальщик или отказ хранилища уничтожает данные вместе с бэкапами.
• Снапшот приняли за бэкап. Снимок хранится в той же системе и не спасает при её отказе.

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

Проверьте, защищены ли ваши данные. КРЕДО-С проведёт аудит текущего резервного копирования, найдёт разрывы и настроит схему с проверкой восстановления. Заказать аудит резервного копирования — бесплатно.

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

Сведём практику в понятный порядок действий:

1. Определите критичность систем. Разделите виртуальные машины по важности: что останавливает бизнес при потере, а что терпит. Под каждую категорию — свои RPO и RTO. 2. Спроектируйте схему по правилу 3-2-1. Три копии, два типа носителей, одна вне площадки. Для критичных систем — с неизменяемым хранением. 3. Выберите решение. Российское резервное копирование (Кибер Бэкап, РуБэкап) под вашу платформу виртуализации и объёмы. 4. Настройте расписания и хранение. Частота копий под RPO, сроки хранения, дедупликация и шифрование. 5. Защитите копии. Изоляция от продуктивной сети, неизменяемость, ограничение доступа. 6. Проверяйте восстановление. Регулярные тестовые восстановления и контроль успешности заданий.

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

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

Что в итоге

Резервное копирование виртуальных машин — это не «настроить программу», а выстроить проверяемый процесс. Правило 3-2-1 даёт базовую надёжность, параметры RPO и RTO привязывают схему к реальным потребностям бизнеса, а защита самих копий закрывает главную угрозу — шифровальщиков. И всё это работает только при регулярной проверке восстановления.

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