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)
Ответ на: комментарий от Stanson

отследить замену неисправного диска на работающий

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

про СХД я говорю уверенно, я больше 20 лет с ними отработал, SCSI/SAS/FC, неожиданных случаев хватало. также бывали и нештатные случаи при замене на том же LSI (HW RAID). ну и на них отдельный секас если диск не с нуля и там уже есть чужая разметка LSI, вот тут точно с mdadm сильно попроще будет. ну и тащемта, по оф. инструкции на него тоже нужны телодвижения:
https://techdocs.broadcom.com/us/en/storage-and-ethernet-connectivity/enterprise-storage-solutions/12gbs-megaraid-tri-mode-software/1-0/v11668655/v11672350/v11672410/v11672536.html

и упомянутые простые шаги требуются во всех SW RAID: mdadm, VxVm, SVM, ZFS.

ну и отдельный смех - про «Появился какой-то живой диск в порту в котором ранее был битый - всё, заливай туда данные», начать тут надо с того, что линукс ему другое имя может дать или на самом деле это тот же самый диск, FW его перезагрузила, его опять отстрелят и так по кругу пока система совсем колом не встанет. именно поэтому там никто не делает. а также про человека, своими руками что-то делающего. я уже видел всё, и как вместо ЯВНО подсвеченного диска и указанного места (на СХД и серверах чаще всего подписано) - вынимали его соседа или вообще левый диск.
типичная история: https://sysadmins.ru/topic525233.html

так какие проблемы сделать простые шаги по инструкции?
тем более LSI это тоже требует? или это недостаточно HW RAID?;-)

PS: не увидел про 1064 - вот с этим у меня как-то раз был продолжительный секас. и да, он обычно ничо не требовал потому, что был максимально тупой. но не всегда. megaraid там тоже требовался. адаптеки в массе не требовали кстати. мир их праху! НО только если ты нулёвый диск туда пихаешь. может на самом деле у тебя там 1064 в IT mode был, а не IR?

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

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

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

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

как вместо ЯВНО подсвеченного диска и указанного места (на СХД и серверах чаще всего подписано) - вынимали его соседа или вообще левый диск.

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

так какие проблемы сделать простые шаги по инструкции?

Проблема не в сложности или простоте шагов. Проблема в необходимости их делать.

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

да, он обычно ничо не требовал потому, что был максимально тупой

Вот в том числе поэтому KISS - аццки рулит. А вот когда начинаются всякие smart™, intelligent® и т.п. - вот тогда и начинается геморрой.

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

У проксмокса юзать штатный функционал бэкапа = продолбать данные с гарантией.

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

Да, что ты чёрт возьми несёшь)

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

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

А где в документации сказано, что не включенные в бэкап точки монтирования будут отформатированы при восстановлении? Что при восстановлении удаляются detached тома, которые были в момент снятия бэкапа? Что при удалении диска все его бэкапы тоже удаляются, и старые снимки станут невалидны? Что id дисков, которые больше не принадлежат виртуалке, тупо берутся из старой забэкапленной конфигурации с затиранием чужих данных?

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

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

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

Uber прыгал туда-сюда уже 10 лет назад, неужели все эти соображения до сих пор актуальны?

10 лет в софте - это эпоха, за это время в софте очень многое успевает поменяться.

Например, 10 лет назад был актуальным Cent OS 7. Если сейчас зайти на сервер с Cent OS 7, то будешь плеваться от того, насколько всё старое и неудобное, даже какие-то фишки в кондовом bash уже успели поменяться и за 10 лет успеваешь привыкнуть к хорошему.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

ты можешь оказатся очень прав, я 6 лет назад эти проекты пилил, может что то на фронте и поменялось, а очень может и нет, ибо архитектура pgsql не поменялась - удачная о чём mysql клонам можно только мечтать (хранимые процедуры почти на любом языке ...), но есть недостатки.

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

А где в документации сказано, что не включенные в бэкап точки монтирования будут отформатированы при восстановлении?

есть предупреждение

CT ### - Restore. This will permanently erase current CT data. Mount point volumes are also erased.

mishki
()
Ответ на: комментарий от EAT_INSIDE

Что при удалении диска все его бэкапы тоже удаляются, и старые снимки станут невалидны?

при удалении VM PBS не удалет бэкапы, их можно удалить только вручную, с подтверждением, написав что просит в окне удаления: ‘vm/xxx’

