Как подобрать RAID для больших объёмов данных

Большой массив данных быстро превращает выбор RAID в задачу не только о скорости. Нужно понять, сколько полезного пространства останется после резервирования, выдержит ли массив отказ диска во время восстановления, насколько предсказуемой будет работа под нагрузкой и что произойдёт при сбое контроллера или ошибке оператора.

Неправильно выбранная схема может оказаться дорогой в эксплуатации: на бумаге терабайтов достаточно, а на практике хранилище постоянно упирается в производительность, долго перестраивается после отказа или не оставляет места для роста.

RAID объединяет несколько накопителей в логический массив, но сам по себе не является резервной копией. Он помогает пережить определённые отказы дисков и в некоторых режимах повышает скорость, однако не защищает от удаления файлов, шифровальщика, повреждения данных, кражи сервера или пожара.

Поэтому выбирать уровень RAID нужно вместе с оценкой нагрузки, ёмкости дисков, требований к доступности и планом резервного копирования.

Ниже разберём, как подойти к выбору последовательно: от расчёта объёма и характера нагрузки до особенностей восстановления, аппаратных контроллеров, программных хранилищ и резервирования. Примеры приведены для типичных серверных и рабочих сценариев; перед покупкой оборудования стоит сверить характеристики конкретных дисков, контроллера и файловой системы.

Сначала определите, что именно должно хранить хранилище

Фраза "нужен RAID на много данных" мало помогает при проектировании. Архив видеозаписей, виртуальные машины, база данных, медиатека и резервные копии могут занимать одинаковые 100 ТБ, но предъявлять совершенно разные требования. Для архива важнее цена терабайта и сохранность при отказе дисков. Для базы данных - задержка операций и предсказуемая производительность.

Для видеомонтажа нужны высокая последовательная скорость и достаточная пропускная способность при одновременном чтении нескольких потоков.

Начните с инвентаризации данных.

Полезно выяснить не только общий объём, но и темп его роста, средний размер файлов, долю часто используемой информации и типичный срок хранения. Например, у системы видеонаблюдения новые записи появляются каждый день, а старые удаляются через заданное число суток. У виртуализационной платформы объём может увеличиваться скачками при развёртывании новых машин.

В первом случае важно планировать ёмкость по числу камер и сроку хранения, во втором - предусматривать резерв для расширения и снимков.

Оцените нагрузку по операциям, а не только по гигабайтам в секунду. Последовательное чтение большого файла одна задача, а тысячи небольших случайных чтений и записей - совсем другая. Первую хорошо обслуживают многие массивы из HDD, если дисков достаточно и данные распределены по ним. Для второй часто критичны задержка, число операций ввода-вывода в секунду и наличие SSD.

Один и тот же массив может показывать впечатляющую скорость при копировании крупного файла и заметно тормозить под нагрузкой виртуальных машин.

• Для архивов и медиатеки выясните, как часто данные читают и насколько допустима пауза при обслуживании.

• Для баз данных и виртуальных машин измерьте случайные операции, задержку и соотношение чтения к записи.

• Для видеомонтажа посчитайте одновременные потоки, разрешение, частоту кадров и требуемый битрейт.

• Для резервного хранилища определите скорость поступления копий, сроки хранения и сценарий восстановления.

После этого сформулируйте требования к отказоустойчивости.

Нужно ли продолжать работу при отказе одного диска или двух? Допустимо ли плановое окно обслуживания? Есть ли возможность заменить диск немедленно, или запасная деталь будет ехать несколько дней? Если простой стоит дорого, одной схемы RAID может быть мало: потребуются запасной сервер, репликация и проверенный порядок переключения.

Полезно заранее записать приоритеты в порядке важности. Например: "данные не должны стать недоступны после отказа любого одного диска; чтение крупными блоками не ниже заданной скорости; полезная ёмкость не менее 80 ТБ; расширение без остановки желательно".

Такой список отсекает неподходящие конфигурации лучше, чем выбор "самого надёжного RAID" по названию.

Посчитайте полезную ёмкость и оставьте запас

Указанная на диске ёмкость - не то же самое, что доступное пространство массива.

