Comments 49
А причину сбоя выяснить не удалось? Интересно, почему это случилось (может с вами заказчик поделился какими-то итогами своего расследования)?
PS Ваши статьи читаются, как детектив. Спасибо!
PS Ваши статьи читаются, как детектив. Спасибо!
Все расследование заказчика закончилось на уровне формулировки «Сбой оборудования». Перед нами не стояла задача проводить комплекс исследований и пытаться создать условия при которых бы повторился сбой. Посему, кроме ответа на вопрос «Как восстановить данные?» я ничего больше не смогу сказать по данному случаю.
Спасибо огромное за данную статью! Вы ответили на вопрос, который я задавала в комментарии к прошлой Вашей статье!
Пожалуйста. Буду рад, если вы найдете в ней для себя что-то, что поможет вам решить проблему.
Обращаю внимание, всех читателей, что в комментариях вы можете оставлять свои пожелания, на предмет тем будущих статей. По мере возможностей будут рассматриваться интересующие вас случаи восстановления данных.
Обращаю внимание, всех читателей, что в комментариях вы можете оставлять свои пожелания, на предмет тем будущих статей. По мере возможностей будут рассматриваться интересующие вас случаи восстановления данных.
Спасибо за статью
А можете рассказать по шагам как у вас происходит взаимодействие с заказчиком? Можно взять для примера мою недавнюю ситуацию — сгорел RAID-контроллер и остались пять дисков, которые жили на этом контроллере, объединённые в RAID-5. Встал вопрос, что можно спасти. Все организации, которые я нашел, предлагали одно и то же — присылайте диски с курьером, мы посмотрим, что можно сделать, и объявим цену. На этом этапе настораживало уже то, что в RAID-5 важен порядок дисков, а им никто не интересовался. Да и название контроллера не помешало бы узнать, а об этом тоже никто не спрашивал. Допустим, всё удалось восстановить. Что дальше? Вы пересобираете RAID и отдаёте информацию обратно на тех же дисках (если они исправны)?
А можете рассказать по шагам как у вас происходит взаимодействие с заказчиком? Можно взять для примера мою недавнюю ситуацию — сгорел RAID-контроллер и остались пять дисков, которые жили на этом контроллере, объединённые в RAID-5. Встал вопрос, что можно спасти. Все организации, которые я нашел, предлагали одно и то же — присылайте диски с курьером, мы посмотрим, что можно сделать, и объявим цену. На этом этапе настораживало уже то, что в RAID-5 важен порядок дисков, а им никто не интересовался. Да и название контроллера не помешало бы узнать, а об этом тоже никто не спрашивал. Допустим, всё удалось восстановить. Что дальше? Вы пересобираете RAID и отдаёте информацию обратно на тех же дисках (если они исправны)?
Взаимодействие с клиентом происходит следующим образом:
Предоставляются накопители для анализа. Порядок дисков необязателен, так как все равно посредством аналитических мероприятий предстоит его установить как и все параметры массива. Но при выборе компании будьте осторожны, не попадите в руки универсальных сервисов, которые кроме автопилота в программах автоматического восстановления больше ничего не знают.
После анализа озвучивается стоимость работ. Если клиента все устроит, тогда переходим к выполнению.
Нами создаются посекторные копии дисков клиентов. Сбор массива ведется на отдельный накопитель (или массив). После этого из собранного массива можно скопировать данные пользователя. Записать данные можно на любой накопитель достаточной емкости предоставленный со стороны заказчика. Оригинальные накопители мы оставляем без изменений. Если конечно клиент желает, чтобы на них информация была записана как на разрозненные диски, то можно поступить и таким образом. (страховочные посекторные копии некоторое время хранятся у нас. Срок хрения обсуждается с заказчиком).
Предоставляются накопители для анализа. Порядок дисков необязателен, так как все равно посредством аналитических мероприятий предстоит его установить как и все параметры массива. Но при выборе компании будьте осторожны, не попадите в руки универсальных сервисов, которые кроме автопилота в программах автоматического восстановления больше ничего не знают.
После анализа озвучивается стоимость работ. Если клиента все устроит, тогда переходим к выполнению.
Нами создаются посекторные копии дисков клиентов. Сбор массива ведется на отдельный накопитель (или массив). После этого из собранного массива можно скопировать данные пользователя. Записать данные можно на любой накопитель достаточной емкости предоставленный со стороны заказчика. Оригинальные накопители мы оставляем без изменений. Если конечно клиент желает, чтобы на них информация была записана как на разрозненные диски, то можно поступить и таким образом. (страховочные посекторные копии некоторое время хранятся у нас. Срок хрения обсуждается с заказчиком).
сгорел RAID-контроллер
В статье описан «сложный случай». Сложность обусловлена тем, что таблица LVM была утеряна. Проблему со сгоревшим контроллером можно попробовать сначала решить при помощи программ умеющих автоматически реконструировать RAID. Таких программ очень много, и шансы, что они сработают в данном случае, — высоки. Если нет — всегда можно обратиться к специалистам.
П.С. Обязательно сделайте образы дисков.
Проблему со сгоревшим контроллером можно попробовать сначала решить при помощи программ умеющих автоматически реконструировать RAID. Таких программ очень много, и шансы, что они сработают в данном случае, — высоки.
Могут сработать, при условиях:
1. Массив начинался с LBA 0, либо вы точно зададите смещения с которого начинать сбор (многие контроллеры в начале диска могут размещать свои метаданные).
2. RAID контроллер не создавал буферных зон в середине LBA диапазона каждого из дисков.
3. На дисках был организован один массив.
Со всяким автоматическим ПО остро встанет вопрос определения диска с неактуальными данными, который необходимо исключить при сборе и недостающие данные компенсировать за счет избыточных.
Как показывает практика в RAID 5, 5E, 5EE, 6, 50, 60 и прочих чуть сложнее страйпа (RAID 0) с автоматическим ПО получить качественный результат несколько проблематично.
П.С. Обязательно сделайте образы дисков.
Также свою лепту вносит неумение многими пользователями и системными администраторами адекватно оценивать состояние жестких дисков, которые при попытках создания посекторной копии (посредством линейного чтения) усугубляют его состояние вплоть до невозможности извлечения данных.
Современные накопители с проблемами, как правило, требуют вмешательства в работу микропрограммы (например отключение оффлайн сканирования, отключение SMART, запрет процедур автореаллокации). Также требуется локализация крупных дефектообразование по каждой поверхности с последующей вычиткой стабильных зон и лишь в последнюю очередь читать проблемные зоны, так как при их вычитке высоки риски деградации как поверхностей так и БМГ.
1. Массив начинался с LBA 0, либо вы точно зададите смещения с которого начинать сбор (многие контроллеры в начале диска могут размещать свои метаданные).
Это не проблема. Программы умеют искать смещения «регулярками». Но, это работает только если искомая область не повреждена. Если повреждена, — это как раз «сложный случай»
2. RAID контроллер не создавал буферных зон в середине LBA диапазона каждого из дисков.
Это, и, включенный кэш на запись — показания сразу нести диски к специалистам. Но, скорее всего, контроллер используемый «в домашних условиях» этого делать не будет. Если условия не «домашние», то лучше сразу к специалистам идти.
3. На дисках был организован один массив.
Даже если массивов несколько — это может сработать. Программы часто умеют читать стандартные способы разбивки MatrixRaid/MD/LVM и т.п., как и большинство комбинаций. Но, метаданные должны быть на месте.
Со всяким автоматическим ПО остро встанет вопрос определения диска с неактуальными данными, который необходимо исключить при сборе и недостающие данные компенсировать за счет избыточных.
Это верно. Но, при сгоревшем контроллере скорее всего сильного расхождения не будет. А если случай немного другой, даже тогда, иногда, можно решить автоматически. В худшем случае, можно по-очереди исключать при сборке разных участников и проверять содержимое. AKA метод грубой силы. Острым становится вопрос если ни в одной комбинации у не получается восстановить данные. Такое тоже бывает, но реже.
Также свою лепту вносит неумение многими пользователями и системными администраторами адекватно оценивать состояние жестких дисков, которые при попытках создания посекторной копии (посредством линейного чтения) усугубляют его состояние вплоть до невозможности извлечения данных.
В случае сгоревшего контроллера, — скорее всего диски живы. Есть много статей о том как осторожно снимать посекторнее образы с дисков, и, часто, программы для восстановления умеют делать это самостоятельно. Если диск проявил малейшие признаки неисправности — не надо диск насиловать. Это как раз случай где упорство вредно. Возможно, этот диск не понадобится для сборки массива. Лучше сосредоточиться на живых. Если живых дисков недостаточно — это задача для специалистов.
Любое действие предпринимаемое самостоятельно это риск. Но, иногда, этот риск оправдан. Иногда, обратиться к специалистам это тоже риск, особенно, когда специалисты далеко, а, единственный способ доставки дисков — почта. Или, как было сказано, специалисты не проверены. Транспортировать неисправные диски, в конце концов, — тоже вредно.
Раз уж тут в комментариях зашла речь о ПО, то для восстановления своего массива при сгоревшем контроллере использовал:
UFS Explorer
UFS Explorer
Это не проблема. Программы умеют искать смещения «регулярками». Но, это работает только если искомая область не повреждена. Если повреждена, — это как раз «сложный случай»
Из моего личного теста в 2014 году, автоматического ПО могу сказать, что самостоятельно определить размер метаданных RAID контроллера в начале LBA диапазона и найти область с которой начинался единственный массив затруднилось все тестируемое ПО.
Даже если массивов несколько — это может сработать. Программы часто умеют читать стандартные способы разбивки MatrixRaid/MD/LVM и т.п., как и большинство комбинаций. Но, метаданные должны быть на месте.
в 2014 году в авторекаверилках с разбором LVM была мрачная картина (полное отсутствие разбора). В лучшем случае был разбор LDM для «динамичесикх дисков» в Windows.
Есть много статей о том как осторожно снимать посекторнее образы с дисков, и, часто, программы для восстановления умеют делать это самостоятельно. Если диск проявил малейшие признаки неисправности — не надо диск насиловать.
программы автоматического восстановления в настраиваются в лучшем случае на прыжок в случае дефекта, без каких-либо возможностей вычитки участка после создания основного образа. Если ставить большие прыжки, то на проблемном месте будет много недочитанных мест, если ставить маленький, то будет попытка убийства диска с дефектами. Никакого контроля времени операции чтения, никакого контроля состояния диска и того, что он отдает.
Транспортировать неисправные диски, в конце концов, — тоже вредно.
в принципе не более вредно, чем и исправные. При правильной упаковке и использовании служб курьерской доставки не так все страшно.
Любое действие предпринимаемое самостоятельно это риск. Но, иногда, этот риск оправдан.
Вопрос лишь в ценности данных. Когда пользователь играется с собственным массивом, где он 100% владелец информации и готов с нею расстаться в случае неудачи, то это конечно его дело. Но в случае, когда системный администратор не обладая должной квалификацией начинает экспериментировать с дисками из RAID массива компании, где находится результат труда многих людей, то тут пора вовремя остановиться во избежание наступления необратимых последствий.
И во сколько это, если не секрет, обошлось заказчик?
В договоре с клиентом прописано, что информация заказчика, включая информацию о заключенном с ним договоре, не передается третьим лицам. Конкретная стоимость услуг является элементом договора.
Если Вы хотите обратиться за услугой, то в нашей лаборатории бесплатная диагностика, на основании которой оцениваются трудозатраты, согласно технического задания, и формируется стоимость услуги. Учитывая различную сложность задач и нюансы технических заданий стоимость может варьироваться в очень широком диапазоне. Кроме этого на стоимость влияет время выполнения. Будет это дневное время будних дней или круглосуточный режим в выходные дни.
Если Вы хотите обратиться за услугой, то в нашей лаборатории бесплатная диагностика, на основании которой оцениваются трудозатраты, согласно технического задания, и формируется стоимость услуги. Учитывая различную сложность задач и нюансы технических заданий стоимость может варьироваться в очень широком диапазоне. Кроме этого на стоимость влияет время выполнения. Будет это дневное время будних дней или круглосуточный режим в выходные дни.
del
Бэкапы? Зачем, ведь есть же RAID!
Когда же подобные одмины закончатся…
Когда же подобные одмины закончатся…
Да ещё и RAID-5.
Почему RAID-5 — «mustdie»?
Почему RAID-5 — «mustdie»?
В интернете легко можно найти истории, когда сравнительно небольшой 4-6 дисковый RAID-5 из 500GB дисков восстанавливал данные на новый диск в течении суток, и более.
С использованием же терабайтных и двухтерабайтных дисков приведенные цифры можно смело умножать в 2-4 раза!
И вот тут начинаются страсти.
Дело в том, и это надо себе трезво уяснить, что на время ребилда RAID-5 вы остаетесь не просто с RAID лишенным отказоустойчивости. Вы получаете на все время ребилда RAID-0.
Использую RAID-Z (аналог RAID-5) на трех 2TB дисках в домашних условиях.
Полный ребилд массива занимает порядка 20 часов.
Бекапы конечно делаются.
Если RAID 5 в руках системного администратора, который обладает базовыми знаниями согласно организации хранения данных в массиве, то особо бояться будет нечего. Потому как банально у него будут резервные копии всего нужного. Перед ребилдом он сделает еще одну копию важных данных.
RAID 10, так же при отказе в зоне риска, что если возникнут затруднения чтения на единственной копии диска, оставшейся в массиве, то точно также случится остановка массива.
Более явное преимущество имеет RAID 6.
RAID 10, так же при отказе в зоне риска, что если возникнут затруднения чтения на единственной копии диска, оставшейся в массиве, то точно также случится остановка массива.
Более явное преимущество имеет RAID 6.
А еще в интернете когда задаешь вопросы касательно рейда то народ сразу теряется или говорит что все по дефолту:
— Журнал рейда на самом рейде
— Размер страйпа наугад выбран
— Размер и смещение блоков ФС тоже какие то странные
итд итп
— Журнал рейда на самом рейде
— Размер страйпа наугад выбран
— Размер и смещение блоков ФС тоже какие то странные
итд итп
Резервные копии баз были, но двухнедельной давности. Но как оказалось ценность имели не только базы, но и полностью сконфигурированные виртуальные машины. В связи с чем заказчик предпочел не начинать с чистого листа, а получить актуальные копии баз и рабочие виртуальные машины.
Бэкапы? Нет, не слышал… Так бы в худшем случае потерял небольшой промежуток данных — не более того. Но ведь да, есть RAID, он же надёжный…
Кстати, RAID 5 в продакшн? Серьёзно? Ни за что.
Кстати, RAID 5 в продакшн? Серьёзно? Ни за что.
Бэкапы? Нет, не слышал… Так бы в худшем случае потерял небольшой промежуток данных — не более того. Но ведь да, есть RAID, он же надёжный…
в комментариях сказано про наличие бэкапов.
Кстати, RAID 5 в продакшн? Серьёзно? Ни за что.
Вы так говорите, будто бы Вас тут намерено заставляют использовать RAID 5.
RAID 5 хорош, когда использован к месту. Не для всех задач он подходит. Всего-лишь стоит обозначить, где его можно применить, где нет без категоричных заявлений.
Бекапы конечно всегда обязательны, но после знакомства с ZFS я ни ногой в другие ФС, а про raid5 вообще и говорить не стоит.
а про raid5 вообще и говорить не стоит.
Поговорить можно, если без эмоций оценивать его недостатки и достоинства.
но после знакомства с ZFS я ни ногой в другие ФС
После случая «падения» данной файловой системы вы несколько измените свое мнение (поверьте, она тоже падает по тем же причинам, что и другие файловые системы). Тем более большинство преимуществ данной файловой системы весьма не очевидны, например для домашних пользователей и малых офисов.
Поговорить можно, если без эмоций оценивать его недостатки и достоинства.
Извиняюсь за излишнюю эмоциональность, но это не отменяет явных недостатков raid5 на дисках большого объёма хотя бы из-за BER. Да, он работает, но при сбое вероятность потерь меня очень смущает.
После случая «падения» данной файловой системы
Я не утверждал, что она не падает, к сожалению всё может в какой-то момент дать сбой. Наоборот, как раз сторонники ZFS наиболее яро пропагандируют эту идею, в частности только они явно выделяют рекомендации по ECC памяти.
преимуществ данной файловой системы весьма не очевидны, например для домашних пользователей и малых офисов.
Не хочу спорить, лично для меня это вопрос из разряда «мыши плакали, кололись, но продолжали есть кактус». Я понимаю, что у каждой ФС свои плюсы.
Кстати, у вас уже был опыт восстановления ZFS?
Также очень интересно было бы узнать ваши предпочтения по ФС.
Извиняюсь за излишнюю эмоциональность, но это не отменяет явных недостатков raid5 на дисках большого объёма хотя бы из-за BER. Да, он работает, но при сбое вероятность потерь меня очень смущает.
Если рассмотреть типичные условия: диски куплены в одно время и на них создан массив. Условия эксплуатации одинаковые, как по времени, так и по нагрузке. Если были какие-то внешние воздействия, то они касались всех дисков в этом массиве. Исключение первого диска из массива обычно намекает, что с ним есть проблемы. В такой ситуации кроме стандартного бекапного плана стоит переместить актуальные данные на другой сервер/массив (максимально безболезненно для пользователей), а уж потом заниматься реанимацией массива в надежде, что из одинаково «уставших» дисков вылет одного чистая случайность. Обращая внимание на вероятности возникновения ошибок в HDD стоит разве что в дорогих системах, где в первую очередь продумана система бесперебойного питания начиная с батарей, заканчивая несколькими блоками питания, где используется ОЗУ с ЕСС, где должным образом экранированы корпуса, где продумана система охлаждения, как в самом устройстве, так и в помещении, где оно находится и многие другие факторы.
сторонники ZFS наиболее яро пропагандируют эту идею, в частности только они явно выделяют рекомендации по ECC памяти.
но кроме ОЗУ с ЕСС надо учитывать и остальные компоненты, как написано выше.
Говоря о дорогой серверной системе, где все учтено, что написано выше, я бы согласился, что в качестве элемента дополнительной надежности можно рассмотреть ZFS и местами даже нужно. В случае же NAS для дома и малых офисов дополнительная надежность ZFS звучит как издёвка.
Не хочу спорить, лично для меня это вопрос из разряда «мыши плакали, кололись, но продолжали есть кактус». Я понимаю, что у каждой ФС свои плюсы.
Именно у каждой свои плюсы. Во многих случаях ZFS тот же кактус.
Кстати, у вас уже был опыт восстановления ZFS?
был.
Также очень интересно было бы узнать ваши предпочтения по ФС
«родные» файловые системы для ОС в которой они используются. пример: MS Windows — NTFS
В случае же NAS для дома и малых офисов дополнительная надежность ZFS звучит как издёвка.
Именно в этом случае и не соглашусь, ZFS создавалась с упором на ненадёжность носителей, что прямо относится к недорогим HDD, взять хотя бы подсчёт контрольных сумм всех данных. В отличии от него, другие ФС отдадут то, что выдал HDD, без проверки.
И уж если мы заговорили о надёжности железа, то оно от ФС не зависит.
«родные» файловые системы для ОС в которой они используются. пример: MS Windows — NTFS
Извиняюсь, что не уточнил — в Linux, для Windows вариантов особо и нет :) Для Linux понятия родной ФС в вашем случае можно заменить на наиболее используемую, видимо это ext4.
Также интересно узнать, есть ли у вас какое-то мнение по поводу надёжности файловых систем, что лучше или хуже?
Именно в этом случае и не соглашусь, ZFS создавалась с упором на ненадёжность носителей, что прямо относится к недорогим HDD, взять хотя бы подсчёт контрольных сумм всех данных. В отличии от него, другие ФС отдадут то, что выдал HDD, без проверки.
В случае отказа HDD, например проблемы с буферным ОЗУ на его плате, в накопитель запишутся как и битые данные, так и битые контрольные суммы для этих данных. Т.е. совершенно не спасет. Кроме этого при проблемах в иных компонентах ПК в накопитель будут записаны битые данные или недописаны.
В исправном накопителе, есть процедуры контроля целостности данных при поступлении информации по интерфейсу. Контроль целостности в ОЗУ, есть биты четности, при записи на пластину и чтении хороший контроль в виде БЧХ кодов (ЕСС). Да и результаты нагрузочного тестирования на новых недорогих винтах показывают, что случайно искажение данных по вине накопителя — это то, чего нужно опасаться меньше всего (если рассматривать систему в комплексе).
Нагрузочное тестирование велось следующим образом: Несколько накопителей 500Гб. Запись случайно сформированным паттерном, потом чтение (в рамках всего LBA диапазона) для проверки записанного. 3 часа один цикл. за сутки 8 циклов то есть 4Тб данных. за месяц 30 дней 120Тб. Продолжать эксперимент получилось примерно до одного Петабайта. (дальше последовало длительное отключение электроэнергии и возможностей ИБП не хватило и тест был прерван). Отловить хоть одну ошибку не удалось. Более полугода такого тестирования — это многие годы работы в условиях малого офиса или дома.
И уж если мы заговорили о надёжности железа, то оно от ФС не зависит.
говоря о сохранности данных и анализируя случаи их повреждения, мы лишь констатируем, что наличие ZFS практически бесполезно при других ненадежных элементах системы. Но вот в случае аварии и повреждения ZFS для домашнего пользователя или малого офиса процедура восстановления данных будет существенно усложнена. Стоит ли закладывать себе «мину» в виде ZFS, зная что другие компоненты системы в плане надежности оставляют желать лучшего?
Также интересно узнать, есть ли у вас какое-то мнение по поводу надёжности файловых систем, что лучше или хуже?
Если говорить о различных случаях повреждений файловых систем и возможностей восстановления данных и рассматривать например Ext (2,3,4), XFS, VMFS, ExFAT, FAT32, NTFS, HFS+
то самой живучей по итогу окажется NTFS. Место аутсайдера займет ExFAT c VMFS
Сразу уточню, что я говорю только о Linux и Unix мире, т.к. ваша статья была о нём, и в контексте надёжности.
И это естественно. Контрольная сумма (даже неверная) сработает при чтении, что спасёт от использования искажённых данных, а также спасёт от дальнейших потерь.То есть ZFS гарантирует в первую очередь проверку на корректность, такие данные в любом случае потеряны, если нет резервирования (а при использовании любого резервирования ZFS просто восстановит такой блок на проблемный носитель, хотя это является первым признаком возможного сбоя носителя в будущем).
Но этот фактор нельзя просто отбрасывать, если данные всё-таки нам дороги (всё же производители не просто так предоставляют информацию о BER). Тут скорее идёт речь о балансе надёжности к стоимости/производительности.
Только ZFS отреагирует на проблемы с оборудованием (речь про искажение информации), другие ФС будут работать уже с некорректными данными, т.к. контрольные суммы они не считают.
Можете уточнить точный сценарий, при котором ZFS сложнее восстановить?
Предполагая, что значительная часть данных с диска сохранена, и резервирование не используется — ZFS перетягивается тем же dd на другой диск, проводится штатный scrub, который выявляет все проблемы с данными, а неповреждённые блоки будут и дальше прекрасно работать (а метаданные всегда дублируются в нескольких частях диска).
Также в контексте использования на десктопах у ZFS есть возможность дублировать все блоки несколько раз (параметр copies).
Невозможность примонтирования (т.е. полный крах ФС) в счёт не беру, т.к. в этом случае проблемы будут одинаковы для всех ФС. Но и в этом случае ZFS на шаг впереди за счёт CoW (copy on write) — фактически он позволяет откатиться до последней корректной транзакции на диск.
Естественно, что рядовой пользователь не знает, как восстановить данные с любой ФС. Я не предлагаю на каждый ноутбук с Windows прямо сейчас городить ZFS (жаль, что сейчас это и невозможно), но это не значит, что самый распространённый вариант = самый верный.
Шествие ZFS в мире Unix идёт семимильными шагами, он уже используется в *BSD, Solaris, а в Linux будет штатным через 1-2 года, т.к. наконец решены вопросы с лицензией, Debian уже включил его в штатный репозиторий Stretch. Я считаю, что есть множество случаев, когда его использование оправдано.
В случае отказа HDD, например проблемы с буферным ОЗУ на его плате, в накопитель запишутся как и битые данные, так и битые контрольные суммы для этих данных. Т.е. совершенно не спасет.
И это естественно. Контрольная сумма (даже неверная) сработает при чтении, что спасёт от использования искажённых данных, а также спасёт от дальнейших потерь.То есть ZFS гарантирует в первую очередь проверку на корректность, такие данные в любом случае потеряны, если нет резервирования (а при использовании любого резервирования ZFS просто восстановит такой блок на проблемный носитель, хотя это является первым признаком возможного сбоя носителя в будущем).
случайно искажение данных по вине накопителя — это то, чего нужно опасаться меньше всего (если рассматривать систему в комплексе).
Но этот фактор нельзя просто отбрасывать, если данные всё-таки нам дороги (всё же производители не просто так предоставляют информацию о BER). Тут скорее идёт речь о балансе надёжности к стоимости/производительности.
наличие ZFS практически бесполезно при других ненадежных элементах системы
Только ZFS отреагирует на проблемы с оборудованием (речь про искажение информации), другие ФС будут работать уже с некорректными данными, т.к. контрольные суммы они не считают.
в случае аварии и повреждения ZFS для домашнего пользователя или малого офиса процедура восстановления данных будет существенно усложнена
Можете уточнить точный сценарий, при котором ZFS сложнее восстановить?
Предполагая, что значительная часть данных с диска сохранена, и резервирование не используется — ZFS перетягивается тем же dd на другой диск, проводится штатный scrub, который выявляет все проблемы с данными, а неповреждённые блоки будут и дальше прекрасно работать (а метаданные всегда дублируются в нескольких частях диска).
Также в контексте использования на десктопах у ZFS есть возможность дублировать все блоки несколько раз (параметр copies).
Невозможность примонтирования (т.е. полный крах ФС) в счёт не беру, т.к. в этом случае проблемы будут одинаковы для всех ФС. Но и в этом случае ZFS на шаг впереди за счёт CoW (copy on write) — фактически он позволяет откатиться до последней корректной транзакции на диск.
Естественно, что рядовой пользователь не знает, как восстановить данные с любой ФС. Я не предлагаю на каждый ноутбук с Windows прямо сейчас городить ZFS (жаль, что сейчас это и невозможно), но это не значит, что самый распространённый вариант = самый верный.
Шествие ZFS в мире Unix идёт семимильными шагами, он уже используется в *BSD, Solaris, а в Linux будет штатным через 1-2 года, т.к. наконец решены вопросы с лицензией, Debian уже включил его в штатный репозиторий Stretch. Я считаю, что есть множество случаев, когда его использование оправдано.
И это естественно. Контрольная сумма (даже неверная) сработает при чтении, что спасёт от использования искажённых данных, а также спасёт от дальнейших потерь.То есть ZFS гарантирует в первую очередь проверку на корректность, такие данные в любом случае потеряны, если нет резервирования (а при использовании любого резервирования ZFS просто восстановит такой блок на проблемный носитель, хотя это является первым признаком возможного сбоя носителя в будущем).
говоря о данных не забывайте, что речь может идти о повреждении самих структур ZFS и мало проку будет от самих проверок. Говоря о случайных ошибках накопителей прочтите комментарий ниже. К сожалению страховка от сбоев накопителей — это по большей части маркетинговый ход.
Но этот фактор нельзя просто отбрасывать, если данные всё-таки нам дороги (всё же производители не просто так предоставляют информацию о BER). Тут скорее идёт речь о балансе надёжности к стоимости/производительности
именно его пожалуй и стоит отбросить в силу того, что накопитель банально не выдаст вам данных, если возникла некорректируемая ошибка чтения (прочтите комментарий ниже).
Только ZFS отреагирует на проблемы с оборудованием (речь про искажение информации), другие ФС будут работать уже с некорректными данными, т.к. контрольные суммы они не считают.
при сбоях в работе ОЗУ рухнет все, в том числе и процедуры контроля, которые выполняются при R/W операциях и банально будет записан кусок мусора вместо структур и данных. Крах будет примерно одинаковым по последствиям на любой файловой системе. Из реальных плюсов ZFS можно отметить, что при ошибках в файловой системе и пересекающихся записей, проще будет установить, где еще остались целые данные.
Невозможность примонтирования (т.е. полный крах ФС) в счёт не беру, т.к. в этом случае проблемы будут одинаковы для всех ФС. Но и в этом случае ZFS на шаг впереди за счёт CoW (copy on write) — фактически он позволяет откатиться до последней корректной транзакции на диск.Несколько оптимистичный взгляд на разрушения. Вы скорее говорите о мелких проблемах, которые вызваны аварийным отключением питания. Здесь многие ФС перенесут это без какой-либо существенной потери данных.
Шествие ZFS в мире Unix идёт семимильными шагами, он уже используется в *BSD, Solaris, а в Linux будет штатным через 1-2 года, т.к. наконец решены вопросы с лицензией, Debian уже включил его в штатный репозиторий Stretch. Я считаю, что есть множество случаев, когда его использование оправдано.
продолжается, так как есть некоторые конкурентные преимущества. Но повторюсь в случае дома и малого офиса, они банально не раскроются.
Вашу позицию по поводу BER я всё-таки не разделяю (предпочитаю быть параноиком), пожелаю лишь нам всем удачи и в дальнейшём отсутствии такой проблемы.
Отключение питания вообще не страшно ZFS, она атомарна, недозаписанная информация будет потеряна, но она не приведёт к какой либо ошибке в структуре.
Говоря о ZFS, стоит в первую очередь понимать, какие отличия у CoW ФС от классических. В случае ZFS даже при успешной записи новых метаданных старые метаданные не затираются в течении нескольких транзакций ZFS, что технически даёт возможность откатиться на последнее стабильное состояние (вот пример, как можно поступить при повреждении структуры).
При всём этом носитель должен быть изрядно поврежден, т.к. метаданные дублируются на разных частях.
Вы скорее говорите о мелких проблемах, которые вызваны аварийным отключением питания.
Отключение питания вообще не страшно ZFS, она атомарна, недозаписанная информация будет потеряна, но она не приведёт к какой либо ошибке в структуре.
говоря о данных не забывайте, что речь может идти о повреждении самих структур ZFS и мало проку будет от самих проверок
Крах будет примерно одинаковым по последствиям на любой файловой системе.
Говоря о ZFS, стоит в первую очередь понимать, какие отличия у CoW ФС от классических. В случае ZFS даже при успешной записи новых метаданных старые метаданные не затираются в течении нескольких транзакций ZFS, что технически даёт возможность откатиться на последнее стабильное состояние (вот пример, как можно поступить при повреждении структуры).
При всём этом носитель должен быть изрядно поврежден, т.к. метаданные дублируются на разных частях.
Вашу позицию по поводу BER я всё-таки не разделяю (предпочитаю быть параноиком), пожелаю лишь нам всем удачи и в дальнейшём отсутствии такой проблемы.после ознакомления с АТА стандартом и анализе нескольких микропрограмм накопителей страхи отступят. Ну и экспериментально попробуйте подтвердить, что исправный накопитель при определенных условиях выдаст некорректные данные, а не будет поймана ошибка и взведен флаг ошибки.
Отключение питания вообще не страшно ZFS, она атомарна, недозаписанная информация будет потеряна, но она не приведёт к какой либо ошибке в структуре.это можно сказать почти о любой относительно современной файловой системе. Но процедуру проверки потребуют все.
Говоря о ZFS, стоит в первую очередь понимать, какие отличия у CoW ФС от классических. В случае ZFS даже при успешной записи новых метаданных старые метаданные не затираются в течении нескольких транзакций ZFS, что технически даёт возможность откатиться на последнее стабильное состояние
в идеальных условиях выглядит чуть ли не панацеей от все бед, но при реальных сбоя и отказах оборудования рушится чуточку поболее, чем хотелось бы. Беря пример в данной заметке — некоторые структуры, на разных дисках оказались уничтоженными на 100% (причем они вообще не должны были перезаписываться при штатной работе). Так и с ZFS при некоторых видах сбоев пострадать может не только самая последняя структура.
Ну и экспериментально попробуйте подтвердить, что исправный накопитель при определенных условиях выдаст некорректные данные
CERN и Amazon точно с вами не согласны, и это только верхушка айсберга.
У ЦЕРН в этом отчёте также есть статистика по RAID5, которая наглядно показывает, почему он ненадёжен. Приведу цитату:
1.Disk errors
…
2.RAID 5 verification
…
Running the verify command for the RAID controller on 492 systems over 4
weeks resulted in the fix of ~300 block problems. The disk vendors claims about
one unrecoverable bit error in 10^14 bits read/written. The 492 systems correspond
to about 1.5 PB of disk space.
…
The first thing to notice is that the verify command stresses the disks 3 times more than the actual physics applications, by just running it once per week.
The second observation is the that we measured about 300 errors while from the mentioned BER (Bit Error Rate) and the usage one would expect about 850 errors. As the vendor BER numbers are normally on the ‘safe’ side the measurement is close to the expectation.
3.Memory errors
…
4.CASTOR data pool checksum verification
All the previously mentioned error will of course result in the corruption of user data.
…
Честно, я очень хотел бы с вами согласиться.
Результаты данного тестирования вызывают больше вопросов, чем дают ответов. На основании собственных экспериментов и анализе протоколов передачи, могу подозревать, что в том тестирование под проблемы накопителей списано множество иных проблем.
Стоит еще отметить, что мире много стандартов принятых на основании чьих-то страхов. Причем совершенно необоснованных, но позволяющих освоить немалые средства. Например возьмем требование некоторых стандартов перед утилизацией диск многократно перезаписывать разными паттернами, во избежание возможности восстановить с него данные. Хотя достаточно одной перезаписи всего LBA диапазона, чтобы уничтожить данные безвозвратно. Эксперименты в области магнитно-силовой микроскопии это подтвердят.
Можете уточнить точный сценарий, при котором ZFS сложнее восстановить?
Есть целая куча сценариев, которую можно отнести к человеческому фактору. Сюда относятся всякие переформатирования, переинициализации, удаление файлов по ошибке и тому подобное.
Преимущество NTFS в таких сценариях в том, что она хорошо изучена и ее поддерживают все основные инструменты для восстановления данных (кто-то хуже, а кто-то лучше, но поддерживают), а у специалистов по восстановлению данных уже скопился большой опыт. А вот с ZFS все сейчас находится только в развитии.
Если проводить очень грубую аналогию с автомобилями, то NTFS — она как жигули, а ZFS — как тесла. Тесла вроде как должна быть надежней, заранее сообщать о поломках и прочее. Но если вы дадите ее погонять подросткам в деревню, они точно найдут способ ее сломать. И починить ее сможет один лишь Илон Маск. А вот жигули вам вам смогут починить в той же деревне и за дешево.
Возьмем спецификацию на недорогой современный HDD
найдем пугающую строчку Nonrecoverable Read Errors per Bits Read, Max 1 per 10E14, но стоит это понимать так: что при попытке чтения может возникнуть ситуация, что сектор будет прочитан с ошибкой и емкости ЕСС не хватит для коррекции. Но в этом случае накопитель не отдаст битых данных. Будет банально взведен флаг ошибки чтения. Если речь шла о случайной ошибке, то при повторном чтении, все прочитается. Также стоит учесть, что по умолчанию микропрограмма такой сектор в современном накопителе попытается перечитать и не раз и не два. Например во многих десктопных версиях сигейтов по умолчанию 20 попыток чтения.
В общем не стоит бояться случайных ошибок. Дефектообразование на пластинах это несколько другой род проблем и не относится к этому пункту спецификации.
найдем пугающую строчку Nonrecoverable Read Errors per Bits Read, Max 1 per 10E14, но стоит это понимать так: что при попытке чтения может возникнуть ситуация, что сектор будет прочитан с ошибкой и емкости ЕСС не хватит для коррекции. Но в этом случае накопитель не отдаст битых данных. Будет банально взведен флаг ошибки чтения. Если речь шла о случайной ошибке, то при повторном чтении, все прочитается. Также стоит учесть, что по умолчанию микропрограмма такой сектор в современном накопителе попытается перечитать и не раз и не два. Например во многих десктопных версиях сигейтов по умолчанию 20 попыток чтения.
В общем не стоит бояться случайных ошибок. Дефектообразование на пластинах это несколько другой род проблем и не относится к этому пункту спецификации.
Хм. У меня падала zfs и восстановление было автоматом. Типа check disk, но на 2ТБ дисках в raidz2 он был долгий, точно уже не помню, но точно больше 2 часов.
Хм. У меня падала zfs и восстановление было автоматом. Типа check disk, но на 2ТБ дисках в raidz2 он был долгий, точно уже не помню, но точно больше 2 часов.
Разве ж это падение? Так мелкая проблема, которая легко поправляется штатными средствами.
А время проверки зависит от размера метаданных, корректность которых необходимо проверить.
Под падением будет подразумевать случаи, где штатные средства ничем не могут помочь.
А можете дать рекомендации :)) Как подстраховаться, для автоматического восстановления!
Что бы можно было к «вам» не обращаться.
Когда мне заломили цену за восстановление информации с 1гб диска в нашем городе.
Дешевле было весь бизнес с нуля начать :(
Что бы можно было к «вам» не обращаться.
Когда мне заломили цену за восстановление информации с 1гб диска в нашем городе.
Дешевле было весь бизнес с нуля начать :(
Когда мне заломили цену за восстановление информации с 1гб диска в нашем городе.
Дешевле было весь бизнес с нуля начать :(
Или бизнес весь совсем ничего не стоил или обратились не в профильную компанию, которая формировала цену непонятно из чего. Стоимость восстановления данных с неисправных дисков по странам СНГ обычно от нескольких десятков, до нескольких сотен евро. Исключение могут составлять случаи с сильно поврежденными накопителями, требующих большое количество донорских затрат и случаи с восстановлением фрагментированных файлов без опоры на файловую систему.
А можете дать рекомендации :)) Как подстраховаться, для автоматического восстановления!
Что бы можно было к «вам» не обращаться.
Продумайте и внедрите систему резервного копирования. Учитывайте различные события, которые могут повлиять на целостность и наличие ваших данных. Ищите меры противодействия. При продуманной системе резервного копирования услуги компаний по восстановлению данных не потребуются.
Да сумма была за 1000 б. но это было 4 года назад.
Недавно была
проблема с резервным копированием, основной сервер имел раид 0, на одном из дисков стали сыпаться сектора. При этом делались резервные копии, на сервер резервного копирования.
В результате когда все грохнулось, оказалось, что повреждено всё.
Дело в том, что к основным файлам, обращаются ооооочень редко, а пользуются их сжатой копией, но когда понадобилось, оказалось все плохо.
Недавно была
проблема с резервным копированием, основной сервер имел раид 0, на одном из дисков стали сыпаться сектора. При этом делались резервные копии, на сервер резервного копирования.
В результате когда все грохнулось, оказалось, что повреждено всё.
Дело в том, что к основным файлам, обращаются ооооочень редко, а пользуются их сжатой копией, но когда понадобилось, оказалось все плохо.
Да сумма была за 1000 б. но это было 4 года назад.
в профильной компании такая цена могла быть разве что за диск с очень серьезными повреждениями на поверхностях и неисправными головками, где бы потребовалось множество доноров. Если же речь идет о рядовых дефектообразования и проблемах с микропрограммой, то стоимость даже в самых дорогих городах РФ в профильных компаниях в несколько раз ниже, чем озвученная Вами.
Недавно была
проблема с резервным копированием, основной сервер имел раид 0, на одном из дисков стали сыпаться сектора. При этом делались резервные копии, на сервер резервного копирования.
В результате когда все грохнулось, оказалось, что повреждено всё.
Дело в том, что к основным файлам, обращаются ооооочень редко, а пользуются их сжатой копией, но когда понадобилось, оказалось все плохо.
здесь вы допустили ошибки
1. Использовали уровень массива без избыточности (RAID 0 — чередование)
2. Копии складывали на этот массив.
Итог Вы сами вскоре и ощутили. Но если накопитель с дефектами не довели до запилов, то как правило получить данные не будет большой сложностью.
Да сумма была за 1000 б. но это было 4 года назад.
Когда мне заломили цену за восстановление информации с 1гб диска в нашем городе.
Дешевле было весь бизнес с нуля начать :(
Полагаю, что накопитель был емкостью 1Тб
Какой NAS фирмы? Чтобы знать :)
Sign up to leave a comment.
Восстановление данных из поврежденного массива RAID 5 в NAS под управлением Linux