Raid и резервирование

[RomanK]

Добрый день!
Имеем Raid 5 (иногда, правда, и он нас). 5 дисков, два раздела: на первом - 2 тома (системный С: и софт D:), на втором - 1 (базы).
Недавно рухнул, вышел из строя один диск, при ребилде отвалился второй.
Задумался про резервирование. Резервирование баз делаю на сетевое хранилище.
Как быть с системным разделом. Сделал образ системного тома С: и зарезервированной области Acronis-ом.
1. Получится данный образ раскатать под загрузочным диском Acronis?
2. Что станет с томом D:?
3. Что станет с raid? Уйдет в ребилд первого раздела?

Спасибо!

[SergeyB]

Добрый день!
Имеем Raid 5 (иногда, правда, и он нас). 5 дисков, два раздела: на первом - 2 тома (системный С: и софт D:), на втором - 1 (базы).
Недавно рухнул, вышел из строя один диск, при ребилде отвалился второй.
Задумался про резервирование. Резервирование баз делаю на сетевое хранилище.
Как быть с системным разделом. Сделал образ системного тома С: и зарезервированной области Acronis-ом.
1. Получится данный образ раскатать под загрузочным диском Acronis?
2. Что станет с томом D:?
3. Что станет с raid? Уйдет в ребилд первого раздела?

Спасибо!

Добрый день.
Ну в общем основное - рейду абсолютно неважно (и он об этом не должен знать) какие на нем разделы, он ниже уровнем. Если вываливается диск - он в degraded mode и пока не заменим все очень плохо (читай вывалится еще диск - и кранты).
Заменили - начинаем восстановление (это само). А сколько там каких разделов рейд не волнует, система ж видит рейд как один физический диск и начинает его уже разбивать и тд (загрузочная запись, натягиваем ФС и тд).
Наличие рейда не отменяет бекапы, тут тоже верно

Посоветую все-таки систему поставить на отдельный диск (хоть 120Gb SSD) - и быстрее, и действительно регулярно бекапить и если что - раскатать. В противном случае с восстановлением и загрузкой могут быть проблемы.
А продакшн - на рейд.
Ну хотя бы так, вкратце.

[gs]

Посмотрите Veeam endpoint backup.
Акронис - если только серверный. И предварительно проверьте весь цикл бэкап-рестора.

[RomanK]

Спасибо!

Посмотрите Veeam endpoint backup.
Акронис - если только серверный. И предварительно проверьте весь цикл бэкап-рестора.

SSD хорошо конечно, дома уже давно стоят.. В конторе проблемней денег выбить..
Какие проблемы могут возникнуть при развертывании из образа системного тома в raid 5?
acronis серверный.
После распада рейд хочу возможные проблемы узнать, а потом пробовать. А то второй раз за месяц потеря рейда с данными перебор.

[Umlyaut]

Какие проблемы могут возникнуть при развертывании из образа системного тома в raid 5?
acronis серверный.

При исправном железе - и "исправном" софте - никаких.

И да - как Вам правильно указали выше, Вы разворачиваете системный образ не "в raid5", а на LUN (том, раздел, etc.), расположенный на рейд-группе размерности R5.
С т.з. B/R-софта - в Вашем случае акрониса - destination LUN "непрозрачен", акронис "не видит" размерность рейд-группы под тем местом, куда он разворачивает образ.
Главное - чтобы софт вообще увидел destination LUN, сиречь, имел в себе драйвер под данный контроллер (для серверного акрониса как правило, с этим всё ОК... если он не сильно старее Вашего контроллера ).

После распада рейд хочу возможные проблемы узнать, а потом пробовать. А то второй раз за месяц потеря рейда с данными перебор.

Побуду Кассандрой, процитирую Вас же:

Недавно рухнул, вышел из строя один диск, при ребилде отвалился второй.

Главная рекомендация - завязывайте с R5.
Альтернативы - R6 или R10 (зависит от Ваших условий: профили нагрузки, аппаратное обеспечение, etc.).

Ну и не пренебрегать "мелочами" (именно в кавычках!).

- BBU на кеш контроллера (чтоб не накернилось недописанное "есличо");

- не пренебрегать HSD (может статься, сокращение интервала между выпаданием диска и неспешной его заменой для ребилда как раз даст успеть восстановить избыточность);