Производители обычно считают терабайт как 1 000 000 000 000 байт, тогда как операционная система может показывать двоичные тебибайты. Поэтому диск на 20 ТБ в интерфейсе системы будет выглядеть примерно как 18,2 ТиБ ещё до учёта RAID, файловой системы и служебных расходов.

Разница не означает, что накопитель "украл" место: используются разные единицы измерения.

Для простых уровней оценку можно сделать заранее. В RAID 1 из двух одинаковых дисков полезна ёмкость одного диска.

В RAID 5 массив из N дисков предоставляет примерно ёмкость N−1 дисков. В RAID 6 - примерно N−2. В RAID 10 обычно доступна половина суммарной сырой ёмкости, если диски одинакового размера.

Это теоретические оценки: файловая система, метаданные, резервирование свободного места и форматирование уменьшают фактический объём.

Это расчёт десятичных терабайтов до форматирования и служебных расходов. В примере с восемью дисками по 20 ТБ исходная ёмкость составляет 160 ТБ. RAID 6 сохраняет пространство, эквивалентное двум дискам, под чётность, а RAID 10 расходует около половины ёмкости на зеркальные копии.

При планировании сравнивайте конфигурации в одинаковых единицах и уточняйте, как именно производитель интерфейса обозначает объём.

Не стоит проектировать массив так, чтобы сразу после создания он был заполнен почти полностью. Свободное место нужно для роста, временных файлов, перестроения, снимков и нормальной работы некоторых файловых систем.

На практике организация может заранее определить рабочий порог, например начать расширение, когда занято 70–80% полезной ёмкости. Это не универсальная техническая граница: для одних нагрузок запас требуется больше, для других меньше.

Важен сам принцип - расширение должно быть запланировано до аварийного заполнения.

К расчёту прибавьте будущий рост. Если система получает около 1,5 ТБ новых данных в месяц, срок хранения равен 18 месяцам, а сжатие и дедупликация не гарантированы, минимальный объём новых данных только для текущего периода составит 27 ТБ.

Затем следует учесть снимки, служебные данные, резерв свободного пространства и возможное увеличение потока.

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

Наконец, проверьте ограничения оборудования. Некоторые системы не умеют расширять конкретный уровень RAID добавлением одного диска, другие могут расширять его онлайн, но только при определённых условиях. Иногда для увеличения ёмкости приходится создавать новый пул и переносить данные.

Если доступность важна, стоимость такого переноса и время, когда придётся держать две копии, нужно включить в проект ещё до покупки дисков.

Разберитесь в основных уровнях RAID

RAID 0 распределяет данные по нескольким дискам без избыточности. Он может повысить пропускную способность, но отказ любого накопителя обычно означает потерю всего массива. Для единственной копии важных данных это плохой выбор.

RAID 0 может быть оправдан для временного рабочего пространства, кэша или материала, который можно быстро пересоздать, - при условии, что потеря не сорвёт работу.

RAID 1 создаёт зеркальные копии. В простейшем варианте из двух дисков один продолжает обслуживать данные, если второй выходит из строя.

Чтение иногда ускоряется за счёт одновременной работы накопителей, но точный эффект зависит от контроллера и нагрузки; запись должна попасть на обе стороны зеркала.

RAID 1 удобен для небольших систем, где важна простота, однако его цена за полезный терабайт высока: половина сырой ёмкости уходит на копию.

RAID 5 распределяет данные и контрольные сведения о чётности между дисками. Массив выдерживает отказ одного накопителя и использует ёмкость эффективнее зеркала.

Обратная сторона - более сложные операции записи и повышенный риск при восстановлении большого массива: до завершения перестроения второй отказ диска может привести к потере всего тома.

RAID 5 не становится автоматически плохим при любой ёмкости, но чем больше и нагруженнее массив, тем внимательнее нужно оценивать время восстановления и вероятность ошибки чтения на остальных накопителях.

RAID 6 использует две независимые схемы чётности и обычно переживает отказ любых двух дисков.

За дополнительную защиту платят ёмкостью и некоторыми накладными расходами при записи. Для массивов из HDD большой ёмкости RAID 6 часто рассматривают как практичный компромисс: полезного пространства остаётся больше, чем в RAID 10, а запас по отказам выше, чем у RAID 5.

Однако это не освобождает от резервного копирования и мониторинга.

