консистентность данных при резком пропадании питания (чтоб массив не пересобирался целиком!)

Write-intent bitmap.

в случае чего - увидить данные на дисках в другой системе - т.е. цеплять весь RAID целиком в другую ОС, систему.

Какую другую? Windows? OS X? DOS? OS/2?

куда ставить mdadm на весь HDD или на партицию?

Без разницы, если не нужен загрузчик.

mdadm то вообще как?

Вообще ничего.

3ware на 6-10 тысяч?

Скорее за 20-30.

ИМХО

куда ставить mdadm на весь HDD или на партицию? - Чтобы как можно легче увидить все массивы + lvm + данные на другой системе в случае чего?

Без разницы

mdadm то вообще как? Торт? Или лучше купить аппаратный RAID 3ware на 6-10 тысяч?

лучше mdadm

ну или может как-то по-другому есть смысл всё организовать?

Все что Вы описали работать будет.

mdadm на 100% наше все.
Яндекс с Гуглом врать не будут :)

Скорее за 20-30.

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

купить аппаратный RAID 3ware

Умножай на два, в случае аппартных рэйдов.

Когда закончится место нужно будет ещё добавлять диски, я добавлю ещё скажем два диска. - Создам /dev/md1 - присоеденю его к lvm, и расширю ФС.

Создам /dev/md1 - присоеденю его к lvm

вот этого делать не надо.

Когда закончится место нужно будет ещё добавлять диски, я добавлю ещё скажем два диска. - Создам /dev/md1 - присоеденю его к lvm, и расширю ФС.

Есть некоторые опасения относительно того как LVM будет данные распределять. Хотя они компенсируются рейдом конечно.

Вот и я почему то чувствую, что этого делать не надо... А как надо? :) Просто докупать диски нужного объёма? И в крайнем случае иметь несколько точек монтирования и переливать данные в случае чего? (такое также возможно и допустимо в моём случае т.к. будут различные данные например: 10 гб фоток за много лет компании, 100-200 гб дистрибутивов ПО (да-да SAP AG наше фсё), и изменяемые данные).

Ну наверное не стоит так делать, если есть в общем-то возможность этого избежать?

Воооооот, и я слышал в том-же Radio-t, что аппаратные RAID мертвы как уже давно...

Ну вроде что-то такое ведь есть: http://www.nix.ru/price/virtualshop_cb.html?new_basket=1 с энергонезависимым кешем. Вот и думаю, что лучше mdadm или такая штуковина.

Какую другую? Windows? OS X? DOS? OS/2?

Сейчас планирую Ubuntu 12.04 x 64 или x32, в будущем что-то подобное если полетит винт с ОС.

Write-intent bitmap

Не слышал про такое дело. Пойду читать. Скорость записи в общем и целом не дюже волнует. Backup будет ночью шуршать неспешно.

я не изменю мнения.

Ок! В общем читаю тут: https://raid.wiki.kernel.org/index.php/Write-intent_bitmap и не буду пользоваться lvm. Если система будет стоять на отдельном винте и с ним начнутся проблемы, то я думаю, что это я легко переживу (при наличии бекапов конфигов mdraid, кстати они критичны?), что вообще нужно будет для того, чтобы диски увиделись в другой системе?

что вообще нужно будет для того, чтобы диски увиделись в другой системе?

Они соберутся по метаданным.

Расскажите это, скажем, p220i на Gen8...

Ок. А как усложнит мне жизнь если я скажем на один из серверов (в офисе в одном бекапить надо не много данных, порядка 100 gb), поставлю два б/у диска, один на 120 gb, другой на 200. - Создам на них по разделу в 110 gb, и уже на раздел поставлю mdadm c Write-intent bitmap? Слышал, что можно даже и не создавать разделы, а прям так поставить mdadm, и он сам разберётся что на больший диск не стоит записывать данных больше чем на меньший. - В общем как тут надо поступать более разумно? Чтоб как можно легче было увидеть данные в случае чего на другой ОС linux.

Или лучше купить аппаратный RAID 3ware на 6-10 тысяч?

аппаратный рейд нужен в довольно редких случаях, и хранение бекапов это тот случай когда аппаратный рейд категорически не нужен

Ну у меня конечно не столь обширные задачи. :) Мне важно сейчас обеспечить консистентность backup данных в rdiff-backup репозитарии. Не более.

Вот и я также считаю. Но решил с грамотным народом посоветоваться.

А, вроде всё можно, и всё просто. http://askubuntu.com/questions/4244/move-raid1-to-new-machine - оно само всё должно задетектить. Спасибо в очередной раз! Буду тестировать, так глядишь переползу из админов первой категории в админы которые уже делают... :)

Торт?

торт

RAID 3ware на 6-10 тысяч?

не торт

чтоб массив не пересобирался целиком!

bitmap настрой. Только будет бить по производительности. Возможно, это можно вынести на другой девайс.

куда ставить mdadm на весь HDD или на партицию?

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

консистентность backup данных в rdiff-backup репозитарии.

это как?

несколько серверов на mdadm, перешёл с аппаратного контроллера. (данных примерно пара терабайт обычно). Полёт нормальный. Даже лучше чем с аппаратным потому что не нужно обновлять прошивку/дрова контроллера. Ну и с «увидеть данные» в другом линуксе у аппаратного контроллера сильно хуже чем у mdadm я думаю. ибо нужен будет такой же контроллер точно.

у меня именно так и работает. и именно с теми же целями. отчего не надо?