- включайте CC и прочие patrol reading`и - в том числе и на HSD;

- если контроллер и диски поддерживают опцию PI по стандарту T10/DIF, то включив её (и отформатировав физ.сектора дисков под соответствующий размер) получите ещё один уровень надёжности для своих данных - на уровне физ.секторов диска

Как-то так...

[lem0n]

Имели в институте аналогичный геморрой с RAID10. Для резервирования пользовались Handy Backup, ему на RAID непринципиально, и NAS устройством, но всё равновсё попыталось грохнуться, когда один диск вышел в degrade. После смены физического диска стало всё ещё хуже, оказалось, что серия диска под замену не соответствует той, которая уже стояла (хотя подбирали с цифрами в руках). К счастью, была только база, и для неё делался ещё один бэкап, потому что в итоге, когда разобрались с NAS, всё стало плохо. К софту здесь претензий никаких, всё отработало, а вот сам по себе RAID может подкидывать неожиданные сюрпризы. Поэтому теперь используем grandfather-father-son схему, и не пытаемся полагаться на надёжность RAIDов (скорость — другое дело!).

[Umlyaut]

Имели в институте аналогичный геморрой с RAID10. Для резервирования пользовались Handy Backup, ему на RAID непринципиально, и NAS устройством,

Странный оборот, как по мне.

RAID-группа (LUN/VD на ней) "видится" ОС и софтом, исполняемым в ней, как некий "диск", без нижележащих подробностей его устройства (размерность массива и прочие его настройки/параметры).
Иначе говоря, упомянутому Вами ХэндиБыкапу не может быть "принципиально" или "непринципиально" "на RAID", бо он про RAID абсолютно не в курсе.

Единственный вариант, допускающий Вашу трактовку - это если Вы быкапите RAID-группу не "на горячую", быкап-софтом, установленным в ОС и работающим вместе с ней, а "на холодную", путём загрузки с лив-носителя от быкап-софта.

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

но всё равновсё попыталось грохнуться, когда один диск вышел в degrade.

Ещё одна загадка - что значит "попыталось грохнуться"???

При деградации сабъюнита в R10 (одного из составляющего рейд-группу "зеркал") R10 работает точно так же, как и в стандартной моде (в отличие от конфигураций с чётностью - R5x/R6x).
Нет ни повышения нагрузки на него, ни каких-то ещё "отягчающих обстоятельств" - т.е. "грохаться" в этом виде ему не с чего.

Конечно, если затем выйдет из строя и второй, оставшийся, диск из деградировавшего "зеркала"-сабъюнита, то тогда действительно можно будет говорить, что вся рейд-группа R10 "грохнулась".
Но у Вас, как я понимаю, до этого не дошло - оттого это Ваше "попыталось грохнуться" выглядит крайне загадочно.

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

Ну вот, опять...
Что такое "стало ещё хуже"?
В чём это проявлялось?
Что значит "серия диска"? Условный Констеллейшен, только вместо стоявшего условного релиза J поставили условный релиз H или N? Или вместо условного Констеллейшена сунули условную Барракуду?

И с какими "цифрами в руках" подбирали? Не глядя на серию/семейство "в лоб" сравнивали AvgTime и прочие Seek?
Короче, не очень понятна эта претензия к дискам в разрезе описываемой проблемы.

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

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

Товарищ, да Вы прямо "мастер заголовка"... ой, то есть умелец выражаться загадочно.
Ну мы всё же в специализированном разделе технического форума - а Вы "когда разобрались с NAS, всё стало плохо".

Просто даже с т.з. лексики и логики в голову не лезет - конструкция "разобраться с <железка>" всегда обозначала успешную отладку для нормальной работы (хоть в плане начальной настройки, хоть в плане восстановления после дизастера какого).
То есть было никак или плохо -> разобрались -> стало нормально/хорошо.

А у Вас после того, как "разобрались", "стало плохо".
Вы мне моск сломали!

К софту здесь претензий никаких, всё отработало, а вот сам по себе RAID может подкидывать неожиданные сюрпризы. Поэтому теперь используем grandfather-father-son схему, и не пытаемся полагаться на надёжность RAIDов (скорость — другое дело!).

Кгхммммм... как бы мне так поделикатнее намекнуть Вам...

Конечно, я всегда говорил и говорю, что "рейд быкапу не замена", но верно и обратное.
Рейд - это одна из линий обороны ДО того, как в ход пойдёт быкап.
Надеюсь, термины RPO и RTO Вам что-то да говорят?

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

Кстати, впредь желательно указывать марки контроллеров и дисков, с которыми у Вас были траблы (как у В.В.:"а из зала мне кричат - давай подробности!"" ).
А то если описанное Вами было на, к примеру, каком-нибудь FastTrack или Promise, то тут и удивляться-то нечему будет, только посочувствовать останется.

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

UPD: что-то вдруг вдогонку подумалось...

если упоминавшийся Вами R10 располагался на некоем NAS, а последний был в меру плюшевым (типа Powasonic/Abibas ), то тогда неудивительны любые метаморфозы этой сущности.

Рейд-группы любого "NAS-искаропки" - это софтверные массивы, с учётом тотальной экономии в дешёвых "NAS"`ах на комплектухе и принимая во внимание саму системную слабость этих устройств (где один SoC работает "прислугой за всё" - и дисковый ввод-вывод на нём, и сетевой, и ОС с сервисами отжирает своё) они весьма малопригодны для нормальной работы, являясь даже не SOHO, а просто HO... и то с оговорками и натяжками.