RAID 10 сочетает зеркалирование и распределение данных по нескольким зеркальным парам. Он обычно хорошо подходит для интенсивных случайных операций и быстро восстанавливается: после отказа копируется содержимое одной зеркальной пары, а не пересчитывается чётность всего набора.

Но ёмкость обходится дороже. Важная тонкость: RAID 10 может выдержать отказ нескольких дисков, только если они находятся в разных зеркальных парах. Если откажут обе стороны одной пары, массив теряется.

Существуют и вложенные варианты, например RAID 50 и RAID 60, где несколько групп с чётностью объединяют общим распределением данных.

Они позволяют строить более крупные массивы и локализовать некоторые последствия отказов, но усложняют проектирование.

Уровень, его ограничения и реакцию на отказ нужно проверять по документации конкретного контроллера или программного решения: одинаковое название не всегда означает одинаковое поведение при расширении, замене диска и деградации.

• RAID 0 выбирают только там, где данные не являются единственной копией и потерю можно принять.

• RAID 1 подходит для небольших объёмов и простых зеркальных конфигураций.

• RAID 5 экономит ёмкость, но оставляет запас только на один отказ диска.

• RAID 6 выдерживает два отказа и часто удобнее для больших групп HDD.

• RAID 10 предпочитают при высокой нагрузке и важной скорости восстановления, если бюджет позволяет.

Уровень RAID - не оценка "хорошо" или "плохо", а распределение компромиссов. Нельзя выбрать схему только по проценту полезной ёмкости: нужно учитывать нагрузку, допустимый простой, размер группы, время восстановления и наличие проверенной резервной копии.

Даже лучший по расчётам уровень может оказаться неудачным, если массив собран из неподходящих дисков или администратор не получает уведомлений о деградации.

Учтите ёмкость дисков и риск восстановления

Восстановление массива - период повышенного риска. После отказа диск заменяют, а контроллер или программная система восстанавливает недостающие данные на новый накопитель. В RAID с чётностью для этого приходится читать информацию с оставшихся дисков и пересчитывать потерянное содержимое.

Пока операция идёт, массив может работать медленнее, а при дополнительном отказе возможности зависят от уровня RAID и конкретной структуры массива.

Время перестроения нельзя надёжно предсказать только по формуле "объём диска разделить на скорость".

На него влияют нагрузка, приоритет восстановления, скорость чтения исходных дисков, состояние контроллера, ошибки чтения и размер блока. Например, для диска на 20 ТБ даже непрерывное чтение со скоростью 200 МБ/с в идеальных условиях потребовало бы около 28 часов, но реальная перестройка может занимать существенно дольше.

Если система в это время обслуживает приложения, часть ресурсов уйдёт на пользовательские операции.

Чем больше дисков в группе, тем больше накопителей участвуют в обслуживании данных и тем больше информации может потребоваться прочитать при восстановлении. Это не значит, что большой RAID непременно небезопасен, но он требует более строгого подхода к резервированию и наблюдению.

Для крупных объёмов часто сравнивают одну большую группу с несколькими меньшими: разделение может локализовать последствия отказа, но добавляет сложности в управлении и может изменить доступную ёмкость.

Для простого объяснения риска иногда приводят показатель частоты неисправимых ошибок чтения из спецификации диска. Например, если в паспорте указан предел порядка одной неисправимой ошибки на 10¹⁵ прочитанных бит, чтение десятков терабайтов во время перестроения уже требует внимания.

Но превращать это число в точный прогноз потери массива нельзя: это характеристика модели и условий тестирования, а не персональная вероятность отказа конкретного диска.

Важны качество партии, температура, возраст, вибрация, нагрузка и то, как система реагирует на ошибки чтения.

Особенно внимательно оценивайте RAID 5 на больших дисках и в массиве, который должен оставаться доступным при восстановлении. Он защищает от одного отказа, но во время перестроения запаса на ещё один отказ нет.

RAID 6 оставляет дополнительную чётность и обычно даёт больший люфт. RAID 10 часто восстанавливается быстрее, однако отказ двух накопителей одной пары всё равно критичен. Ни одна схема не отменяет мониторинг SMART и журналов контроллера: предупреждение о проблемном секторе, росте ошибок или перегреве лучше обнаружить до деградации массива.

