Современная СХД — это не просто набор дисков. На одной инфраструктуре работают виртуализация, базы данных, файловые сервисы и другие критичные нагрузки, а данные должны оставаться доступными не только при отказе оборудования, но и после ошибочного удаления, повреждения или разрушительной атаки.
Расчёт идёт от профиля нагрузки, а не от номинальной ёмкости.
Система должна работать не только когда все компоненты исправны.
Успешная резервная копия — ещё не доказательство готовности к восстановлению.
Hafaza Tech проектирует и внедряет системы хранения данных и резервное копирование на базе Huawei OceanStor, NetApp, Lenovo ThinkSystem Storage и Veeam — от обследования нагрузок и расчёта до миграции, репликации, резервного копирования и проверки восстановления.
Платформа хранения. Портфель OceanStor закрывает блочные, файловые и объектные сценарии: виртуализация, базы данных, корпоративные приложения, высоконагруженные задачи, файловые сервисы, ёмкие среды, репликация и защита данных.
Конкретная платформа подбирается по профилю нагрузки, производительности, ёмкости, доступности, росту и требованиям к защите данных. Huawei развивает и механизмы киберустойчивости внутри портфеля хранения, но их состав зависит от модели, версии и архитектуры — это проверяется для конкретной конфигурации.
Платформа хранения. Архитектура построена вокруг ONTAP и развитых возможностей управления данными. Подходит для блочного и файлового доступа, виртуализации, баз данных, корпоративных файловых сервисов, репликации и защиты данных.
NetApp развивает защиту от шифровальщиков на уровне хранения, снимки с защитой от изменения и подходы с изолированной копией как дополнительные уровни архитектуры восстановления. Такие механизмы не заменяют полноценное резервное копирование и план аварийного восстановления.
Платформа хранения. ThinkSystem Storage применяется для виртуализации, баз данных, корпоративных приложений, файловых сервисов, репозиториев резервных копий и инфраструктурных задач общего назначения.
У Lenovo есть проверенные архитектуры совместно с Veeam для сценариев резервного копирования и восстановления. Практичный вариант там, где нужна предсказуемая корпоративная архитектура хранения и интеграция с существующей инфраструктурой Lenovo.
Уровень резервного копирования. Veeam работает поверх производственной инфраструктуры и решает другую задачу: резервное копирование с учётом типа нагрузки, политики хранения, защищённые репозитории, восстановление с учётом состояния приложений, вторичные копии и проверка восстановления.
Veeam не заменяет снимки, репликацию и отказоустойчивость на уровне СХД — он дополняет их отдельным уровнем, у которого собственная политика и собственный жизненный цикл.
Huawei, NetApp и Lenovo — платформы хранения. Veeam — уровень резервного копирования и восстановления.
Сочетание даёт то, ради чего и строится архитектура: несколько независимых путей восстановления данных.
Проект начинается с архитектуры и расчёта, а конкретная модель выбирается после. Сравнение по стоимости одного терабайта без профиля нагрузки приводит к системе, которая не справляется в нужный момент.
С чего начинается проект
Одни и те же 500 ТБ могут использоваться под транзакционные базы, виртуализацию, виртуальные рабочие места, файловые сервисы, аналитику, архив или репозиторий резервных копий. СХД для большого архива и СХД для высоконагруженной базы могут иметь одинаковую ёмкость и совершенно разные требования к задержкам и архитектуре.
Профиль нагрузки
Полезная ёмкость
Производительность
Доступность
Рост
Защита данных и восстановление
Тома и LUN для нагрузок, где важны предсказуемая задержка и производительность: виртуализация, базы данных, корпоративные приложения.
Общий доступ к файлам: NAS, пользовательские данные, файловые сервисы приложений.
Большие объёмы неструктурированных данных, архив, репозитории резервных копий и задачи, где объектная модель естественнее.
При сравнении СХД разные показатели ёмкости означают разные вещи, а производительность нельзя оценивать одним числом.
Физический объём установленных накопителей.
Объём после накладных расходов на защиту данных и системные резервы. Именно на неё мы ориентируемся при расчёте.
Расчётный объём после сжатия, дедупликации и других механизмов уплотнения.
Эффективная ёмкость сильно зависит от типа данных: уже сжатые или зашифрованные наборы могут практически не уменьшаться. Коэффициент уплотнения нельзя считать гарантированным без анализа конкретной нагрузки.
Производительность
Сто тысяч операций на мелком случайном чтении и сто тысяч на смешанной нагрузке с крупным блоком — совершенно разные сценарии. Поэтому результаты тестов рассматриваются вместе с задержкой, размером блока, соотношением чтения и записи и предположениями о кэше.
Операции в секунду и пропускная способность
Задержка
Размер блока
Соотношение чтения и записи
Параллельность нагрузки
Последовательный и случайный доступ
Поведение кэша
Интерфейсы и внутренняя архитектура
СХД, которая соответствует требованиям только в нормальном состоянии, может не справиться во время реального инцидента.
Отказоустойчивость
Для критичных нагрузок инфраструктура хранения должна переживать отказ компонентов: резервированные контроллеры и узлы, несколько путей доступа, резервированные фабрики, защита на уровне дисковой группы, кластеризация, синхронная или асинхронная репликация, устойчивость на уровне площадки.
Резервированные контроллеры и узлы
Несколько путей доступа
Резервированные фабрики
Защита на уровне дисковой группы
Кластеризация
Синхронная и асинхронная репликация
Устойчивость на уровне площадки
Резервирование — это не резервное копирование, а высокая доступность — не восстановление данных. Отказоустойчивость не защищает от логического повреждения, ошибочного удаления, действий администратора, шифровальщика или некорректного изменения со стороны приложения. Это разные задачи и разные уровни архитектуры.
Современная защита данных обычно использует несколько механизмов одновременно, и каждый из них решает собственную задачу.
Позволяют быстро создавать точки восстановления и часто обеспечивают очень быстрый возврат. Но снимок остаётся частью той же системы хранения и сам по себе не является стратегией резервного копирования: его устойчивость зависит от политики хранения, прав администраторов и механизмов защиты самой СХД.
Создаёт копию данных на другой системе или площадке и полезна для доступности и аварийного восстановления. Но репликация так же быстро передаёт повреждение, ошибочное удаление, нежелательное изменение или результат работы шифровальщика.
Создаёт копии с отдельной политикой, сроком хранения и собственным жизненным циклом восстановления. Для критичных нагрузок копия по возможности размещается в отдельном домене отказа и безопасности относительно продуктивной инфраструктуры.
Безопасность платформы хранения
Если атакующий получает привилегированный доступ к управлению хранением, он может изменить конфигурацию, удалить снимки, отключить репликацию, уничтожить точки восстановления или нарушить доступность. Поэтому управление хранением защищается не слабее других критичных систем.
Ролевая модель доступа
Многофакторная аутентификация — где поддерживается
Разделение административных ролей
Изоляция сети управления
Шифрование при хранении и передаче
Журналирование и аудит
Контроль административных изменений
Защищённая репликация
Безопасность и устойчивость — не одно и то же. Безопасность защищает управление и доступ, а устойчивость отвечает на вопрос, сможем ли мы восстановить данные после разрушительного события.
Неизменяемость защищает точки восстановления от изменения или удаления в течение заданного периода. Но сам по себе термин «неизменяемая копия» ничего не гарантирует — значение имеет реальная модель администрирования.
Ключевой вопрос проектирования: может ли атакующий, скомпрометировав управление продуктивной средой, теми же учётными данными или по тем же сетевым путям уничтожить данные для восстановления? Если да — уровень восстановления недостаточно независим.
Кто может удалить копию
Какие учётные данные для этого нужны
Можно ли изменить срок хранения
Может ли платформа управления обойти защиту
Что произойдёт при компрометации управления
Разные технологии дают разный уровень защиты: снимок только для чтения, снимок с защитой от изменения, неизменяемый репозиторий, изолированная или офлайн-копия. Для критичных нагрузок используются логическая изоляция, отдельные учётные данные, выделенная зона восстановления или физически изолированная копия — там, где это действительно требуется.
Резервное копирование — отдельный уровень поверх продуктивного хранения. Его производительность зависит не только от репозитория.
Главный вопрос инцидента
При проектировании много внимания уделяют окну резервного копирования. Но во время серьёзного инцидента важнее другое: сколько времени займёт восстановление. Репозиторий, способный быстро принимать поток копий, не обязательно восстановит десятки терабайт критичных нагрузок за требуемое время.
Допустимая потеря данных — RPO
Допустимое время восстановления — RTO
Критичность нагрузки
Срок хранения копий
Требуемая скорость восстановления
Критичная база, корпоративная система, файловый архив и тестовая виртуальная машина не должны автоматически получать одинаковую политику защиты. Поэтому цепочка выглядит так: критичность нагрузки → RPO → RTO → метод защиты.
Одна из самых распространённых ошибок — считать статус «задание выполнено» доказательством того, что сервис можно поднять.
Резервное копирование отвечает прежде всего за восстановление данных, а аварийное восстановление — за восстановление бизнес-сервиса. Наличие копии базы ещё не означает возможность поднять приложение: нужны вычислительные ресурсы, сеть, учётные записи, зависимости и порядок действий.
Само восстановление
Целостность данных
Согласованность приложения
Зависимости и порядок запуска
Учётные данные и доступ
Сетевая конфигурация
Соблюдение RPO
Соблюдение RTO
Подход 3-2-1-1-0 остаётся полезным ориентиром: три копии, два разных способа хранения, одна копия вне площадки, одна неизменяемая или офлайн, ноль непроверенных ошибок восстановления. Но это ориентир при проектировании, а не обязательная архитектура: главное — независимость копий от доменов отказа и компрометации.
Проект редко заканчивается установкой новой СХД: существующие нагрузки нужно безопасно перенести.
Для критичных систем миграция проектируется так же внимательно, как и сама целевая архитектура. До переключения определяются метод переноса, требования к простою, совместимость, способ копирования или репликации, сценарий отката и критерии проверки.
Допустимый простой
Совместимость хостов
Многопутевой доступ
Зонирование фабрики
Зависимости приложений
Репликация и полоса пропускания
Окно переключения
Откат
Проверка данных
Порядок этапов выстроен так, чтобы архитектура считалась от реальных нагрузок, а восстановление было проверено до того, как оно понадобится.
01
Обследование
02
Профиль нагрузок
03
Расчёт
04
Архитектура
05
Миграция
06
Защита данных
07
Резервное копирование
08
Проверка восстановления
09
Поддержка
Анализируем существующее хранение, инфраструктуру сети и фабрики, гипервизоры, базы данных, приложения, файловые сервисы, текущее резервное копирование и репликацию, ёмкость, рост, производительность, доступность, требования к аварийному восстановлению и безопасности. Проверяем используемые протоколы и интерфейсы.
Для каждой критичной нагрузки оцениваем полезную ёмкость, операции в секунду, пропускную способность, задержку, профиль чтения и записи, параллельность, рост, критичность, требования к доступности и к RPO и RTO.
Расчёт учитывает текущую нагрузку, рост, сценарии отказа и накладные расходы на защиту данных: защиту дисковой группы, снимки, репликацию, резервную ёмкость, перестроение, предположения об уплотнении данных, расширение и нагрузку от резервного копирования.
В архитектуре определяются требования к блочному, файловому и объектному доступу, протоколы, архитектура контроллеров и узлов, подключение, отказоустойчивость, многопутевой доступ, репликация, снимки, сеть управления и мониторинг. При необходимости проектируется архитектура на несколько площадок.
Для каждой нагрузки определяется нужный набор уровней восстановления: снимок, репликация, резервная копия, защищённая или изолированная копия. Не каждая нагрузка требует всех уровней — набор выбирается по критичности и требованиям к восстановлению.
После внедрения проверяется не создание копий, а полный цикл: резервное копирование → восстановление → запуск приложения → проверка данных. Для критичных нагрузок такие проверки повторяются регулярно.
Выбор нельзя свести к бренду или стоимости одного терабайта. Проект начинается с архитектуры и расчёта — модель выбирается после.
Профиль нагрузок, полезная ёмкость, операции в секунду, пропускная способность, задержка.
Поддерживаемые протоколы, архитектура подключения, многопутевой доступ.
Архитектура отказоустойчивости, поведение в деградированном состоянии, масштабируемость.
Снимки, репликация, уплотнение данных, механизмы защиты копий.
Жизненный цикл, поддержка, операционная сложность.
Лицензирование и совокупная стоимость владения на горизонте проекта.
Для резервного копирования отдельно оцениваются скорость восстановления, согласованность приложений, политики хранения, защищённые репозитории и возможность проверки восстановления.
Современная СХД — это не только ёмкость, но и производительность, доступность, защита данных и способность восстановиться.
Хранить данные с требуемой производительностью → переживать отказ компонентов → сохранять точки восстановления → иметь отдельное резервное копирование → защищать копии → восстанавливать критичные сервисы в заданные сроки.
Не нашли ответа на свои вопросы? Отправьте свой вопрос ниже, и наша служба поддержки ответит на него в ближайшее время. Мы здесь, чтобы помочь вам с кибербезопасностью!
Задайте вопрос!
Если вы хотите узнать больше о наших услугах в области кибербезопасности или не уверены, какие решения подойдут именно вам, оставьте заявку — и наши специалисты свяжутся с вами для бесплатной консультации.
Дополняющие решения для комплексной защиты инфраструктуры и повышения общего уровня информационной безопасности.
Защита привилегированного доступа к управлению хранением и резервным копированием.
Мониторинг критичных административных событий, сбоев и попыток удаления копий.
Дополнительный контекст при разрушительных инцидентах и атаках шифровальщиков.
