Комментарии 34
Очень, очень круто, автор молодец. Думаю, специализированная контора вроде OnTrack за такую работу, обратись к ней какой банк, взяла бы несколько десятков килобаксов.
UPS'ы поставили после такого инцидента со «скачком электричества»?
Думаю автор понимает прелести RAID6. От такого должно было помочь.
Дополнительно можно организовать независимое питание пар дисков с упсами.
Дополнительно можно организовать независимое питание пар дисков с упсами.
RAID is not a backup.
а что вы имели ввиду под сообщением «RAID is not a backup.»
Raid это не бекап.
или Raid нельзя бекапить?
просто я в этом не очень разбираюсь. как я понимаю backup и raid созданы для разных целей. а вот про то что raid нельзя бекапить первый раз слышу.
Raid это не бекап.
или Raid нельзя бекапить?
просто я в этом не очень разбираюсь. как я понимаю backup и raid созданы для разных целей. а вот про то что raid нельзя бекапить первый раз слышу.
НЛО прилетело и опубликовало эту надпись здесь
Эта фраза переводится как «RAID — это не бэкап».
RAID защищает только от одной напасти — аппаратной поломки жесткого диска. Он не защищает ото всех остальных напастей вроде повреждения файловой системы, да к тому же добавляет ряд собственных напастей.
Поэтому данные, хранящиеся в RAID-массиве, нужно обязательно бэкапить. Если бы у автора статьи имелся бэкап данных, ему не пришлось бы так мучиться с восстановлением данных, при этом рискуя потерять их окончательно. Он бы просто запустил новый массив и скопировал на него данные.
Зачем же тогда нужен RAID? Единственный смысл RAID — обеспечение бесперебойной работы. Если один из дисков массива отказывает, система продолжает работать. В некоторых режимах RAID так же имеется приятный бонус в виде некоторого повышения скорости.
Также есть два не-совсем-RAID режима. Я их так называю, потому что они не обеспечивают бесперебойности. RAID-0 используется для повышения скорости, а JBOD для наращивания объема.
Настройте автоматическое резервное копирование и еженедельно заглядывайте в содержимое бэкапов, убежаясь в том, что всё бэкапится своевременно и в полном объеме.
RAID защищает только от одной напасти — аппаратной поломки жесткого диска. Он не защищает ото всех остальных напастей вроде повреждения файловой системы, да к тому же добавляет ряд собственных напастей.
Поэтому данные, хранящиеся в RAID-массиве, нужно обязательно бэкапить. Если бы у автора статьи имелся бэкап данных, ему не пришлось бы так мучиться с восстановлением данных, при этом рискуя потерять их окончательно. Он бы просто запустил новый массив и скопировал на него данные.
Зачем же тогда нужен RAID? Единственный смысл RAID — обеспечение бесперебойной работы. Если один из дисков массива отказывает, система продолжает работать. В некоторых режимах RAID так же имеется приятный бонус в виде некоторого повышения скорости.
Также есть два не-совсем-RAID режима. Я их так называю, потому что они не обеспечивают бесперебойности. RAID-0 используется для повышения скорости, а JBOD для наращивания объема.
Настройте автоматическое резервное копирование и еженедельно заглядывайте в содержимое бэкапов, убежаясь в том, что всё бэкапится своевременно и в полном объеме.
Типичное заблуждение. Ваш вчерашний бэкап конечно лучше, чем ничего, но как быть с сотней-другой человеко-часов которые вложены в период между бэкапом и аварией?
Я не совсем понял, какое именно утверждение является, по вашему мнению, заблуждением?
Вы хотите сказать, что реанимировать массив целесообразнее, чем восстанавливать резервную копию?
Собственно, я и не утверждал обратного. Я только предположил, что автор не стал бы заниматься восстановлением с риском потерять всё, если бы у него был свежий бэкап.
Но давайте попробуем оценить. Время покупки и установки новых дисков не учитываем, т. к. оно одинаково и для реанимации массива, и для восстановления бэкапа. Сколько времени потребуется на анализ ситуации, копирование туда-сюда, восстановление, всяческие пляски с бубном? Я могу предположить, что автор уложился в один день. Но у менее опытного человека на это уйдет несколько дней, а то и неделя.
В случае же с бэкапом достаточно выкинуть старые диски, поставить новые, инициализировать новый массив с прежним конфигом и накатить бэкап.
При реанимации бэкапа будет потеряно на простое ГОРАЗДО больше человеко-часов.
Я уже не говорю про то, что для реанимации нужно новый массив запустить рядом со старым. В описанном случае это 14 дисков! Куда их пихать?
Так что единственная причина, ради которой я вижу смысл париться с восстановлением массива при наличии бэкапа — это отсутствие в бэкапе невосстанавливаемых данных, например, платежных операций или чего-то столь же чувствительного.
Но для таких данных не используют, блеать, RAID-5! В худшем случае, RAID-1. В лучшем, дублирование всего сервера, кластеризацию, и т. п.
Уже из описанной в статье конфигурации (программный RAID, каждый диск обслуживает по два массива) понятно, что речь о какой-то кустарной системе, типа домашней файлопомойки. Использовать такое в бизнесе, где за неполный день расходуется «сотня-другая человеко-часов», — это нищебродство какое-то.
В бизнесе реанимация массива — это самая внештатная ситуация. Система должна быть настроена таким образом, чтобы в реанимации не было нужды ни при какой аварии.
PS Все сказанное — скромное личное мнение. Плюсанул вам в карму.
Вы хотите сказать, что реанимировать массив целесообразнее, чем восстанавливать резервную копию?
Собственно, я и не утверждал обратного. Я только предположил, что автор не стал бы заниматься восстановлением с риском потерять всё, если бы у него был свежий бэкап.
Но давайте попробуем оценить. Время покупки и установки новых дисков не учитываем, т. к. оно одинаково и для реанимации массива, и для восстановления бэкапа. Сколько времени потребуется на анализ ситуации, копирование туда-сюда, восстановление, всяческие пляски с бубном? Я могу предположить, что автор уложился в один день. Но у менее опытного человека на это уйдет несколько дней, а то и неделя.
В случае же с бэкапом достаточно выкинуть старые диски, поставить новые, инициализировать новый массив с прежним конфигом и накатить бэкап.
При реанимации бэкапа будет потеряно на простое ГОРАЗДО больше человеко-часов.
Я уже не говорю про то, что для реанимации нужно новый массив запустить рядом со старым. В описанном случае это 14 дисков! Куда их пихать?
Так что единственная причина, ради которой я вижу смысл париться с восстановлением массива при наличии бэкапа — это отсутствие в бэкапе невосстанавливаемых данных, например, платежных операций или чего-то столь же чувствительного.
Но для таких данных не используют, блеать, RAID-5! В худшем случае, RAID-1. В лучшем, дублирование всего сервера, кластеризацию, и т. п.
Уже из описанной в статье конфигурации (программный RAID, каждый диск обслуживает по два массива) понятно, что речь о какой-то кустарной системе, типа домашней файлопомойки. Использовать такое в бизнесе, где за неполный день расходуется «сотня-другая человеко-часов», — это нищебродство какое-то.
В бизнесе реанимация массива — это самая внештатная ситуация. Система должна быть настроена таким образом, чтобы в реанимации не было нужды ни при какой аварии.
PS Все сказанное — скромное личное мнение. Плюсанул вам в карму.
Вот, у меня вопрос. Каждый раз одно и то же. А нельзя как-то собрать каким-нибудь цивилизованным способом всю необходимую для восстановления информация сразу после создания RAID? И на компакт диск записать.
В свое время с похожей проблемой без особых проблем восстанавливал с помошью Raid Reconstructor
А утилиты типа капитана немо, в этом случае разве не могут помочь?
всегда удивляли люди, которые используют raid5/6
ну что ж — ни пуха, ни пера вам!
ну что ж — ни пуха, ни пера вам!
За статью спасибо, несколько лет ждал когда же мой raid5 упадет, пережил три выключения электричества у хостера.
Но слава богу рейд так и не успел развалиться.
Вот по этому сейчас у меня raid 10(4 диска) и glusterFS еще на три сервера( но это две соседние две стойки)
Итого получаем raid 1+1+1+0.
И бэкап(inotify, раз в день) на географически удаленных хост.
Но слава богу рейд так и не успел развалиться.
Вот по этому сейчас у меня raid 10(4 диска) и glusterFS еще на три сервера( но это две соседние две стойки)
Итого получаем raid 1+1+1+0.
И бэкап(inotify, раз в день) на географически удаленных хост.
Немножко не в тему, у вас с гластером нет проблем зависания при множественных паралелльных записях?
У нас при больших нагрузках скрипты виснут, что только рестарт гластер-демона помогает, на что я им баг-репорт с полными дебаг-логами отправил, а они мне еще и звонили по этому поводу пару раз.
У нас при больших нагрузках скрипты виснут, что только рестарт гластер-демона помогает, на что я им баг-репорт с полными дебаг-логами отправил, а они мне еще и звонили по этому поводу пару раз.
У нас гластер вообще систему убивал.
загрузка проца\сети — 0. la > 150 :)
решилось обновлением версии.
А записи у вас конкурирующие или как?
Вы там не забыли локи прописать и всякое такое?
Мне вот чем GFS не нравиться — так это своей жуткой конфигурабельностью.
загрузка проца\сети — 0. la > 150 :)
решилось обновлением версии.
А записи у вас конкурирующие или как?
Вы там не забыли локи прописать и всякое такое?
Мне вот чем GFS не нравиться — так это своей жуткой конфигурабельностью.
Ну нагрузка тоже была, тоже ок после последнего апдейта + скорость записи на реплику возвросла с 10-12 до 60мб/с, но все до того момента, как параллельные записи не начинаются в большом количестве, после этого гластер даже сам иногда падал, правда и восстанавливался сам :)
в конфиге прописал максимальное performance.io-thread-count: 64
но не думаю, что это значение достигаю
Насчет локов не понял, куда прописать и как?
в конфиге прописал максимальное performance.io-thread-count: 64
но не думаю, что это значение достигаю
Насчет локов не понял, куда прописать и как?
Автор, респект. Если интересно поработать в восстановлении данных, присылайте резюме на agalitski@datarc.ru.
Товарищи, те кто думает, что RAID10 надежнее RAID6, то они ну очень глубоко заблуждаются. У меня где-то >600 дисков в сторождах и уже были случаи выхода из строя двух дисков одновременно в одном сторадже в одной рейд группе и это при том, что ни перебоев питания ничего не было (вообщем в серверной все тип топ). Так вот… когда это случилось я привел скептиков (убеждавших меня сделать RAID5) и ткнул носом в этот предотвращенный факап. Многоуважаемый romx очень все правильно написал в своём блоге, почитайте его реально на многое по-другому посмотрите (я жалею, что у меня не было этого блога когда я начинал :) )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Экстремальное восстановление данных с деградировавшего 5го рейда