Помните и о скрытых отказах. Диск может формально оставаться в массиве, но иметь участки, которые плохо читаются. Контроллер способен пометить накопитель неисправным после временной ошибки, а кабель или корзина - создать симптомы, похожие на поломку диска.

Поэтому порядок действий при сбое должен включать проверку журналов, состояния линии и самого носителя, а не только немедленную замену первого устройства, на которое указал интерфейс.

Сопоставьте RAID с реальной нагрузкой

Производительность массива складывается из характеристик дисков, контроллера, интерфейса, кэширования, файловой системы и характера запросов.

Простое сложение паспортных скоростей отдельных HDD обычно даёт слишком оптимистичную оценку.

При последовательном чтении больших блоков массив может загружать несколько дисков параллельно. При случайных операциях головкам HDD приходится часто перемещаться, и выигрыш от числа накопителей может быть намного меньше ожидаемого.

RAID 10 часто выбирают для виртуализации и транзакционных систем, поскольку зеркальные пары хорошо работают со случайными операциями и не требуют такого же пересчёта чётности, как RAID 5 или RAID 6. Но это не правило без исключений: современные контроллеры и SSD могут изменить картину, а конкретная нагрузка - включать длинные последовательные записи.

Перед решением полезно измерить рабочую систему или воспроизвести характерные запросы в тесте, который похож на реальную эксплуатацию.

Для потоковой работы с видео важна устойчивая последовательная пропускная способность, особенно когда несколько монтажёров читают материал одновременно. Дополнительные диски могут увеличить суммарную скорость, но сеть, контроллер и рабочие станции тоже должны быть достаточно быстрыми.

Если массив способен выдавать условные 2 ГБ/с, а подключён по каналу, который ограничивает обмен, покупка дополнительных накопителей не устранит узкое место.

Для SSD-массивов меняется профиль производительности, но не исчезают компромиссы. SSD обеспечивают низкие задержки и высокую скорость случайного доступа, однако имеют ресурс записи, особенности внутреннего сборщика мусора и требования к защите от потери питания.

RAID защищает от отказа устройства, но не гарантирует сохранность незавершённых записей, если кэш контроллера или накопителя потерял питание. Для важных систем проверьте поддержку защиты кэша, конденсаторов в SSD и корректную работу команды TRIM в выбранной конфигурации.

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

Не отключайте кэш и не меняйте режим его работы вслепую: сначала выясните, что именно обеспечивает сохранность данных при внезапном отключении электричества.

Оценивать массив стоит по нескольким показателям одновременно:

• пропускная способность при последовательном чтении и записи;

• число случайных операций ввода-вывода и задержка, особенно в хвосте распределения;

• поведение под смешанной нагрузкой чтения и записи;

• производительность во время перестроения или проверки массива;

• время восстановления после отказа, а не только скорость в штатном режиме.

Для сравнения конфигураций проводите тесты на объёме и типе данных, похожих на рабочие. Короткий тест на пустом SSD может измерять кэш, а не устойчивую производительность. Тестирование на одном большом файле не покажет, как система поведёт себя при одновременной работе нескольких виртуальных машин.

Желательно фиксировать условия: размер блока, очередь запросов, долю чтения и записи, число потоков и состояние кэша. Тогда результаты можно сравнивать, а не просто выбирать красивую цифру из отчёта.

Выберите диски и контроллер без слабых мест

Для большого хранилища важно не только, сколько дисков установлено, но и предназначены ли они для предполагаемой нагрузки. NAS- и enterprise-модели обычно рассчитаны на длительную непрерывную работу и могут иметь функции, полезные при построении массива.

Но маркировка "серверный" сама по себе не гарантирует совместимость, низкий уровень отказов или устойчивость к любой нагрузке. Проверяйте поддерживаемый интерфейс, формат сектора, ограничения контроллера и рекомендации производителя системы.

В одном массиве лучше использовать диски одной ёмкости и сопоставимых характеристик. Если добавить накопитель меньшего объёма, многие схемы будут использовать его как ограничение для всей группы.

Смешивание моделей возможно, но нужно учитывать различия в скорости, времени отклика и поведении при ошибках.

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

