Бэкап выбирают по софту, а надежность – по хранилищу

Современный бизнес руководствуется принципом «ни минуты простоя». Для обеспечения отказоустойчивости компаниям необходим качественный бэкап: он помогает предупреждать сбои бизнес-процессов и потерю данных, гарантирует быстрое восстановление после инцидента. Однако сама программная система резервного копирования (СРК) – это только часть комплексного решения. Система хранения данных (СХД) определяет итоговую надежность всей архитектуры: она должна выдерживать нагрузку, сохранять работоспособность и при необходимости обеспечить быстрый доступ к информации.

Резервное хранение требует системного подхода: определить источники данных и их приоритет, построить сеть, выбрать и внедрить СРК, утвердить регламенты и алгоритмы проверки восстановления. Но все это опирается на инфраструктурный слой – серверные мощности, где хранятся копии. Даже передовая СРК окажется неэффективной, если СХД не успевает отдавать данные при восстановлении или будет скомпрометирована.

Чем хранилище бэкапов отличается от обычной СХД

СХД для резервного копирования отличается от других типов хранилищ:  

– система должна за короткий срок (окна резервного копирования – чаще всего это ночь или выходные) принять терабайты данных без деградации производительности;

– потоки от множества источников могут создавать неравномерную нагрузку, и хранилище должно их сглаживать, не создавая очередей; 

– необходимо длительное хранение данных и поддержка оптимального масштабирования хранилища в условиях роста количества резервных копий;

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

RTO важнее окна резервного копирования

При выборе решения для бэкапа часто смотрят только на скорость создания резервной копии (РК). Однако в аварийной ситуации (сбой, киберугроза, потеря ЦОД) для бизнеса наиболее критичен показатель RTO (Recovery Time Objective) – время с момента инцидента до возврата ключевых систем в эксплуатацию. Хранилище РК должно обеспечивать параллельное чтение и достаточную пропускную способность, чтобы восстановление крупной базы данных не растянулось на сутки. 

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

– обеспечение неизменяемости (immutability) данных в течение утвержденного срока;

– разграничение доступа, ролевая модель и принцип минимальных привилегий;

– логическая и по возможности физическая изоляция хранилища от продуктивной среды;

– шифрование данных там, где это оправдано моделью угроз (в закрытом контуре оно часто не нужно, а вот доказуемая целостность копий нужна всегда). 

Резервная копия имеет ценность только тогда, когда гарантированно доступна в момент восстановления. Значит, в СХД должны быть зарезервированы все аппаратные компоненты – диски, контроллеры, пути ввода-вывода, питание – и обеспечена целостность данных: проверка контрольных сумм, автоматическое исправление ошибок.

В российских реалиях добавляются требования регуляторов: импортонезависимость (реестры Минцифры в части ПО и Минпромторга в части «железа»), хранение персональных данных, отчетность. И совместимость с существующим ИТ-ландшафтом.

Как это выглядит в железе

В портфеле Группы Rubytech есть линейка программно-аппаратных комплексов (ПАК) интеллектуального хранения данных: Машина объектного хранилища Скала^р МХД.О и Машина резервного копирования Скала^р МХД.Р. Они включены в реестр промышленной и радиоэлектронной продукции Минпромторга и соответствуют требованиям ключевых регуляторов рынка, в том числе ФСТЭК России.

В ПАК МХД.Р локальное хранилище данных построено на базе сервера с файловой системой ZFS (Zettabyte File System) – она дает высокую надежность хранения, предсказуемую производительность и защиту от потери данных при сбоях дисков.

Основной массив под данные – это большие HDD-диски. В каждом сервере собственного производства – 60 дисков по 16–24 ТБ каждый, из них 56 рабочих и 4 запасных. Данные размещаются в отказоустойчивых группах по схеме RAIDZ2: в каждой группе 6 дисков с данными и 2 с избыточностью. Таким образом, система выдержит одновременный отказ любых двух дисков в одной группе без потери информации. Соответственно, полезный объем хранилища составит примерно от 680 ТБ (с дисками по 16 ТБ) до 1 ПБ (с дисками по 24 ТБ).

Для ускорения чтения и записи устанавливаем два быстрых NVMe-диска по 3,84 ТБ в RAID1 – они работают как лог намерений (SLOG), кэш чтения (L2ARC) и хранилище метаданных.

Если необходимо хранить копии данных на разных серверах (для катастрофоустойчивости), это нужно тоже заложить в расчет емкости: часть пространства будет отведена для задач дублирования. Получается аппаратная платформа, которая, с одной стороны, горизонтально масштабируется, а с другой – обеспечивает надежное резервное копирование и удобство управления СРК.

Второй ПАК – Скала^р МХД.О – закрывает смежную задачу: это объектное хранилище с S3-совместимым API. Если МХД.Р принимает поток резервных копий и обеспечивает быстрый возврат данных в эксплуатацию, то МХД.О становится емким уровнем длительного хранения и заменяет дисковые массивы и ленточные накопители. Объем одной Машины – от 100 ТБ до 64 ПБ, сжатие данных – до 20 раз, а избыточность настраивается под задачу.

Отдельный вопрос – сертификация. Требованиям регуляторов решения соответствуют за счет сертификата ФСТЭК России на используемую ОС. Однако сразу развертывать сертифицированную версию самой СРК не рекомендуется: под конкретную инфраструктуру часто требуется адаптация, а цикл сертификации новой версии очень долгий. При этом купить сертифицированную версию и эксплуатировать вместо нее обычную нельзя – это административное нарушение. Поэтому рабочая последовательность такая: ставим обычную версию, дорабатываем, проходим опытно-промышленную эксплуатацию, фиксируем версию и ждем ее сертификации.

Сертификация подтверждает соответствие стандартам безопасности, а защиту на уровне архитектуры обеспечивает принцип Secure by Design. В ПАК Скала^р это сканирование на уязвимости при разработке, повышение защищенности комплекса на этапе производства (hardening), встроенное управление доступом, сертифицированные ОС и служебные СУБД в составе, проверенная совместимость с наложенными средствами защиты и SIEM заказчика. Встроенная защита не конкурирует с системой за производительность – достроенная поверх конкурирует почти всегда.

В этой логике катастрофоустойчивость перестает быть отдельным проектом. В МХД.Р дублирование копий между узлами закладывается в расчет емкости заранее. В МХД.О георепликация в режимах Active-Active и Active-Passive работает без ограничения по расстоянию, мультитенантность разводит контуры подразделений по независимым пространствам имен, а доступ контролируется ролевой моделью с отдельной ролью аудитора ИБ и выгрузкой событий во внешний SIEM. Компрометация одного контура не открывает доступ к копиям остальных, а потеря площадки отрабатывается штатным сценарием.

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