Резервное копирование для бизнеса часто считают закрытой задачей: задания настроены, отчёты зелёные. Обратное выясняется в день инцидента: восстановление из резервной копии занимает втрое больше времени, чем закладывали, или копии зашифрованы вместе с серверами. Ниже — правило 3-2-1-1-0, резервное копирование в облако, защита резервных копий от шифровальщиков и проверка восстановления.
Почему бэкап подводит и что меняет правило 3-2-1-1-0
Четыре сценария, в которых резервная копия бесполезна
- Копия там же, где оригинал. Пожар, протечка или отказ контроллера СХД выводят из строя и рабочие системы, и бэкапы.
- Копия доступна по тем же учётным записям. Злоумышленник с правами администратора домена удаляет задания и точки восстановления ещё до запуска шифрования.
- Копия содержит ту же проблему. Логическая порча данных или закладка атакующего попадают во все копии, сделанные до обнаружения. Если глубина хранения короче этого периода, чистой точки не остаётся.
- Из копии никогда не восстанавливались. База в копии несогласованна, ключ шифрования потерян, а восстановление занимает сутки при допустимых четырёх часах.
RAID, репликация и snapshot резервными копиями не являются. Удаление или шифрование сразу отражается на всех дисках массива и на второй площадке, а снимок пропадает вместе с хранилищем. Вернуть систему в прошлое состояние может только резервная копия.
Три копии, два носителя, одна вне площадки, одна неизменяемая, ноль ошибок
Каждая цифра правила закрывает свой класс угроз.
- 3 копии: рабочие данные и две резервные.
- 2 разных типа носителей: дисковый репозиторий и лента, СХД и объектное хранилище. Без общей прошивки и общей партии дисков.
- 1 копия вне площадки: в другом здании или у облачного провайдера.
- 1 неизменяемая или отключённая копия: её нельзя удалить даже с правами администратора.
- 0 ошибок: копии подтверждены восстановлением, а не отчётом об успешном задании.
Облако почти всегда закрывает пункт «вне площадки», а «другой носитель» — только если хранилище провайдера технически независимо от вашего. Две зоны одного провайдера управляются из одного административного контура: при захвате учётной записи атакующему доступны обе копии. Провайдер не копирует данные внутри ваших ВМ, пока резервное копирование не подключено отдельной услугой.
RPO, RTO и выбор места хранения копий
RPO показывает, данные за какой период бизнес готов потерять, RTO — за какое время сервис должен снова заработать. Оба показателя задаёт владелец системы, исходя из стоимости простоя.
Целевые показатели для 1С, СУБД, файлов, почты и виртуальных машин
| Система | Способ копирования | RPO | RTO |
|---|---|---|---|
| 1С, клиент-серверный вариант (MS SQL или PostgreSQL) | Полная копия базы раз в сутки и журналы транзакций или WAL каждые 15–60 минут | 15–60 мин | 2–4 ч |
| 1С, файловый вариант | Копия файла базы без активных сеансов или выгрузка .dt в монопольном режиме | 24 ч | 1–2 ч |
| Прочие СУБД (CRM, учётные системы) | Копия, согласованная на уровне приложения (application-consistent), и архив журналов для восстановления на момент времени (point-in-time recovery) | 5–60 мин | 1–4 ч |
| Файловые сервисы | Инкрементные копии томов | 4–24 ч | 4–12 ч (том целиком) |
| Почта | Копия почтовых баз с обработкой на уровне приложения | 4–24 ч | 4–8 ч |
| Инфраструктурные ВМ (AD, DNS, терминальные серверы) | Копия уровня образа (image-level) | 24 ч | 1–4 ч |
Копия, согласованная на момент сбоя (crash-consistent), обычно поднимается, но без гарантии. Копия, согласованная на уровне приложения, делается через VSS или средства СУБД и фиксирует согласованное состояние. Для копирования журналов MS SQL нужна модель восстановления Full или Bulk-logged; для восстановления на произвольный момент времени — Full. Файловую базу 1С нельзя копировать во время работы пользователей, поэтому её RPO привязан к ночному окну.
Локально, на второй площадке, в облаке или в архиве: скорость и стоимость
| Место хранения | От чего защищает | Что ограничивает скорость восстановления | Время до начала восстановления | Стоимость хранения |
|---|---|---|---|---|
| Локальный дисковый репозиторий | Отказ сервера или СХД, ошибки пользователей | Диски репозитория, локальная сеть | Минуты | Средняя |
| Вторая собственная площадка | Потеря основной площадки | Канал между площадками | Минуты | Высокая: помещение, оборудование, каналы |
| Облако провайдера (BaaS) | Потеря площадки, при неизменяемом хранении — шифровальщик | Интернет-канал или ресурсы облака, если ВМ запускаются у провайдера | Минуты | Средняя, без капитальных затрат |
| Объектное S3-хранилище | Потеря площадки, с Object Lock — удаление и шифрование | Канал и скорость чтения объектов | Минуты | Низкая или средняя |
| Архив (холодный класс хранения, лента вне библиотеки) | Шифровальщик, требования к долгому хранению | Доставка кассеты или извлечение из холодного класса | Часы или сутки | Низкая |
Главный вопрос к внешней копии — сколько времени займёт её возврат. Допустим, нужно вернуть 2 ТБ (16 × 10¹² бит) через канал 200 Мбит/с. При полной загрузке канала это 80 000 секунд, около 22 часов. При реальной полезной скорости около 70% от номинала (140 Мбит/с) — примерно 32 часа. Канал 1 Гбит/с вернёт этот объём примерно за 6,3 часа. При целевом RTO 4 часа не подходит ни один вариант: нужна локальная копия или запуск системы прямо в облаке, без обратной перекачки данных.
Копии с персональными данными граждан РФ, как и рабочие базы, хранят в России. У финансовых организаций и субъектов КИИ добавляются отраслевые требования регуляторов.
Если второй площадки нет, внешнюю копию разумно вынести к провайдеру. Для этого у Cloud4U есть резервное копирование в облако на базе Veeam Backup. Копии физических и виртуальных серверов (VMware, Hyper-V, XenServer) хранятся в российских дата-центрах уровня Tier III и шифруются на стороне клиента ключом, который остаётся у вас. После первой полной копии передаются только сжатые изменения. Системы, не укладывающиеся в RTO, можно защитить репликацией: готовая к запуску ВМ стартует в облаке.
Как защитить сами резервные копии
Защиту проектируют из худшего допущения: у злоумышленника уже есть права администратора основного домена.
Отдельные учётные записи и изолированный сегмент для системы резервного копирования
- Отдельный контур учётных записей. Сервер резервного копирования и репозитории не входят в основной домен и не связаны с ним доверием.
- Многофакторная аутентификация на консоли и в облачной учётной записи.
- Разделение ролей. Оператор не может удалять точки и сокращать срок хранения.
- Выделенный сегмент сети. Репозиторий принимает соединения только от сервера и прокси резервного копирования.
- Ключи и пароли вне защищаемой инфраструктуры. Потерян ключ шифрования — потеряны и копии.
- Журнал аудита во внешней системе. Удаление точек и изменение политик сразу вызывают оповещение.
Неизменяемые и отключённые копии: что они защищают и где их пределы
Неизменяемые резервные копии (immutable backup) остаются в сети, но изменение и удаление запрещает само хранилище. Отключённая копия (air-gap) по сети недоступна вообще.
Пределы неизменяемости:
- Режим блокировки. В S3 Object Lock режим Governance снимает пользователь с отдельным правом: если оно есть у скомпрометированной учётной записи, защиты нет. Режим Compliance не снимает никто до истечения срока, но ошибочно выставленный год хранения придётся оплатить.
- Репозиторий на Linux защищён, пока не захвачен root: SSH отключают, учётные данные делают одноразовыми.
- Цепочка копий. Инкремент без полной копии бесполезен, блокировка должна покрывать всю цепочку.
- Время. Если атакующий сдвинет часы хранилища или подменит NTP, блокировка истечёт раньше срока.
Вымогатели нередко проводят в сети дни, а в отдельных случаях и недели до запуска шифрования. Если хранится 14 ежедневных точек, а проникновение было три недели назад, закладка есть во всех точках. Рекомендуем держать ежедневные точки 14–30 дней, еженедельные 2–3 месяца, а ежемесячные до года в более дешёвом классе хранения.
Проверка восстановления: что на практике означает «ноль ошибок»
«Копия цела» и «из копии за приемлемое время поднимается работающая система» — разные утверждения. Цифра «0» относится ко второму.
Уровни проверки: от контрольной суммы до учения по аварийному восстановлению
- Контрольные суммы. Подтверждают целостность блоков, но несогласованная база или зашифрованный файл проходят их без замечаний.
- Монтирование. Том читается, выборочные файлы открываются.
- Загрузка ОС в изолированной среде. ВМ стартует из копии без связи с рабочим контуром.
- Проверка приложения. Для СУБД — DBCC CHECKDB или pg_amcheck и сверка даты последней транзакции, для 1С — контрольный отчёт и тестовый документ.
- Учение по аварийному восстановлению. Группа связанных систем поднимается по плану, измеряется фактический RTO.
| Класс | Примеры | Контрольные суммы | Загрузка в изолированной среде | Проверка приложения | Учение |
|---|---|---|---|---|---|
| A | 1С, основная СУБД, AD | После каждого задания | Еженедельно | Ежемесячно | Раз в полгода |
| B | Почта, файловые сервисы, CRM | После каждого задания | Ежемесячно | Ежеквартально | Раз в год |
| C | Тестовые среды, архивы | После каждого задания | Ежеквартально | Не проводится | Не проводится |
Регламент, критерии успеха и протокол тестового восстановления
Тест успешен, если восстановление прошло без ошибок, данные укладываются в RPO, проверка целостности СУБД и контрольный сценарий выполнены, антивирус не нашёл угроз, а фактический RTO не превышает целевой. RTO замеряют от решения о восстановлении до момента, когда пользователи могут работать. Например, если пин-кодов лицензий 1С нет в плане восстановления, повторная активация добавит несколько часов.
Если последние копии могут быть заражены, по данным расследования определяют время проникновения и берут точку до него. Восстанавливают в изолированный сегмент, проверяют индикаторами компрометации и подключают к сети только после очистки или пересборки AD.
| Поле | Пример заполнения |
|---|---|
| Дата проверки, исполнитель | 15.09.2026, дежурный инженер |
| Система и класс | 1С:ERP, класс A |
| Точка восстановления | Копия от 14.09.2026 02:00 и журналы до 09:45 |
| Уровень проверки | 4 — проверка приложения |
| Целевые RPO / RTO | 30 мин / 4 ч |
| Фактические RPO / RTO | 15 мин / 3 ч 40 мин |
| Результат по критериям | Выполнены все, кроме лицензии: активация вручную |
| Меры и срок | Внести пин-коды в план восстановления до 30.09.2026 |
| Подтверждение | Владелец системы |
Журнал хранят вне системы резервного копирования. Проваленная проверка оформляется как инцидент со сроком устранения и повторным тестом.
Типичные ошибки и чек-лист стратегии резервного копирования
Ошибки, которые обнаруживаются только во время аварии
- Мониторят статус заданий, а не свежесть копий. Отключённое задание ошибок не выдаёт. Резкий рост инкремента при падении степени сжатия — признак массового шифрования.
- Копии СУБД и почты без согласованности на уровне приложения. Бэкап есть, а база из него не поднимается.
- Нет плана с порядком подъёма систем: AD и DNS, затем СУБД, серверы приложений и 1С, затем терминальные и веб-серверы.
- Пароли к ключам шифрования хранятся внутри домена, который как раз зашифрован.
Итоговый чек-лист
- [ ] Три копии критичных данных, два независимых типа хранения.
- [ ] Одна копия вне площадки, копии с персональными данными — в России.
- [ ] Одна неизменяемая или отключённая копия, блокировка покрывает всю цепочку.
- [ ] Система резервного копирования вне основного домена, с MFA и разделением ролей.
- [ ] Глубина хранения перекрывает период скрытого присутствия злоумышленника с запасом.
- [ ] RPO и RTO утверждены владельцами систем, время возврата внешней копии рассчитано.
- [ ] Проверки по графику, протоколы с фактическим RTO, учение хотя бы раз в год.
Главные выводы
Правило 3-2-1-1-0 удобно для проверки схемы: для каждого класса угроз должна быть копия, которую эта угроза не затрагивает. От отказа диска защищает второй носитель, от потери площадки — резервное копирование в облако, от злоумышленника с правами администратора — неизменяемые резервные копии и отдельный контур доступа. Итоговую надёжность определяет «ноль ошибок»: стратегия резервного копирования подтверждается только регулярной проверкой резервных копий с замером фактического времени. Поэтому резервное копирование для бизнеса стоит планировать от целевого времени восстановления.