Для больших ёмкостей обращайте внимание на технологию записи. SMR-диски могут хорошо подходить для преимущественно последовательного архивного использования, но длительные случайные записи и перестроение RAID способны вызвать заметное падение скорости.

CMR-диски обычно предсказуемее в многопользовательской нагрузке и при восстановлении. До покупки проверьте точную модель и её документацию: внешне похожие варианты внутри одной линейки могут существенно отличаться по способу записи.

Аппаратный RAID-контроллер может предоставить централизованное управление и кэш, но создаёт зависимость от конкретного оборудования и его формата метаданных. При выходе контроллера из строя может понадобиться совместимая модель или процедура импорта массива.

Программный RAID часто проще переносить между системами того же семейства, однако требует достаточных ресурсов хоста и грамотной настройки операционной системы.

Нельзя объявить один подход универсально надёжнее другого: важны поддержка, документация, доступность запасных частей и опыт команды.

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

Если планируются накопители большой ёмкости, убедитесь, что контроллер, прошивка и операционная система корректно их распознают и не ограничивают адресуемое пространство.

Кабели, корзины и блок питания тоже входят в цепочку надёжности. Неплотный контакт или перегрев может вызвать отключения диска, которые выглядят как отказ накопителя.

Для серверной установки важны направленный поток воздуха, контроль температуры и питание с запасом.

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

Наконец, заранее решите, где будет храниться запасной диск. Накопитель на полке не помогает, если для его установки нет совместимой корзины или доступ к серверу ограничен. С другой стороны, постоянно установленный hot spare начинает восстановление автоматически, но занимает отсек и остаётся частью той же системы.

Для критичных сервисов можно хранить совместимый запас на площадке, а для удалённого объекта - продумать срок доставки и процедуру временного перехода на резерв.

Не забывайте о файловой системе и программных хранилищах

RAID отвечает за распределение данных по носителям, но верхний уровень хранения тоже влияет на целостность и удобство эксплуатации.

В одних системах RAID-массив создают контроллером, а затем поверх него размещают обычную файловую систему. В других программная платформа сама управляет дисками, контрольными суммами, кэшем и восстановлением.

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

Некоторые файловые системы и программные хранилища умеют проверять контрольные суммы данных и метаданных. Это помогает выявить повреждение, которое простое зеркалирование может незаметно скопировать на обе стороны: RAID 1 гарантирует наличие копии, но без дополнительной проверки не всегда способен определить, какая версия содержимого правильная.

В системах с контрольными суммами и несколькими копиями возможны механизмы самовосстановления, если архитектура и конфигурация позволяют однозначно выбрать корректные данные.

Однако функции файловой системы не следует смешивать с резервной копией. Снимок, созданный на том же пуле, может помочь быстро вернуть случайно изменённый файл, но не спасёт при отказе всего массива, краже сервера или повреждении системы хранения.

Репликация на другой сервер полезнее, но мгновенно может передать туда удаление или шифрование. Для полноценной защиты нужны отдельные копии, политика хранения и проверка восстановления.

Если используется SSD-кэш для HDD-массива, уточните, какие данные он кэширует и что происходит при его отказе. Кэш чтения обычно можно восстановить из основного массива. Кэш записи потенциально содержит ещё не подтверждённые на дисках данные и поэтому требует защиты от потери питания и отказа устройства.

В документации должны быть понятны режимы записи, порядок сброса кэша и условия, при которых система сообщает приложению, что операция завершена.

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

Поэтому обновления сначала проверяют на тестовой системе, а конфигурацию и инструкции восстановления хранят отдельно от самого хранилища.

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

Частоту проверки выбирают с учётом объёма, скорости дисков и нагрузки: слишком редкий запуск откладывает обнаружение ошибок, а слишком частый добавляет нагрузку. Не следует запускать проверку без понимания её влияния на производительность рабочего массива.

Спланируйте отказоустойчивость, обслуживание и мониторинг

Надёжность массива зависит не только от его уровня, но и от того, насколько быстро команда узнаёт о проблеме и начинает действовать.

Если диск вышел из строя в пятницу вечером, а уведомление попало в нечитанный системный журнал, защита RAID фактически работает без контроля.

