LINUX.ORG.RU
ФорумAdmin

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

 , ,


0

1

История успеха, немного по мотивам А вот хочу 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)

RAID и не был НИКОГДА средством бекапа!!! В зависимости от версии и конфигурации - это средство ускорения доступа, средство бесперебойности доступа (твой случай), чтобы если диск вылетит оно продолжало 24/7 фурычить или комбинация целей (ускорение и бесперебойность), могут отличаться количества дисков, ускорение, разные коэффициенты в работе, но это никогда не бекап

anonymous
()

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

К другим новостям:

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

Не благодари.

CrX ★★★★★
()

RAID - не бэкап

Да ты прям капитан очевидность. Хромой.

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

ofp
()
Ответ на: комментарий от Vsevolod-linuxoid

Сам proxmox обновился, под копотом, скорее всего, простой apt upgrade. Хз, может, я что-то не так делаю, но не в первый раз загрузчик приходится восстанавливать. На этот раз со спецэффектами.

EAT_INSIDE
() автор топика

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

Видимо, это.

Плюс ты, после того как накатил, видимо, промахнулся дисками. Не надо после накатывания заниматься странными вещами.

P.S. hotswap в sata появился давным-давно, никаких проблем с ним нет.

Dimez ★★★★★
()

Ну вообще RAID и не подразумевался никогда как средство бэкапа.

Вообще, чисто теоретически, какой-нибудь RAID1/5/6 могли бы в какой-то степени выполнять отдельные функции бэкапа на предмет сохранности данных при поломке одного из дисков, если бы не один нюанс. о котором никто и никогда не думает при создании всяких подобных систем - подключение нового диска вместо сдохшего - это всегда пердоолинг и всегда через жопу. Хотя казалось бы. Железячные RAID иногда могут автоматически подцепить новый диск вставленный вместо умершего, но это зависит от погоды на марсе и не дай Бог на новом диске есть какие-то разделы или тем более ФС. А чаще всего конечно приходится лезть в BIOS RAID’а чтобы заставить это ублюдство понять что да, это, сцуко, новый диск взамен старого, что да, можно там всё нахер перезаписать, что вообще не надо туда лазать, а просто записать туда свой заголовок и скопировать, сцуко, данные с другого диска/дисков.

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

В общем, RAID и бэкап связаны только в том смысле, что если диск в RAID’е с резервированием сдох, то надо срочно данные с RAID’а бэкапить, потому что далеко не факт что RAID удастся привести в первоначальное состояние до поломки.

Stanson ★★★★★
()

указав резервный суперблок ext4

Это потому что у тебя LVM с btrfs не было, как у местных админов лолхоста.

Через некоторое время захотелось накатить™. Сначала прогнал апдейт

Сначала надо было протрезветь.

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

В общем, RAID и бэкап связаны только в том смысле, что если диск в RAID’е с резервированием сдох, то надо срочно данные с RAID’а бэкапить, потому что далеко не факт что RAID удастся привести в первоначальное состояние до поломки.

Золотые слова! Очень не всегда исполнимые, но золотые.

anc ★★★★★
()

Note: mdraid не хранит никакие контрольные суммы в блоках.

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

Tanger ★★★★★
()

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

s-warus ★★★★
()
Последнее исправление: s-warus (всего исправлений: 1)

из всех рейдов только 0 хорошь: ускоряет на mdadm, lvm удобный но соединяет друг за другом профита ускорения нет, и обединяет разделы. rsinc (и его аналоги) /home/user на разные машины для одного пользователя проблему быстрых бекапов решают.

s-warus ★★★★
()

Ну, молодец что в итоге вырулил)

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

Поэтому я храню как минимум некоторые копии вообще на максимально дубовых носителях с максимально понятной фс, ну и в идеале периодически проверять, да)

frunobulax ★★★★
()