mishki
()
Ответ на: комментарий от mishki

Это другое™, там ещё лулз с совпадением ID старой и новой виртуалок в имени архива.

Я про удаление снимков диска, связанных со старыми бэкапами, при снятии у него галки «backup» в ресурсах контейнера.

EAT_INSIDE
() автор топика
Ответ на: комментарий от EAT_INSIDE

Ты можешь здесь еще раз расписать по пунктам эти проблемы, я задам вопросы на форуме у разрабочиков. Если ты этого не делал. Речь про Proxmox Backup Server или про штатные бэкапы в составе PVE?

mishki
()
Ответ на: комментарий от Stanson

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

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

Вообще-то у нормальных контроллеров есть админская утилита для их настройки,

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

и она умеет всё что может от неё потребоваться

Да щаз. Эти админские утилиты написаны корпорастами для корпорастов и они все убогие и корявые поделки, которые обычно пригодны лишь для того чтобы показывать состояние массива. Да и даже для этого лучше использовать какую-нибудь опенсорсную утилитку написанную людьми для людей, ибо она хотя бы не чинит препятствий для автоматизации и например для опций использует стандартные -x/–xxx а не какой-то бред. Ну и для каких-то действительно важных действий приходится лезть в BIOS контроллера.

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

В общем, хреново всё в 21 веке с восстановлением FT/HA после поломки. Не, сцуко, ну каким утырком надо быть, чтобы выдумать какие-то там коллизии и якобы не понимать, например, «а как же можно автоматически определить какой диск содержит правильные данные и откуда куда надо данные скопировать». Да сцуко тот, который не фейлился. И это не только к RAID относится - вон, для сраного mysql/mariadb и то подавай аж минимум 3 машины в кластере, а то непонятно им, видите ли, на какой тачке база зафейлилась, поэтому нужно никак не меньше трёх машин. Сраные шестёрки железопроизводителей.

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

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

И вообще, как ты себе представляешь работу схд, который для замены диска, не говоря уж о создании массива, надо ребутать и отправлять в даунтайм всех клиентов? Его ж никто не купит такой (ну, максимум купят 1 раз когда ещё не будут знать об этой особенности).

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

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

А я не представляю, их есть у меня. IBMы с долбанными адаптеками, HP с их Smart Array и т.п. Да, именно в BIOS лезть. И далеко не факт что оно вообще новый диск схавает. Адаптеки этим славны, например.

Его ж никто не купит такой (ну, максимум купят 1 раз когда ещё не будут знать об этой особенности).

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

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

Вот HP SmartArray у меня всяческие были: 5i, 6i, 6400, P400, P410, P420, E2xx… Не было только отстоя типа B-серии, которая fake raid.

Диски менял примерно раз в месяц. Не из-за того, что простоянно ломались, просто когда дисков много, так получается.

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

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

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

Вот HP SmartArray у меня всяческие были: 5i, 6i, 6400, P400, P410, P420, E2xx…

Поздравляю.

Не было только отстоя типа B-серии, которая fake raid.

Это вообще не RAID, даже на fake не тянет.

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

А не HP диски пробовал туда засовывать? :) Я даже молчу про другой объем и геометрию.

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

Разумеется.

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

Что за бред? Контроллер неспособен запомнить какой диск зафейлился, и разобраться вместо какого диска засунули новый?

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

А не HP диски пробовал туда засовывать? :)

Разве это поддерживается HP?

Я даже молчу про другой объем и геометрию.

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

Что за бред? Контроллер неспособен запомнить какой диск зафейлился, и разобраться вместо какого диска засунули новый?

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

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

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

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

Разве это поддерживается HP?

Частенько поддерживается. Я так и не понял от чего зависит. Два одинаковых DL360, серийники даже несильно отличаются. Одному пофиг HP или нет, другой ничего кроме HP не признаёт. Даже та же самая модель диска, но не брендированная как HP - ни в какую.

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

И всё это перезагрузки, автоматом?

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

Такой опыт. Весьма продолжительный. Из всех серваков, самые геморройные это HP, кстати. Хотя, если повезёт с моделью и версиями прошивок, могут десятилетиями пахать.

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

Ага. При отсутствующем мониторе и клаве. Очень правильно. Хорошо если в ILO есть возможность в биосе поковыряться и RAID инициализируется при загрузке после ILO.

Stanson ★★★★★
()