Ок. А как усложнит мне жизнь если я скажем на один из серверов (в офисе в одном бекапить надо не много данных, порядка 100 gb), поставлю два б/у диска, один на 120 gb, другой на 200. - Создам на них по разделу в 110 gb, и уже на раздел поставлю mdadm c Write-intent bitmap?

не усложнит. вообще.

bitmap настрой. Только будет бить по производительности. Возможно, это можно вынести на другой девайс.

вроде можно вынести, но и на том же девайсе бьёт по производительности не сильно если предварительно подобрать chunk size и сколько-метров-на-бит-битмапа приходится. если не подбирать, может просесть до 2х раз ЕМНИП. Жаль статью не написал когда себе собирал раид...

Чтоб как можно легче было увидеть данные в случае чего на другой ОС linux

По моему мнению, достаточным условием будет аналогичная (не обязательно) версия mdadm/метаданных. В этом то и прелесть решения.

Жаль статью не написал когда себе собирал раид...

Действительно жаль.

от того, что если вытащить диски того raid, весь vg разрушится

а если без lvm вытащить диски того раид то не разрушится?

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

да, конечно. смысл в том, чтобы была «модульность»:

/dev/md0 vg0
/dev/md1 vg1

а если будет

/dev/md0 vg0
/dev/md1 vg0

угадай с одного раза, что будет при разрушении любого из md?

Да, я думаю всё будет очевидно. И придётся эту гирлянду из веников целиком постоянно таскать, и не запутаться в них при этом. :) В общем не буду я так мутиться. Как уже подсказали есть очевидно надёжней решение.

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

консистентность backup данных в rdiff-backup репозитарии.

это как?

Ну это примерно так: когда понадобится вытащить бекап за прошлое время, чтобы была какая-то уверенность, что raid тут собран не просто так, а с тем расчётом, что бед блок на диске, или ещё небольшое «чудо» не поколотило мне данные в репозитарии....

Чёрт - никогда не забуду как пришли бухи и с ножом у горла затребовали чтоб данные им 1С поднял я за пол года взад... - Итить машину времени нашли... - Таки поднял, но по чистой случайности откопав выгрузку древнюю... :) Я так понимаю что с rdiff-backup мне это будет сделать ещё проще, т.к. места они занимать будут совсем немного. Также через rdiff-backup планирую сливать ценные данные с рабочих станций пользователей (никто не запретит мне с backup сервера маунтить по smb особо важные ресурсы с пользовательской машиной и сливать их), и с файлопомоек. - А то иной раз пропадают нужные отчёты, и мне мозг выносят из-за горстки xls файлов...

P.S. bacula не хочу. Т.к. офисов несколько, не хочу с ней ковыряться - обновлять, разбираться в этих сторадж демонах проксях и всё прочее. - Мне надо чтоб было хорошо, но от добра добра искать не хочу.

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

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

правильно, но для надежности и не только и придумали SAN

правильно, но для надежности и не только и придумали SAN

но у нас нет SAN, а есть то что есть. в общем, я остаюсь при своём, но это выбор автора, может ему без lvm проще (потому что это действительно проще при востановлении).

в случае ТС я не рекомендовал бы совать разные raid в один vg. тем более для backup.

хоть mdadm крут до безобразия, принципы важнее.

вот здесь я выложил сырые данные своих тестов для раид5. http://andreykl.blogspot.ru/2012/11/blog-post_9.html

идея такая, сначала идёт команда создания массива и битмапа для ней.

первый битмап по дефалту mdadm --grow --bitmap=internal /dev/md2 далее cat /proc/mdstat , который даёт описание массива и далее три теста dd.

видно, что скорость довольно сильно меняется в зависимости от битмапчанк сайза.

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

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

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

вообще говоря, любопытно. при 16Мб вообще почти нет просадки в скорости. а при 1Гб - большая просадка... довольно странно, ибо при 1Гб по идее должно быть меньше чанков.. загадка, блин. но факт, ещё при тестах удивился..

Делали мы и таким образом, но... Бяка вылазит ИНОГДА (раз в пол-года, год) такая: при каких-либо глюках с сетью, или samba, или чего ещё: бывает что файл который хотели сохранить на сетевой диск - крешится... При том крешится так, что ни в темпах потом, ни на файлопомойке не достать. - Было пару раз, что гл. бух делала фин отчётность в exel - а я могу сказать, что с нашим гл. бухом даже Господь побоится связываться во страшном сне... - В общем то, что было после того как её полуденная работа крашнулась даже не передать всеми эмоциями мира... Вплоть до генеральных директоров всё дошло :) В общем лишняя прослойка в виде сети, или чего-то подобного реально может навредить.

Посмотрю это дело, интересно выглядит.

Согласен конечно... Но пока и оперативного backup толкового нету, надо наладить... Сегодня вот к примеру полетел очень странной смертИю БП на сервере виртуализации. А бэкапов то толковых нету... - Ох что пришлось пережить когда понимаешь, что есть БД не бекапленая с двумя фирмами сотрудников... - До сей поры пью валерьяну. Хорошо, что не упало ничего в итоге и БП удалось заменить без последствий...

Очень большая скорость, это я так понимаю Мегабайт в сек? Это что за диски такие? Я думаю что: чанки нужно высчитывать, и на просчёт больших чанков тратится больше процессорного времени, и следовательно скорость чуть ниже.

Если я правильно понял как bitmap работает.

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

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