Что делать, если в RAID 5 отказал диск?

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

Можно ли восстановить RAID 5 после потери двух дисков?

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

Переживёт ли RAID 10 потерю одного диска?

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

Защитит ли удалённая копия от шифровальщика?

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

Можно ли хранить бэкап на другом томе того же сервера?

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

Достаточно ли успешного статуса задания бэкапа?

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

Почему RAID — не резервное копирование: защита данных сервера

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

RAID и резервная копия решают разные задачи

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

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

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

Когда RAID помогает, а когда нужна независимая копия

Что покрывают RAID и резервные копии

Событие	Поможет ли RAID	Когда поможет независимый бэкап	Что нужно для восстановления
Отказ одного диска	Да, если уровень допускает такой отказ и остальные компоненты доступны. Например, RAID 5 обычно остаётся доступен с одним отказавшим диском.	Если массив не удалось штатно восстановить, произошли сопутствующие ошибки или нужно вернуть данные после неудачных действий.	Исправная копия, совместимая среда и процедура восстановления; для массива — отдельная процедура замены и Rebuild.
Два отказа дисков	Зависит от уровня и сочетания дисков. RAID 5 при потере двух дисков обычно не сохраняет данные. RAID 6 рассчитан на отказ любых двух дисков. В RAID 10 результат зависит от того, находятся ли диски в одной зеркальной паре.	Да, если копия создана до события и не затронута общей причиной отказа.	Отдельное хранилище копий, нужная версия данных и проверенный порядок возврата.
Случайное удаление файлов	Нет. Удаление становится текущим состоянием массива.	Да, при наличии версии, созданной до удаления, и достаточной глубине истории.	Выбрать нужную точку восстановления и вернуть файлы в отдельное место или на исходный сервис.
Вирус-шифровальщик	Нет. RAID записывает зашифрованные данные так же, как любые другие изменения.	Да, если есть незатронутые версии и копия изолирована от учётных данных и путей, доступных злоумышленнику.	Версионность, разграничение доступа, при необходимости неизменяемое хранение или физически изолированная копия.
Сбой приложения или повреждение базы данных	Обычно нет: логически повреждённые блоки могут быть корректно сохранены на всех дисках массива.	Да, если есть согласованная копия БД либо поддерживаемая точка восстановления и журналы транзакций.	Процедура конкретной СУБД, совместимые файлы данных и журналы, проверка согласованности после восстановления.
Отказ RAID-контроллера или сервера	Не всегда. Массив может быть исправен, но недоступен из-за контроллера, его кэша, конфигурации или самого сервера.	Да, если копия размещена в независимой системе и доступна для восстановления на другом оборудовании.	Совместимая целевая инфраструктура, доступ к копии и документированная процедура запуска сервиса.
Потеря площадки: пожар, затопление, кража, длительная авария питания	Нет, если все диски и сервер находятся на площадке.	Да, если копия размещена в другом независимом месте и доступна.	Удалённая копия, канал или доставка носителя, подготовленная площадка либо вычислительные ресурсы для запуска.

Почему RAID 5 и RAID 10 с отказавшим диском не становятся бэкапом

Запрос «RAID 5 отказ диска» обычно означает, что массив может продолжить работу в деградированном режиме, пока отказан один диск и остальные участники читаются корректно. После замены диска избыточность восстанавливается в процессе Rebuild. Но в этот момент на массиве остаются только актуальные данные: удалённый файл, повреждённая таблица или результат ошибочной перезаписи уже неоткуда вернуть.

При запросе «RAID 5 потеря двух дисков» ответ обычно отрицательный: RAID 5 рассчитан на отказ одного диска, а не двух. Это не повод экспериментировать с оставшимися накопителями: при проблеме массива важнее сначала сохранить сведения о конфигурации и состоянии. Действия до изменений на дисках описаны в статье «Восстановление RAID после сбоя».

Запрос «RAID 10 потеря диска» обычно имеет более благоприятный ответ: один отказавший диск может быть пережит при сохранности его зеркального партнёра. Однако RAID 10 с одним отказавшим диском всё равно не является бэкапом — он не содержит исторической копии. При двух отказах RAID 10 может остаться работоспособным, если диски принадлежат разным зеркальным парам, и может стать недоступным, если отказали оба диска одной пары. Подробное сравнение уровней — в статье «Как выбрать RAID 0, 1, 5, 6 или 10».

Деградированный массив — не штатное состояние

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

Что произойдёт при удалении, шифровальщике и ошибке базы данных

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

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

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

Домен отказа важнее количества дисков в массиве

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

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

Какие копии нужны малому серверу помимо RAID

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

Размещение копий и компромиссы

Тип копии	Что обычно даёт	Какие риски может разделять	Что проверить
Локальная на отдельном хранилище	Обычно самое быстрое восстановление больших объёмов данных.	Помещение, питание, сеть, часть административных учётных данных; иногда — сам сервер.	Что хранилище действительно отдельное, хватает скорости и места для восстановления, есть нужные версии.
Внешняя на отключаемом или отдельно подключаемом носителе	Изоляцию от постоянно доступной сети при корректной процедуре отключения и хранения. Восстановление не требует передачи всей копии с удалённой площадки, но носитель нужно получить и подключить.	Физическую потерю, пожар или кражу, если носитель остаётся в том же помещении; риск ручных ошибок.	Регулярность обновления, время доставки и подключения, скорость чтения, условия хранения, шифрование при необходимости и возможность прочитать носитель.
Удалённая на другой площадке или в независимой системе	Возможность восстановиться при потере основной площадки.	Компрометацию учётных данных, шифровальщик и ошибочное удаление, если нет версий, изоляции и ограничений прав.	Время передачи и восстановления, доступность целевой среды, версионность, права доступа и защиту копий.

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