Настройте оповещения о деградации, ошибках ввода-вывода, перегреве, проблемах с батареей контроллера, заполнении пространства и длительном восстановлении.

Уведомления должны приходить туда, где их действительно увидят: в систему мониторинга, дежурному специалисту или ответственному каналу. Полезно разделить критические события и предупреждения.

Сообщение о потере избыточности нельзя ставить в один ряд с информацией о плановом обновлении.

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

После замены диска не считайте работу завершённой, пока перестроение не завершилось и массив снова не стал исправным. Следите за скоростью операции, ошибками чтения и температурой соседних накопителей. Если перестроение резко замедлилось или появились ошибки на других дисках, механическая замена очередного устройства наугад может ухудшить ситуацию.

У каждой системы должен быть свой документированный порядок: как определить правильный отсек, как безопасно извлечь диск и как проверить, что новый накопитель принят в массив.

В больших хранилищах полезны плановые проверки состояния дисков и самого массива, но тесты нужно запускать с учётом рабочей нагрузки. Следите за температурой, количеством переназначенных и ожидающих переназначения секторов, ошибками интерфейса и статистикой чтения.

Один тревожный показатель не всегда означает немедленную поломку, а отсутствие предупреждений не гарантирует абсолютную исправность. Сопоставляйте данные SMART с журналами контроллера и динамикой за несколько недель, а не только с разовой оценкой "здоров/не здоров".

Проверьте, как система переносит штатные, но неприятные события: внезапное отключение питания, перезапуск контроллера, извлечение неисправного диска, заполнение тома и потерю связи с одним накопителем.

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

Учение часто обнаруживает проблемы раньше, чем реальная авария: например, выясняется, что пароль от контроллера хранится только у уволившегося сотрудника.

Отдельно продумайте обновление оборудования. Когда сервер приближается к концу срока поддержки, перенос массива должен быть самостоятельным проектом, а не импровизацией в день отказа. Уточните, можно ли импортировать конфигурацию на новую платформу, совместимы ли диски и нужны ли промежуточные этапы.

Для очень больших объёмов копирование данных может занять дни, поэтому заранее определите окно переключения и способ сверки результата.

RAID не заменяет резервное копирование и план восстановления

Избыточность RAID помогает пережить отказ определённого числа накопителей, но массив остаётся одной системой.

Если пользователь удалил каталог, контроллер записал повреждённые данные или программа-вымогатель зашифровала файлы, RAID добросовестно сохранит уже испорченное содержимое на всех участниках массива.

Защита от таких сценариев требует независимых резервных копий, которые нельзя изменить теми же учётными данными и тем же способом, что и рабочие данные.

Практичный план резервирования может включать несколько экземпляров на разных носителях и площадках, в том числе офлайн- или неизменяемую копию.

Конкретная схема зависит от стоимости простоя и потери данных. Для одних организаций достаточно ежедневной копии с длительным хранением; для других нужны частые резервные точки и репликация в другой дата-центр.

Важно определить два показателя: допустимый объём изменений, который можно потерять, и допустимое время восстановления сервиса.

Резервная копия полезна только тогда, когда её можно восстановить. Периодически проверяйте отдельные файлы и целые системы, фиксируйте время восстановления и сравнивайте его с требованиями бизнеса.

Копирование без теста может выглядеть успешным годами, но обнаружить отсутствие нужного ключа, повреждение каталога или неверные разрешения получится лишь в аварии.

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

Нужно также следить за пропускной способностью резервной инфраструктуры. Если за сутки создаётся 5 ТБ новых данных, а канал передачи позволяет отправлять только 1 ТБ за тот же период, очередь будет расти.

В таком случае резервное копирование не успевает за изменениями, даже если хранилище RAID работает быстро. Проведите тест с реальной скоростью передачи, включая шифрование, дедупликацию, компрессию и восстановление нескольких крупных наборов данных.

Снимки и репликация могут дополнять резервные копии, но не всегда заменяют их. Снимки обычно зависят от исходного пула; репликация может перенести ошибку или вредоносное изменение. Независимая копия должна иметь собственный срок хранения, контроль доступа и отдельную проверку.

Если все копии доступны одному администраторскому аккаунту, злоумышленнику, получившему этот аккаунт, может быть достаточно одной атаки, чтобы повредить весь контур защиты.

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

