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

Что именно защищает массив

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

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

Сценарии, где избыточность не помогает

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

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

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

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

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

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

Почему снимок — тоже не копия

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

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

Признаки настоящей резервной копии

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

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

Как эти два механизма работают вместе

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

Отсюда и порядок планирования. Сначала определяют, какой объём потерянной работы допустим и как быстро сервис обязан вернуться в строй, — эти две величины задают частоту копий и требования к каналу восстановления. Затем под требования непрерывности подбирают схему массива и запас по накопителям. Подбор дисковой подсистемы под конкретный профиль нагрузки разобран в разделе о серверных комплектующих.

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