Правило 3-2-1 — отправная эвристика

Распространённое правило 3-2-1 предлагает иметь не менее трёх экземпляров данных, на двух типах носителей, с одной копией вне основной площадки. Это полезный ориентир для проектирования, но не универсальная гарантия и не единственно допустимая схема. Например, оно не заменяет проверку восстановления, защиту учётных записей и выбор глубины истории.

Как выбрать частоту, способ и срок хранения бэкапов

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

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

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

Модель выбора схемы резервного копирования

Это не настройка конкретной программы, а последовательность проектных решений.

1
Определите критичные данные и зависимости
Составьте перечень файлов, баз данных, конфигураций, ключей, виртуальных машин и сервисов. Отдельно укажите порядок их восстановления: сервер может быть технически восстановлен, но сервис останется недоступен без зависимой БД, DNS, ключей или конфигурации.
2
Задайте RPO и RTO для каждой группы
Зафиксируйте допустимую потерю изменений и допустимый простой. Не применяйте один показатель ко всем данным автоматически: архив и рабочая база заказов обычно имеют разные требования.
3
Определите глубину истории и срок хранения
Решите, на какую дату или версию может понадобиться откат, и учтите обязательные сроки хранения. Проверьте, что политика очистки не удалит нужные версии раньше времени.
4
Разберите угрозы и домены отказа
Учтите отказ диска, сервера, контроллера, питания, ошибку администратора, шифровальщик и потерю площадки. Для каждого сценария проверьте, остаётся ли хотя бы одна пригодная копия вне затронутого домена отказа.
5
Выберите размещение и защиту копий
Добавьте отдельное локальное хранилище, если нужен быстрый возврат, и удалённое размещение, если нужно пережить потерю площадки. Настройте версии, разделение учётных записей и, где требуется, поддерживаемую неизменяемость или изоляцию.
6
Проверьте восстановление
Регулярно восстанавливайте нужные версии в отдельную среду, измеряйте фактическое время и фиксируйте результат. По итогам корректируйте частоту, хранение, объём хранилища или процедуру.

Как убедиться, что резервная копия пригодна

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

Восстанавливайте не только отдельный файл, но и критичные наборы данных: базу данных, конфигурацию, права доступа и зависимости сервиса.
Проводите восстановление в отдельной среде, чтобы не перезаписать рабочие данные и не принять работающий сервер за результат теста.
Проверяйте, что возвращена нужная версия, файлы читаются, база проходит предусмотренную СУБД проверку, а приложение запускается.
Измеряйте фактическое время от начала восстановления до готовности сервиса и сравнивайте его с RTO.
Проверяйте доступ к копиям после изменения паролей, прав, инфраструктуры, формата хранения и обновления ПО.
Документируйте результат, найденные ограничения и порядок восстановления; затем повторяйте тест по расписанию.

Копия без проверки может не помочь в аварии

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

Термины в статье

Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Деградированный режим: Состояние отказоустойчивого RAID-массива, потерявшего часть избыточности, но сохраняющего доступ, пока сочетание отказов допустимо для его уровня и раскладки.
Дисковая корзина: Дисковая корзина — узел шасси с отсеками для установки нескольких накопителей и организации их подключения к питанию и контроллеру либо HBA.
Домен отказа: Домен отказа — группа компонентов с общей причиной недоступности, отказ которой может одновременно вывести из строя несколько копий данных или сервисов.
Избыточность данных: Избыточность данных — хранение дополнительных копий или контрольной информации, позволяющее восстановить данные при отказе носителя, блока или другого компонента.
Физический диск: Физический диск — отдельный HDD, SSD или иной накопитель, распознанный RAID-контроллером как член массива либо как независимое устройство.
Чётность: Избыточные контрольные данные, вычисляемые из блоков одной полосы RAID. Один блок чётности защищает от отказа одного диска, два независимых блока RAID 6 — от отказа двух.
Consistency Check: Consistency Check — фоновая проверка согласованности избыточности RAID: зеркальных копий либо рассчитанной и записанной чётности; расхождения могут исправляться.
Failed: Failed — статус физического накопителя, который RAID-контроллер признал отказавшим и перестал использовать для штатного ввода-вывода в составе массива.
RAID: Технология объединения нескольких накопителей в логические блочные устройства для повышения производительности и/или отказоустойчивости в зависимости от RAID-уровня.
RAID 1: RAID 1 — уровень RAID с зеркалированием данных на двух или более дисках. Полезная ёмкость равна ёмкости наименьшего участника, а доступ сохраняется, пока исправна хотя бы одна копия.
RAID 10: Комбинированный уровень: чередование (RAID 0) поверх зеркальных пар (RAID 1). Сочетает высокую скорость и отказоустойчивость, отдавая под избыточность половину ёмкости.
RAID 5: RAID 5 — уровень RAID с чередованием данных и распределённой чётностью, выдерживающий отказ одного диска. Требует минимум трёх дисков.
RAID 6: Уровень RAID с чередованием данных и двойной распределённой чётностью. Выдерживает отказ любых двух дисков; минимум четыре диска.
RAID-контроллер: Устройство или модуль, который формирует RAID-массивы из накопителей и предоставляет ОС логические диски, управляя размещением данных, отказами и восстановлением избыточности.
RAID-уровень: RAID-уровень — схема размещения данных и избыточности по накопителям массива, определяющая полезную ёмкость, отказоустойчивость и характеристики ввода-вывода.
Rebuild: Процесс восстановления избыточности массива после замены отказавшего диска: контроллер вычисляет и записывает на новый диск недостающие данные из остальных дисков.