Сам RAID остаётся первым уровнем доступности, резервное копирование - способом вернуть данные после логической или физической катастрофы, а аварийный план связывает оба уровня в работающую процедуру.

Практические сценарии выбора конфигурации

Архив медиаданных на HDD. Если данные в основном записываются последовательно, читаются нечасто, а цена полезного терабайта важна, можно рассматривать RAID 6 или другой вариант с двойной чётностью.

Например, восемь HDD по 20 ТБ дадут ориентировочно 120 ТБ сырого полезного пространства до форматирования. Такая оценка не учитывает файловую систему и резерв свободного объёма.

Нужно проверить скорость записи, реальное время восстановления, температурный режим и наличие резервной копии на другой системе.

Если архив пополняется непрерывным потоком, оцените скорость поступления данных и окно на обслуживание. Важна не только максимальная скорость одного массива, но и способность оставаться в рабочем состоянии во время проверки целостности и перестроения.

Убедитесь, что модель дисков подходит для длительной записи, а видеосистема корректно переживает деградацию хранилища.

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

Пул виртуальных машин. Здесь часто важны случайные операции, низкая задержка и быстрый возврат к штатной производительности после отказа. RAID 10 на SSD может быть хорошим кандидатом, если полезная ёмкость и бюджет позволяют.

Например, из восьми SSD по 7,68 ТБ получится около 30,72 ТБ до форматирования и системных расходов. Но итоговую схему стоит проверять тестами виртуализационной платформы: число виртуальных дисков, размер блока, нагрузка на запись и используемый кэш способны существенно изменить результат.

Не забудьте про резервирование самих виртуальных машин, включая конфигурацию гипервизора, сетевые настройки и каталоги, необходимые для запуска. Массив может пережить поломку SSD, но не заменит резервную копию машины и не гарантирует восстановления после ошибочного обновления.

Для критичных систем заранее отрепетируйте восстановление виртуальной машины на другом узле, а не только проверку отдельных файлов.

Видеомонтаж и совместная работа. Для крупных последовательных файлов важны полоса массива и сеть. RAID 6 может дать хорошее соотношение ёмкости и защиты, но скорость нужно измерять при нескольких одновременных потоках.

RAID 10 может обеспечить более предсказуемую работу при смешанном доступе, но заметно снизит полезный объём.

В некоторых студиях удобно разделить быстрый рабочий пул на SSD и ёмкое хранилище готовых материалов на HDD, а не пытаться сделать один универсальный массив для всех задач.

При такой архитектуре нужно продумать перенос между уровнями: кто решает, какие проекты остаются на быстром пуле, как проверяется копирование и сколько времени хранятся исходники.

Рабочий SSD-массив не должен становиться единственным местом для незавершённого проекта, если отказ диска приведёт к потере недельной работы.

Система резервирования должна учитывать большие последовательные файлы: иногда восстановление нескольких терабайтов занимает дольше, чем сама замена накопителя.

Резервное хранилище. Здесь часто допустима более скромная скорость, зато важны цена, вместимость и защита от логического повреждения.

RAID 6 может быть разумной основой пула, но резервные копии следует держать отдельно от исходных данных и по возможности на другой площадке или носителе. При расчёте учтите не только текущую копию, но и версии, срок хранения, ежедневный прирост и место для временной обработки резервных наборов.

Для резервного хранилища также важна скорость чтения при восстановлении. Если сервер приложения должен вернуться в работу за несколько часов, а восстановление данных займёт два дня, бюджетная конфигурация не соответствует требованиям, даже если копии формально есть.

Проведите пробное восстановление на тестовый сервер и измерьте не только скорость дисков, но и время поиска нужной версии, передачи по сети, проверки целостности и запуска сервисов.

Небольшой филиал или локальное хранилище. Здесь ценны простота обслуживания и понятный механизм оповещения. Зеркало из двух дисков может быть удобным для умеренного объёма, если критичные данные дополнительно копируются в центральное хранилище.

При увеличении ёмкости стоит сравнить стоимость установки ещё одной зеркальной пары с более плотной конфигурацией и оценить, кто будет менять диски на месте. Наличие RAID без удалённых уведомлений не поможет, если филиал неделями работает с деградированным массивом.

