Журнал "Information Security/ Информационная безопасность" #4, 2026
Программная система резервного копирования – лишь часть решения. Надежность всей архитектуры зависит от СХД, которая должна выдерживать нагрузку, сохранять работоспособность и обеспечивать быстрый доступ к дан- ным. Резервное хранение требует систем- ного подхода: нужно определить прио- ритеты данных, построить сеть, внедрить СРК и регламенты восстановления. Но все это опирается на инфраструктуру хранения. Даже передовая СРК не помо- жет, если СХД не успевает отдавать данные при восстановлении или будет скомпрометирована. СХД для резервного копирования должна за короткое окно принимать терабайты данных без потери произво- дительности, сглаживать неравномерную нагрузку от множества источников и мас- штабироваться по мере роста объема копий. Для быстрого восстановления важна высокая скорость не только запи- си, но и чтения. RTO важнее окна резервного копирования При выборе решения для бэкапа часто смотрят на скорость создания копии, хотя при аварии для бизнеса важнее RTO – время возврата ключевых систем в работу. Поэтому хранилище должно обеспечивать достаточную пропускную способность и параллельное чтение, чтобы восстановление крупной базы не растянулось на сутки. Другой критерий надежности – устой- чивость к киберугрозам. Злоумышлен- ники могут целенаправленно искать и уничтожать резервные копии, поэтому хранилище должно обеспечивать их неизменяемость в течение заданного срока, минимальные привилегии и изо- ляцию от продуктивной среды. Шифро- вание зависит от модели угроз и в закрытом контуре может быть избыточ- ным, а подтвержденная целостность копий нужна всегда. Резервная копия имеет ценность только тогда, когда гарантированно доступна в момент восстановления. Значит, в СХД должны быть зарезер- вированы все аппаратные компонен- ты (диски, контроллеры, пути ввода- вывода, питание) и обеспечена целостность данных: проверка конт- рольных сумм, автоматическое исправление ошибок. В российских реалиях добавляются требования регуляторов: импортонеза- висимость (реестры Минцифры в части ПО и Минпромторга в части железа), хранение персональных данных, отчет- ность. И совместимость с существующим ИТ-ландшафтом. Как это выглядит в железе В портфеле Группы Rubytech есть линейка программно-аппаратных комплексов (ПАК) интеллектуального хранения данных: Машина объектно- го хранилища Скала^р МХД.О 1 и Машина резервного копирования Скала^р МХД.Р 2 . Они включены в реестр промышленной и радио- электронной продукции Минпромтор- га и соответствуют требованиям ключевых регуляторов рынка, в том числе ФСТЭК России. В ПАК МХД.Р локальное хранилище построено на сервере с файловой систе- мой ZFS (Zettabyte File System), которая обеспечивает надежность, предсказуе- мую производительность и защиту от потери данных при сбоях дисков. Основной массив состоит из HDD: в каждом сервере собственного про- изводства – 60 дисков по 16–24 Тбайт, из них 56 рабочих и 4 запасных. Дан- ные размещаются в отказоустойчивых группах RAIDZ2 по 8 дисков: 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, поведение при отказе дисков и изоляция от продуктивного контура – только при восстановлении. Поэтому хранилище стоит проектиро- вать вместе с СРК с учетом требований к восстановлению и отказоустойчиво- сти. l 40 • СПЕЦПРОЕКТ Бэкап выбирают по софту, а надежность – по хранилищу На правах рекламы 1 https://www.skala-r.ru/products/skala-mhdo/ 2 https://www.skala-r.ru/products/data-storage/pac-for-backup/
Made with FlippingBook
RkJQdWJsaXNoZXIy Mzk4NzYw