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

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

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

Нет там таких слов.

Тебе конкретно зачем репликация бд? По твоим комментариям же видно, что ты мягко скажем, далек от этого.

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

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

много раз делал замену сдохших дисков в т.ч. в R5/R6

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

у меня статистика маленькая и плохая, я проклят.

начать надо с того - какой у тебя 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 по-другому, но суть та же.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

про СХД я говорю уверенно, я больше 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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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