Для каждого сценария полезно составить небольшую таблицу требований: полезная ёмкость, скорость, допустимое число отказов, время восстановления, бюджет и способ резервирования.

В ней сразу видно, где компромисс не сходится.

Если нужны одновременно максимальная ёмкость, высокая скорость, низкая цена и отсутствие простоев, одной конфигурацией RAID эти требования не удовлетворить - придётся менять архитектуру, делить данные по классам или увеличивать бюджет.

Пошаговый алгоритм перед покупкой

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

Разные типы нагрузки могут эффективнее обслуживаться отдельными пулами, а повреждение или заполнение одного тома не обязательно должно влиять на все остальные.

Затем оцените текущую и будущую ёмкость. Переведите единицы измерения, посчитайте полезный объём после избыточности, добавьте свободное пространство и рост на плановый срок.

Отдельно определите, как будет выполняться расширение: добавлением дисков, заменой на более ёмкие накопители или созданием нового массива. Проверьте, сколько времени займёт перенос данных и где они будут размещены на переходном этапе.

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

Для массивов большой ёмкости не ограничивайтесь подсчётом "сколько отказов выдерживает уровень": учитывайте, какие именно диски могут выйти из строя и как долго система будет работать без полного запаса избыточности.

Выберите несколько подходящих вариантов, например RAID 6 и RAID 10, и сравните их на конкретной нагрузке. Рассчитайте полезную ёмкость, оцените цену дисков, контроллера и резервного оборудования, а затем проверьте узкие места сети и серверной платформы.

При возможности проведите нагрузочный тест и измерьте производительность в штатном режиме, во время восстановления и после заполнения части массива данными.

Перед вводом в эксплуатацию настройте мониторинг, уведомления и документируйте расположение дисков. Запишите, какой серийный номер соответствует каждому слоту, как безопасно заменить накопитель, какие действия требуют остановки системы и где лежит резервная копия конфигурации.

Проверьте, что восстановление действительно работает. Наконец, назначьте ответственных за обслуживание и установите порядок регулярной проверки ёмкости, состояния носителей и резервных копий.

1. Опишите нагрузку: тип данных, размер файлов, частоту чтения и записи, число пользователей.

2. Посчитайте полезную ёмкость с учётом избыточности, свободного места и прогнозируемого роста.

3. Определите допустимое число отказов и срок, в который массив должен вернуться в нормальный режим.

4. Выберите диски, контроллер или программную платформу с проверенной совместимостью.

5. Сравните несколько уровней RAID по ёмкости, скорости, стоимости и поведению при восстановлении.

6. Подготовьте отдельное резервное копирование и проведите тест восстановления.

7. Настройте мониторинг, уведомления, запасные диски и понятную инструкцию обслуживания.

Главный ориентир при выборе - не максимально возможный процент полезного пространства и не самая высокая цифра скорости в рекламной таблице.

Хороший RAID соответствует реальной нагрузке, оставляет запас по ёмкости, позволяет предсказуемо пережить отказ и восстанавливается в срок, который допустим для бизнеса или работы.

Для больших объёмов особенно важны двойная проверка расчётов, контроль состояния дисков и практическая отработка восстановления.

И ещё одно правило, которое легко упустить при обсуждении уровней RAID: избыточность - только часть защиты данных. Если массив пережил отказ диска, но вместе с ним потеряны резервные копии или доступ к ключам шифрования, задача не решена.

Планируйте хранилище целиком: диски, контроллер, питание, сеть, мониторинг, резервирование и людей, которые будут действовать при сбое. Именно такая система, а не одно название RAID, определяет, насколько спокойно большой объём данных переживёт реальную аварию.

Примечания к оценкам

¹ Приведённые значения полезной ёмкости - ориентировочные расчёты для одинаковых дисков. Фактический доступный объём зависит от единиц измерения, контроллера, файловой системы, метаданных и выбранного резерва свободного пространства.

² Примеры времени чтения и перестроения иллюстрируют порядок величины, а не гарантируют конкретный срок. Фактическое восстановление зависит от модели накопителей, уровня нагрузки, настроек массива и состояния остальных дисков.