LINUX.ORG.RU
ФорумAdmin

Ахахах, оказывается, RAID - не бэкап

 , ,


0

2

История успеха, немного по мотивам А вот хочу RAID на Proxmox, например. .

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

Акт I

Взял массив с фоточками, воткнул его в nas на горячую (что я, лох что ли, гасить гипервизор, когда железо hot plug поддерживает), mdraid автоматом его подцепил, фоточки смонтировались. Здорово, - подумал я, - линукс и вправду с человеческим лицом.

Акт II

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

Ладно, дурное дело не особо хитрое. Лайвсили, чрут, установка загрузчика на системный ssd. Не впервой.

После загрузки меня ожидала следующая картина:

  • диск 0 - отформатирован в MBR, создан один раздел неизвестного типа на всю ёмкость

  • диск 1 - linux raid, всё ок

  • диск 2 - отформатирован в GPT, опаньки, потерянный boot раздел нашёлся, затерев первый гигабайт ^_^

Ну вы поняли, ахахах. 2 из 3 томов RAID 5 попячены, наслаждайся своей половиной данных, нашинкованных по 512K.

Акт III

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

Так, смотрим. Данные на дисках физически есть, strings находит текстовики, которые там были. Теоретически, в такой ситуации достаточно было взять диски 0 и 1, как наименее повреждённые, и пересоздать на них массив с теми же характеристиками, скрестить пальцы и вычитать данные, указав резервный суперблок ext4. Но нифига - несмотря на ту же версию метаданных и порядок дисков, никакое из сочетаний не давало живой ФС на выходе.

В итоге пришлось гуглить гуглы, качать проприетарную r-studio, ЧИТАТЬ МАНУАЛ и почти целый день ждать, пока она соберёт образ из повреждённого массива. Что удивительно, результат сборки сразу смонтировался, и даже по мнению fsck оказался вполне приемлемым. Фоточки спасены. Happy end.

Эпи-нафиг-лог.

Было потрачено 4 дня времени и 15к на диск под промежуточные операции. Оверпрайсный диск останется у меня, а вот времени жалко.

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

Что было сделано не так?

Стратегически - отсутствие бэкапа.

Технически? Наверное, можно выделить

  • выпендрёж с горячим подключением консьюмерских железок

  • применение неподдерживаемого массива

  • возможно - использование прямой установки RAID на диск, а не в раздел

  • вероятно, я накосячил при восстановлении загрузчика, усугубив ситуацию os-prober’ом, хоть и не понимаю, зачем и как именно

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

Перемещено hobbit из general



Последнее исправление: EAT_INSIDE (всего исправлений: 4)
Ответ на: комментарий от EAT_INSIDE

вопросов больше не имею

твой мозг маркетолог покусал (), у меня есть много проектов на pgsql, консольная утилита у него самая лучшая, в скоростях только sqllite в однопоточном обходит, но схема репликаций, работа паралельных серверов отвратная, почитай статьи почему Uber от pgsql в сторону mysql перешёл, немного не по этому, но по этой причине репликации pgsql не айс.

s-warus ★★★★
()
Ответ на: комментарий от anonymous

А какие есть? «Включение», «выключение», «магические метки» дисков, чтобы не перепутать при «включении»?

Или рассказывается про работу заранее известного упорядоченного набора определенным образом отформатированных дисков?

anonymous
()
Ответ на: комментарий от s-warus

начать надо с того - какой у тебя raid?

если mdadm, то желательно (но не обязательно) - обнулить MBR/GPT до вставки. ну или заведомо новый пихать. далее, если диски одинаковые изначально - делаешь либо sfdisk -d SRC pipe sfdisk TGT, либо sgdisk -R=TGT SRC; sgdisk -G TGT - смотря что у тебя с разметкой (MBR/GPT); потом mdadm -a TGT, пойдёт resync. ждёшь. на это обычно всё. ну плюс smartctl -a сделать и желательно общий вид разметки иметь в файле.

в других sw raid по-другому, но суть та же.

mumpster ★★★★★
()

RAID это не про бекап конечно, а про скорость или стабильность работы. Бекап должен быть инкрементальный и служить для того, чтоб восстановить какое-либо состояние твоих данных (возможно прошлое). Вот смотри, сломал тебя злой кулхацкер и поменял на твоём сайте все буквы о на o. И стало у тебя мoлoкo вместо молоко. А ты на этом сайте молоком торгуешь. Поисковик тебя в выдаче по запросу молоко вообще воспринимать перестанет. Ты сразу не заметил (выдача падает, а сайт визуально такой же, никаких скриптов нет, дефейса нет, хорошо всё). В RAID у тебя всё отзеркалится и будешь ты буквы o руками искать. А если у твоего сайта ещё и англоязычная версия сайта есть, то скриптом (как взломщик) тебе не вариант - only превратится в оnly и опять всё будет работать плохо. А так ты бекап инкрементальный распакуешь до момента взлома и восстановление пойдёт легче. А вот если у тебя HDD от старости рассыпался, то RAID позволит твоему сайту работать и продавать, а потом ты новый диск воткнёшь. С бекапом так не получится.

peregrine ★★★★★
()
Ответ на: комментарий от mumpster

а в чём проблема вообще?

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

там просто несколько шагов которые надо сделать и всё.

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

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

Да, большинство железных RAID контроллеров требуют лезть в биос и что-то там вручную размечать/добавлять/подключать после замены диска на новый. Однако существование контроллеров которые этого абсолютно не требуют, типа Symbios Logic SAS1064E (последний про который я точно знаю что в него просто втыкаешь любой новый диск равного или большего размера вместо битого и через некоторое время видишь что рейд сам восстановился и всё ОК, так же как и раньше), однозначно доказывает что это всё нахер не нужно, ни в железячных контроллерах, ни в программных типа mdraid.

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

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

большинство железных RAID контроллеров требуют лезть в биос

Лезть в BIOS - это означает перезагрузку. То есть ты хочешь сказать, что большинство аппаратных RAID-контроллеров не поддерживают замену дисков по-горячему, и требуют перезагрузки сервера?

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от bigbit

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

Да. В лучшем случае, новый диск должен быть как-то там специально размечен заранее. Иногда проканывает диск забитый нулями но точно такой же геометрии и объёма. Но если на диске есть, например ФС, то без лазанья в биос или как минимум без шаманства через проприетарную утилиту для этого рейда - хрен он подцепляет новый диск.

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

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

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 4)