Комментарии 6
Лучше расскажите, появились ли контроллеры без шифрования, чтобы реально было данные восстанавливать при сгоревшем контроллере.
По-моему, шифрование в SSD используется не так уж часто. Если вы имеете в виду наложение xor-маски, то этот процесс, вообще говоря, не является шифрованием. Он используется для скремблирования с целью статистического выравнивания заряда соседних ячеек. Но, конечно, это значительно усложняет восстановление.
Шифрование не является единственной помехой для восстановления данных.
Все реально восстановить, вопрос только денег и времени… Как в любом деле — проще предотвратить беду, чем потом героически, что-то там восстанавливать. Репликация критичных данных прекрасно решает проблему. (Не RAID — эта хрень только для механики годна...) SSD как правило «цепляют простуду» коллективно, т.к. воздействие — коллективное на них.
Данные на SSD всегда хранятся вперемешку, т.е. можно сказать скремблированы, это природа SSD, её не поменять.
Понять, где, что хранится, позволяют таблицы, вот их-то потеря и вызывает видимую «смерть» SSD. (на самом деле такой SSD можно восстановить заводским методом прошивки, хотя данные будут утеряны, либо secure erase, если служебные таблицы хотя бы остались.)
Контроллеры потребительских SSD и стоковые FW под них, в силу своей простоты и дешевизны, не могут заботиться о сохранности таблиц во время внезапного пропадания питания или сбоев по питанию, от того и мрут потребительские SSD — часто и с удовольствием, если не защищены бесперебойниками.
Но ситуация — меняется, проектируются новые контроллеры (хотя дело это дорогое и не быстрое), SSD уходят от ATA команд, которые им как собаке пятая нога, писатели FW все больше уделяют внимания сохранности таблиц их дублированию или хотя бы сохранности работоспособности SSD после сбоя.
Зоопарк всевозможных «производителей» SSD сужается, всего год назад их было более 135, сейчас уже меньше 130 ;) Прогресс! Проще стандартизировать процессы и технологии.
А шифрование, только слегка подливает масла в огонь, но не является первопричиной проблемы.
Например Vector 180 — будет иметь частичную защиту главных таблиц, что позволит им как минимум остаться работоспособными, хотя есть вероятность потери данных. (В лаборатории не получилось их потерять, но уверен, что россияне найдут способ!) Очереди за ними точно не будет.
Intrepid 3600 — полная защита по питанию и RAID на N+1 на NAND, нет очередей за ними, что-то. А ведь там не Sand Force полный сюрпризов, как его не программируй…
В следующее поколение контроллеров уже будет встроен еще более продвинутый механизм защиты таблиц размещения, и контроль питания.
FW будет более продвинутой. Не все сразу, забыли как первые HDD работали?
Я бы ставил вопрос иначе — не «как мне восстановить данные?», а «что делать, что бы не потерять их»!
Все реально восстановить, вопрос только денег и времени… Как в любом деле — проще предотвратить беду, чем потом героически, что-то там восстанавливать. Репликация критичных данных прекрасно решает проблему. (Не RAID — эта хрень только для механики годна...) SSD как правило «цепляют простуду» коллективно, т.к. воздействие — коллективное на них.
Данные на SSD всегда хранятся вперемешку, т.е. можно сказать скремблированы, это природа SSD, её не поменять.
Понять, где, что хранится, позволяют таблицы, вот их-то потеря и вызывает видимую «смерть» SSD. (на самом деле такой SSD можно восстановить заводским методом прошивки, хотя данные будут утеряны, либо secure erase, если служебные таблицы хотя бы остались.)
Контроллеры потребительских SSD и стоковые FW под них, в силу своей простоты и дешевизны, не могут заботиться о сохранности таблиц во время внезапного пропадания питания или сбоев по питанию, от того и мрут потребительские SSD — часто и с удовольствием, если не защищены бесперебойниками.
Но ситуация — меняется, проектируются новые контроллеры (хотя дело это дорогое и не быстрое), SSD уходят от ATA команд, которые им как собаке пятая нога, писатели FW все больше уделяют внимания сохранности таблиц их дублированию или хотя бы сохранности работоспособности SSD после сбоя.
Зоопарк всевозможных «производителей» SSD сужается, всего год назад их было более 135, сейчас уже меньше 130 ;) Прогресс! Проще стандартизировать процессы и технологии.
А шифрование, только слегка подливает масла в огонь, но не является первопричиной проблемы.
Например Vector 180 — будет иметь частичную защиту главных таблиц, что позволит им как минимум остаться работоспособными, хотя есть вероятность потери данных. (В лаборатории не получилось их потерять, но уверен, что россияне найдут способ!) Очереди за ними точно не будет.
Intrepid 3600 — полная защита по питанию и RAID на N+1 на NAND, нет очередей за ними, что-то. А ведь там не Sand Force полный сюрпризов, как его не программируй…
В следующее поколение контроллеров уже будет встроен еще более продвинутый механизм защиты таблиц размещения, и контроль питания.
FW будет более продвинутой. Не все сразу, забыли как первые HDD работали?
Я бы ставил вопрос иначе — не «как мне восстановить данные?», а «что делать, что бы не потерять их»!
Зря вы про RAID и SSD — RAID-5 на SSD только в путь!
Не всегда он добрый получается…
Были случаи на SF контроллерах, правда. Что FW лочил сразу все SSD в RAID или сразу несколько SSD, а из этого состояния выход только один — secure erase. Причем взлом FW давал возможность запустить SSD без secure erase, но таблицы все равно были затерты :(
Вот такая печалька…
Новое поколение контроллеров в этом не замечено пока :)
А еще бывают пожары, потопы и человеческий фактор, т.е. когда все накопители рядом — риск потери всего и сразу все же выше, в сравнении с методом размещения данных во множестве мест.
Это я к тому, что RAID не всемогущий, бэкап или реплика все равно необходимы. Не стоит только на RAID полагаться.
Были случаи на SF контроллерах, правда. Что FW лочил сразу все SSD в RAID или сразу несколько SSD, а из этого состояния выход только один — secure erase. Причем взлом FW давал возможность запустить SSD без secure erase, но таблицы все равно были затерты :(
Вот такая печалька…
Новое поколение контроллеров в этом не замечено пока :)
А еще бывают пожары, потопы и человеческий фактор, т.е. когда все накопители рядом — риск потери всего и сразу все же выше, в сравнении с методом размещения данных во множестве мест.
Это я к тому, что RAID не всемогущий, бэкап или реплика все равно необходимы. Не стоит только на RAID полагаться.
Поддерживаю, RAID это в первую очередь для поддержки горячей замены и продолжения онлайн работы при сбое, а вот резервное копирование данных это резервное копирование данных :) Тут немного особняком стоят распределённые файловые системы, особенно с контролем версий, но они дороги, не унифицированы, а для дома вообще являются чем то не реальным.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция контроллеров SSD-дисков