Миф: RAID — это уже резервная копия

MAATRIX

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

Откуда берётся эта уверенность

Миф растёт из реального опыта: диск в RAID 1/5/6/10 действительно может умереть, и ничего страшного не произойдёт — массив перейдёт в деградированный режим, сервис продолжит работать, вы поменяете диск и запустите rebuild. Это работает, это проверено, это именно то, ради чего RAID и придумали. У человека, который один или два раза пережил отказ диска без единой минуты простоя, естественным образом формируется ощущение: «данные защищены, что бы ни случилось». Дальше это ощущение просто не проверяется на других сценариях, потому что другие сценарии (кроме отказа диска) до поры до времени не случаются.

Добавляет уверенности и то, что RAID-контроллеры и mdadm показывают понятный, вычисляемый статус — clean, degraded, rebuilding — и это выглядит как система, которая «следит за сохранностью данных». На деле она следит только за физической целостностью и доступностью блоков на дисках, а не за смысловой корректностью того, что в этих блоках записано. Про эту разницу подробно можно прочитать в разборе что происходит с массивом в первые секунды после отказа диска — там же видно, что вся логика RAID построена вокруг физического диска как единицы отказа, и больше ни вокруг чего.

Что RAID действительно защищает

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

Как это работает по уровням:

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

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

Почему порча данных реплицируется мгновенно на все диски

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

Отсюда прямое следствие: если испорчены сами данные, а не диск, RAID распространит эту порчу на все копии за доли секунды. Конкретные сценарии, где это происходит:

• Случайное удаление. rm -rf /var/www/html/uploads выполняется один раз на файловой системе — и RAID тут же честно применяет эту операцию ко всем дискам зеркала. Восстанавливать нечего: удалённые блоки одинаково удалены везде.
• Шифровальщик. Вирус-шифровальщик читает файл, шифрует его содержимое и перезаписывает поверх оригинала. Каждая такая перезапись — обычная операция записи с точки зрения RAID, она реплицируется на все диски массива так же исправно, как и легитимная запись. Через несколько минут работы шифровальщика у вас на 100% дисков больше зашифрованных файлов, а не одна уцелевшая копия.
• Логическое повреждение таблицы БД. Баг в приложении, оборванная транзакция без отката, битый индекс после сбоя питания — данные в файле .ibd или .frm физически целы, но логически некорректны. MySQL или PostgreSQL честно пишут эти байты на диск, RAID их честно копирует. CHECKSUM TABLE через месяц покажет расхождение, а RAID к этому моменту уже давно синхронизировал повреждение везде.
• Повреждение файловой системы. Битый суперблок ext4, рассинхронизированный журнал XFS после некорректного отключения — если ошибка попадает в данные, а не только в метаданные на лету восстанавливаемые самой ФС, она попадает во все копии массива одновременно.

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

Чего RAID не защищает вообще

Кроме логической порчи данных, у RAID есть ещё несколько слепых зон, о которых миф тоже предпочитает не думать:

• Отказ самого контроллера или блока питания дисковой полки. Если аппаратный RAID-контроллер сгорает или зависает целиком, недоступным становится сразу весь массив — избыточность дисков не спасает от отказа устройства, которое ими управляет. Обычно к моменту такого отказа помогает только замена контроллера с сохранённой конфигурацией — либо восстановление из другого источника.
• Кража, пожар, затопление сервера целиком. RAID живёт внутри одного корпуса. Если сгорела серверная, украли сервер целиком или его залило — сгорели, украли или залило все диски массива одновременно, вне зависимости от уровня RAID.
• Ошибка администратора. DROP DATABASE production; или rm -rf / — это операции на уровне выше RAID, они выполняются один раз и реплицируются идеально точно, без малейшего шанса на «а вдруг на одном из дисков не успело примениться». Человеческий фактор — по разным независимым оценкам одна из самых частых причин реальной потери данных, и RAID перед ней полностью бессилен по конструкции.
• Постепенная деградация без своевременной замены диска. Отдельная история, когда мониторинг молчит, а второй диск в массиве отказывает вскоре после первого — она разобрана в постмортеме про диск, который сыпался месяц, пока мониторинг молчал. Это тоже не защита от порчи данных, а частный случай неправильной эксплуатации самого RAID.

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

Бэкап — это принципиально другое: отделение во времени и в пространстве

Бэкап устроен ровно наоборот тому, как устроен RAID, и в этом вся суть разницы.

Отделение во времени. Бэкап — это снимок данных на определённый момент в прошлом, который физически не переписывается новыми данными автоматически. Если файл испортили в 14:03, а последний бэкап снят в 02:00, у вас есть версия данных, в которой порчи ещё не было. RAID этой возможности не даёт в принципе — у него нет понятия «версия», есть только «текущее состояние, размноженное на N дисков».

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

Отсюда и практическое правило 3-2-1, которое стоит держать как минимальный чек-лист:

• 3 копии данных — оригинал плюс минимум две резервные;
• 2 разных носителя/системы хранения — не полагаться на один тип отказа;
• 1 копия физически в другом месте — вне того здания и того RAID-массива, где лежит оригинал.

Инструменты вроде restic, borgbackup или kopia дают именно версионирование и удалённое хранение из коробки — снапшот делается инкрементально, старые версии остаются доступными отдельно от новых, и всё это физически лежит не на том массиве, где крутится продакшен:

# пример: снапшот с версионированием на удалённый репозиторий
restic -r sftp:backup-vps:/repo backup /var/lib/mysql /var/www
restic -r sftp:backup-vps:/repo snapshots
restic -r sftp:backup-vps:/repo restore latest --target /restore

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

Постмортем: RAID 10 без бэкапа и убитая база

Небольшой интернет-магазин на выделенном сервере с RAID 10 из четырёх NVMe-дисков. Администратор настраивал инфраструктуру два года назад, RAID собирал сам, следил за SMART, один раз даже пережил замену диска без простоя — ровно тот положительный опыт, который и укрепляет миф. Бэкапы «когда-нибудь надо будет настроить» так и остались в списке задач без срока.

Ночью разработчик выкатывает миграцию базы — скрипт с ошибкой в условии WHERE, который вместо обновления цен у одной категории товаров обнуляет поле price у всей таблицы products. Скрипт отрабатывает штатно, без ошибок, транзакция коммитится. MySQL честно записывает изменённые страницы на диск, RAID 10 честно и мгновенно зеркалирует эту запись на все четыре диска. Через восемь секунд после запуска миграции обнулённая цена одинаково лежит во всех копиях массива — если бы сотую долю секунды спустя один диск физически сгорел, это не имело бы вообще никакого значения для сохранности испорченных данных.

Проблему замечают утром, когда на витрине у всех товаров цена «0 ₽» и заказы идут по нулевой стоимости. Первая реакция администратора — «восстановим из RAID, у нас же зеркало». Дальше приходит понимание: зеркало отражает текущее состояние, а не состояние до 3:14 ночи. RAID 10 переживёт отказ любого одного диска из каждой пары — но не умеет отмотать время назад ни на секунду, потому что это вообще не его задача.

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

Частые вопросы