Настройки cookie
Автор статьи:
Юрий Салангин
директор по развитию PlanB в России
Технический разбор октябрьских сбоев:
?
что именно сломалось
?
как это проверить у себя
?
как устроена защита, которая переживает отказ целого дата-центра
Введение
За четыре дня — с 8 по 11 октября — три дата-центра одного из крупнейших облачных операторов страны вышли из строя: частично или полностью. Суммарно — больше сотни мегаватт мощностей.
К вечеру понедельника сбой ощущают сотни компаний, а облачный оператор официально сообщает клиентам: режим аварийный, «задействуйте любые альтернативные планы по аварийному восстановлению». По оценкам рынка, восстановление мощностей может занять несколько месяцев или больше.
Эта история показывает главную ошибку последних лет: копии хранили там же, где и оригиналы. Не конкретные атаки виноваты — сама логика такого хранения. Годами складывали копии туда же, куда и оригиналы, называли это «облачным бэкапом» и спали спокойно.
В этой статье мы разберём с технической точки зрения, что именно пошло не так у пострадавших и как это выглядит со стороны компании, которая готовилась.
К вечеру понедельника сбой ощущают сотни компаний, а облачный оператор официально сообщает клиентам: режим аварийный, «задействуйте любые альтернативные планы по аварийному восстановлению». По оценкам рынка, восстановление мощностей может занять несколько месяцев или больше.
Эта история показывает главную ошибку последних лет: копии хранили там же, где и оригиналы. Не конкретные атаки виноваты — сама логика такого хранения. Годами складывали копии туда же, куда и оригиналы, называли это «облачным бэкапом» и спали спокойно.
В этой статье мы разберём с технической точки зрения, что именно пошло не так у пострадавших и как это выглядит со стороны компании, которая готовилась.
Разбор первый: почему копия в том же облаке — это не бэкап
Формально у большинства пострадавших компаний бэкапы были. Резервные копии делались регулярно, хранились аккуратно — внутри того же облака, на том же дисковом массиве, в том же дата-центре. Когда площадка вышла из строя, «оригинал и копия» умерли одним днём.
Для организации резервного копирования используют правило «3−2-1» и его расширенный вариант «3-2-1-1-0»: три копии данных, два разных типа носителей, одна копия вне основного дата-центра, одна — изолированная, ноль непроверенных копий.
Ключевое слово здесь «вне». Зона доступности того же региона не считается: это общая инфраструктура, общее электропитание, общая судьба. Независимая копия — это другой оператор, другой сегмент сети, а лучше другой юридический контур.
Для организации резервного копирования используют правило «3−2-1» и его расширенный вариант «3-2-1-1-0»: три копии данных, два разных типа носителей, одна копия вне основного дата-центра, одна — изолированная, ноль непроверенных копий.
Ключевое слово здесь «вне». Зона доступности того же региона не считается: это общая инфраструктура, общее электропитание, общая судьба. Независимая копия — это другой оператор, другой сегмент сети, а лучше другой юридический контур.
Копия должна жить вне основного дата-центра: схема 3-2-1
Разбор второй: почему одни уехали за три дня, а другие ждут неделями
Показательным оказалось различие в сроках восстановления. Одни компании перенесли сервисы к другим операторам за считанные дни. Другие восстанавливаются до сих пор. Сроки восстановления зависят не только от бюджета, но и от подготовки резервных копий и инфраструктуры.
Технически переезд упирается в три вещи.
Технически переезд упирается в три вещи.
- Первое — привязка: если копию можно восстановить только в инфраструктуре того же вендора, вы становитесь заложниками его платформы, и миграция превращается в проект конвертации.
- Второе — место хранения: копия в хранилище того же оператора недоступна ровно столько, сколько недоступен он сам.
- Третье — скорость: петабайт файлов не переедет на rsync, тут нужен специализированный инструмент.
Разбор третий: восстанавливать нужно бизнес, а не терабайты
В кризис считают не гигабайты, а часы до работающей кассы. Это значит, что ещё до инцидента у каждой критичной системы должны быть две цифры:RPO — сколько данных, в минутах работы, мы готовы потерять и RTO (за какое время сервис обязан подняться). Для баз данных это вообще определяет архитектуру: классический бэкап «раз в ночь» даёт RPO до 24 часов, а откат на точный момент времени (point-in-time recovery) за счёт непрерывного перехвата журналов изменений — RPO в секунды. Разница между «потеряли сутки работы бухгалтерии» и «потеряли две минуты» — это не разница продуктов, а разница в настройках одного.
Чек-лист самопроверки
Шесть вопросов, которые стоит задать своей ИТ-службе, пока всё работает:
Где физически лежат резервные копии? Точно не в том же здании и не в том же облаке, что и оригиналы?
Есть ли копия у независимого оператора — и сумеем ли мы переехать к нему за дни, а не месяцы?
Когда в последний раз восстанавливали данные из резервной копии в тестовой среде? Сколько времени это заняло?
Какие RPO и RTO у критичных систем — и где они записаны?
Что случится с копиями, если в сеть зайдёт шифровальщик? Он ищет бэкапы первыми.
Есть ли копия, которую физически нельзя ни удалить, ни изменить — даже с правами администратора?
Скачать чек-лист
Как это устроено в PlanB Data Management
PlanB Data Management — это платформа резервного копирования и аварийного восстановления. Она помогает защищать корпоративную инфраструктуру: физические и виртуальные серверы, базы данных, файловые хранилища, контейнеры и облачные среды.
Ниже подробно расскажу, как задачи по защите данных решаются в рамках решения PlanB Data Management.
Ниже подробно расскажу, как задачи по защите данных решаются в рамках решения PlanB Data Management.
Независимая копия: политика 3-2-1 исполняется системой, а не людьми
Платформа разворачивается в контуре заказчика.
Архитектура — центральная веб-консоль, сервер планирования, кластер серверов приёма копий и легковесные клиенты на защищаемых машинах. По политике каждая копия автоматически распределяется: быстрый диск или ZFS-пул для оперативного восстановления, объектное S3-хранилище независимого оператора для катастрофоустойчивости, ленточная библиотека или Blu-ray для длинного архива. Мультирепликация позволяет держать актуальную копию сразу в нескольких S3-хранилищах разных операторов. Отказ любой одной площадки — включая облако целиком — перестаёт быть потерей данных.
Архитектура — центральная веб-консоль, сервер планирования, кластер серверов приёма копий и легковесные клиенты на защищаемых машинах. По политике каждая копия автоматически распределяется: быстрый диск или ZFS-пул для оперативного восстановления, объектное S3-хранилище независимого оператора для катастрофоустойчивости, ленточная библиотека или Blu-ray для длинного архива. Мультирепликация позволяет держать актуальную копию сразу в нескольких S3-хранилищах разных операторов. Отказ любой одной площадки — включая облако целиком — перестаёт быть потерей данных.
Архитектура платформы PlanB
Портативность: миграция как функция платформы
Модуль Move переносит работающие серверы между любыми платформами без остановки бизнеса: физический сервер в виртуальную машину, виртуалку в другое облако, старую платформу на новую.
Модуль DTO массово перемещает файловые хранилища и архивы между NAS и объектными системами S3 — объёмы до петабайт, с многомерным архивированием и возможностью обращаться к исходным данным и запрашивать архивные (back-to-source).
На каждом этапе переноса выполняются проверки согласованности данных. Данные, с которыми легко переехать, не становятся заложниками ни одного поставщика.
Модуль DTO массово перемещает файловые хранилища и архивы между NAS и объектными системами S3 — объёмы до петабайт, с многомерным архивированием и возможностью обращаться к исходным данным и запрашивать архивные (back-to-source).
На каждом этапе переноса выполняются проверки согласованности данных. Данные, с которыми легко переехать, не становятся заложниками ни одного поставщика.
Копии, которые нельзя изменить и стереть
Защита копий в PlanB стоит на уровне драйвера ядра операционной системы. В каталоге резервных копий система разрешает запись только процессам самой платформы — принцип default-deny на уровне I/O. Шифровальщик, злоумышленник или ошибающийся администратор с полными правами упираются в эту границу: изменить или удалить файлы копий штатными средствами невозможно.
Отключить защиту можно только по разовому коду верификации — то есть осознанным действием, а не побочным эффектом компрометации. Поверх — изолированная копия air gap и шифрование канала и хранения: AES-128/256, SM4, сертификаты на каждый узел, аутентификация через внутренний центр сертификации.
Отключить защиту можно только по разовому коду верификации — то есть осознанным действием, а не побочным эффектом компрометации. Поверх — изолированная копия air gap и шифрование канала и хранения: AES-128/256, SM4, сертификаты на каждый узел, аутентификация через внутренний центр сертификации.
Как устроена защита копий от шифровальщиков
Восстановление: от отдельной секунды до целого сервера на пустом железе
Базы данных. Агент DBAgent обеспечивает транзакционную согласованность при снятии копии, а журналы redo и archive перехватываются в реальном времени, поэтому база откатывается на точный момент времени, для Oracle — с точностью до SCN, для MySQL/MariaDB — до GTID.
Поддерживаются Oracle (включая RAC и Active Data Guard), MS SQL, PostgreSQL, MySQL, DB2, MongoDB, GaussDB; есть резервирование отдельных таблиц и многоуровневое хранение.
Поддерживаются Oracle (включая RAC и Active Data Guard), MS SQL, PostgreSQL, MySQL, DB2, MongoDB, GaussDB; есть резервирование отдельных таблиц и многоуровневое хранение.
Откат базы на точный момент времени за счёт перехвата журналов
Виртуальные машины. Бэкап без агентов — через API гипервизора: VMware, Hyper-V, OpenStack, а также китайские платформы Sangfor SCP, Huawei FusionCompute/HCS, H3C CAS, ZStack. Копирование может идти LAN-free — напрямую через сеть хранения, без нагрузки на прикладную сеть. При восстановлении есть три рабочих сценария: гранулярный возврат отдельных файлов без подъёма машины, моментальный запуск ВМ прямо из копии (instant recovery) и полное восстановление на любое железо с автоисправлением загрузчика.
Физические серверы. Windows и Linux поднимаются на «голом железе» с загрузочного носителя (Bare-Metal Restore), AIX поддерживается.
И поверх всего — контроль целостности: платформа регулярно проверяет копии, чтобы повреждённая копия не обнаружилась в тот день, когда она действительно понадобится.
Физические серверы. Windows и Linux поднимаются на «голом железе» с загрузочного носителя (Bare-Metal Restore), AIX поддерживается.
И поверх всего — контроль целостности: платформа регулярно проверяет копии, чтобы повреждённая копия не обнаружилась в тот день, когда она действительно понадобится.
Масштаб и экономика
Платформа держит до 5000 узлов в одной системе, серверы бэкапа кластеризуются с общим хранилищем — отказ узла не останавливает задания.
Дедупликация на источнике и на целевой стороне (фиксированные и переменные блоки, общая база хэшей) режет объём хранилища в разы, а это самая дорогая часть любой системы защиты данных. Лицензирование — по объёму защищаемых данных. Техническая поддержка на русском языке, команда в России.
Дедупликация на источнике и на целевой стороне (фиксированные и переменные блоки, общая база хэшей) режет объём хранилища в разы, а это самая дорогая часть любой системы защиты данных. Лицензирование — по объёму защищаемых данных. Техническая поддержка на русском языке, команда в России.
PlanB Data Management — система резервного копирования и восстановления данных
Слово напоследок
Инцидент с чужим облаком стоил его клиентам дней простоя и недель нервов. Инцидент с корректно построенными копиями стоит минуты работы и одну кнопку в консоли. Разница между этими сценариями — не деньги и не везение. Разница в том, что было сделано до понедельника.
Хотите посмотреть, как это работает? Тогда приходите на живое демо. Если интересно глубже, мы покажем архитектуру под вашу инфраструктуру: какие СУБД у вас, какая виртуализация, какой объём и честно скажем, что закроется сразу, а что потребует проектирования.
Хотите посмотреть, как это работает? Тогда приходите на живое демо. Если интересно глубже, мы покажем архитектуру под вашу инфраструктуру: какие СУБД у вас, какая виртуализация, какой объём и честно скажем, что закроется сразу, а что потребует проектирования.
Оцените материал
Может быть интересно
