периодическая ручная копия важного на внешний накопитель с отключением оного после сеанса копирования будет выглядеть куда более надежной моделью сохранения данных.
Но немного будет страдать актуальность. И постоянная суета с копирование. Но дешевизна вложений светит постоянным личным участием.
По поводу низкой надежности смерти накопителей от мельчайших чихов в их стороны, есть проблемка, что оба накопителя в RAID 1 будут подвержены одинаковым воздействиям и немало случаев будет, где случится утеря данных сразу на двух накопителя.
По этой причине вариант регулярного копирования за пределы ПК выглядит лучше.
Как на мой взгляд для среднего домашнего пользователя варианты бэкапа будут такими:
1. ручное регулярное копирование на внешний накопитель, а лучше на 2-3 накопителя.
2. недорогой NAS, который недоступен, как шара для ПК и сам лишь периодически на ПК и забирает обновленные данные к себе в хранилище.
3. Облачные сервисы
4. RAID 1 конечно можно рассмотреть, как некую меру страхующую от неприятностей, но слишком уж сильно уязвимая к различным событиям. Я бы эту меру рассматривал как дополнительную к иным мерам. (исхожу из количества изученных ситуаций потери данных пользователем)
Ну это распространенное предположение, для человека, который не видит разницу между NAS и обычным внешним диском. В принципе рядовой пользователь и не должен видеть разницу. Желательно, чтобы об этой особенности пользователю рассказал продавец-консультант при покупке.
Ну в таком случае вам лучше обратиться в лабораторию восстановления данных для проведения диагностических мероприятий.
Вменяемая лаборатория, как правило проведет диагностику в течение 5-30 минут, после которой обрисует вам возможный план работ и стоимость. А также согласует возможные подобные камни.
Для ударенных стучащих дисков однозначно потребуется вскрытие. Осмотр под микроскопом слайдеров и рециркуляционного фильтра, на предмет наличия черной металлической пыли.
Слайдер пилящегося Seagate Grenada.Хотя визуально пластины чистые.
Диск который совсем молчит может оказаться более простым случаем. Сначала проверить плату. При необходимости адаптировать плату от донора. А дальше уже оценивать его состояние.
Бэкап куда? На этот же ПК?
Если на этот же ПК, то сохраняется зависимость от воздействий на ПК.
Если на какой-либо сетевой накопитель, то доступная шара также может оказаться уязвимой.
Если это какой-то внешний накопитель, то уже упирается в человеческий фактор. Пользователь как минимум должен обеспечить, чтобы в нужное время был включен ПК и чтобы был подключен внешний накопитель.
Простые схемы бэкапа в виде создания одной копии во многих случаях все равно остаются уязвимыми к различным факторам. Но конечно это лучше, чем полное отсутствие резервного копирования.
По этому поводу можно добавить, что хватает сильных людей, которые с легкостью подключают SATA кабели наоборот несмотря на препятствие этому со стороны создателей кабеля.
Человеческий фактор же. Резервное копирование информации — это на самом деле весьма хлопотный участок работы. Полная его автоматизация с достаточной степенью надежности для рядового пользователя не выглядит экономически целесообразной.
Регулярное резервирование вручную (копия с одного на другой накопитель) порядком будет надоедать обычному пользователю и как следствие регулярность страдать.
Упал накопитель и после издает щелчки, писки, хрюканье, жужжание — однозначно никакой дальнейшей эксплуатации быть не может.
Если упал отключенным и после был включен и работает нормально, то есть смысл выполнить комплекс тестов, а потом уже решать использовать его хоть как-то или нет
Диск не реагирующий на подачу питания в некоторых случаях может подлежать реанимации для дальнейшего использования. (например при неисправности платы контроллера или мелких проблемах в микрокоде или его структурах). В остальных случаях обычно речь идет о получении данных, но не дальнейшем использовании диска.
Многие люди не задумываются о том, что могут потерять свои данные каким-то иным путем, кроме как обдуманным удалением по собственному желанию.
А стоило бы подумать:
1. Возможны отказы носителей информации и стороннего оборудования приводящего к выходу из строя накопителей.
2. Возможны различные логические повреждения.
3. Возможны различные атаки вредоносного ПО.
4. Ошибочные действия самих пользователей.
5. Потеря накопителя или его хищение.
Как например в случае описанном выше вероятнее всего имели место быть пункт 2 и 4
Сначала сбой, потом невнимательный пользователя не глядя соглашается с предложением ОС отформатировать и даже записывает несколько файлов, а только потом задается вопросом: «А где все остальные данные?»
По поводу RAID 1 можно сказать, что такая организация резервного копирования конечно лучше, чем одиночный диск, но весьма уязвима:
1. Выгоревший БП или удар шваброй уборщицы по системному блоку легко может уволочь оба диска в мир иной.
2. Какие-либо повреждения файловой системы будут писаться ровненько на два диска.
3. Любой прилетевший шифровальщик прибьет данные на обоих накопителях.
4. Ошибка пользователя точно также отразится на данных на обоих накопителях.
Так что RAID 1 стоит рассматривать скорее, как страховку от простоев при отказе единственного накопителя, а не как надежную меру сохранности данных. Любой RAID с избыточностью хорош лишь как дополнение к мерам резервного копирования.
На моей памяти одна демка на спектруме устанавливала адрес стека на начало экранной памяти 16384
Ошибочка. При добавлении чего-либо в стек изменение регистра SP (указателя на вершину стека) происходит в сторону уменьшения.
В случае ZX Spectrum, если требовался вывод только пикселов без изменения атрибутов, то указывалось на #5800 (начало области атрибутов) и далее PUSH'илось на экран до #4000.
Запись в порт #7FFD осуществляла переключение страничек по 16кб. Младшие три бита значения использовались для переключения страничек в адресном диапазоне #C000 — #FFFF. 3 бит второй экран. А дальше подробностей уже наверное и не вспомню, так как последний раз баловался программированием на клоне спектрума в далеких девяностых.
А не подскажите, почему программы странно иногда переводят hex в десятичные числа? Например из
это не программы «переводят», а столбцы Cur Wor Thr содержат некие значения формируемые микропрограммой накопителя, которые обычно ничего не имеют общего с реальным счетчиком в RawValues. Это лишь некие значения, которые формируются по известному авторам конкретной фирмвари алгоритмам, которые при достижении в Cur значения Thr позволят вари посчитать, что SMART status BAD.
Так помечаются как удалённые же при обычном форматировании, в чём тогда разница то? Что-то же он там делает по 30-60 минут.
Если вы формтирует флешку быстрым форматированием, то будет небольшое число операций записи/чтения по созданию чистой файловой системы. Никакого массового высвобождения блоков без TRIM не случится. Все как было включено в трансляцию так и останется. По мере записи новых данных будет происходить запись в те же или новые блоки. При записи в новые блоки старые будут исключаться из трансляции и очищаться. Такой механизм не очень хорошо выравнивает износ, но при отсутствии TRIM хоть так.
В случае «полного» форматирования в Windows будет еще чтение всего логического диапазона (проверка на его доступность) в остальном все будет тоже самое.
из всего этого важно понять, что форматирование средствами ОС, не приводит к сбросу содержимого NAND накопителей без TRIM.
а разработчики твердотельных накопителей понимают под «мусором» повторно перезаписанный LBA. Попытаюсь объяснить. Допустим, ОС модифицирует таблицу размещения файлов, допустим, восемнадцатый LBA. Ну и 10 раз его переписала. В текущем блоке NAND мы получили 10 записанных страниц, ассоциированных с 18 LBA.
Дело в том, что во многих алгоритмах флешек транслятор в сравнении с SSD сильно упрощен. Многие каждую попытку записи в тот же FAT будут отрабатывать так:
1) Чтение целиком блока (группы страниц).
2) Очистка прочитанного блока в NAND.
3) Внесение незначительного изменению в одну из страничек.
4) Выбор оптимального блока для записи и запись.
На таких флешках получаем колоссальный провал в скорости записи на мелких файлах.
Как правило более новые алгоритмы уже не спешат трогать оригинальный блок и просто формируют блок-апдейт в котором содержатся группа модифицированных страниц которые включаются в разные места в трансляции.
Блоки-апдейты используются как точечные наложения на трансляцию. Но в ограниченных условиях USB flash их количество не бывает особо большим. Микропрограммы использующие блоки-апдейты во многих флешках весьма просты. Некоторые из них «подглядывают» в юзерзону и определяю положение таблиц FAT или применяют данный метод для первых блоков в трансляции и для них используют методы писания исключительно блоками-апдейтам. У таких флешек есть некоторое подобие «уборки мусора», но оно обычно весьма быстротечно и обычно достаточно нескольких секунд после окончания копирования, чтобы флешках завершила процессы с этим «мусором».
По поводу «транслятора». Я не могу много написать из за соглашения о неразглашении, но некоторые вещи, размещенные в общем доступе, могу озвучить. Ну во первых, сама L2P очень даже не маленькая. Ее размер легко прикинуть по простой формуле. Делим объем накопителя на 1000 и получаем размер L2P. Для небольших накопителей коэффициент может быть больше просто из за меньшей разрядности физического адреса NAND, например, 1500. Но все равно — для накопителя в 1Gb надо иметь таблицу в 1Mb. Соответственно, никто столько ОЗУ в контроллер не положит.
Для современных носителей коэффициент похожий. Для старых коэффициент поболее.
Например флешка 1Гб, размер блока 0x21000 байт (128кб полезных данных), страница 2112 байт, размер данных в ней 2048.
Для блочной трансляции нужно 8192 блоков, чтобы сформировать полный гигабайт. Для описания очередности использования часто применялись двухбайтовые записи с порядковым номером физического блока в логическом банке. Т.е для описания L2P нужно 16 384 байта. Добавим к этому еще дополнительные таблицы похожего размера и в принципе получим реальный размер транслятора. В такой маленькой старой флешке он не превысит 64-128кб в сумме. Округлим до 128кб и это даст соотношение 1 к 8192.
Разумеется даже в таких флешках правило имело место деление на логические банки и у каждого банка была своя табличка трансляции.
Скажу так, я смогу восстановить всю таблицу, даже если она будет полностью утеряна. Конечно, на своем железе со своими алгоритмами.
многие разработчики в страницы кроме пользовательских данных и ECC отводят место для номера блока/страницы (не везде конечно), различных флажков и т.п. И знаю, где и что значат байты, биты в служебке несложно реконструировать актуальные таблицы трансляции. Или провести сборку образа зная как интерпретировать служебные данные.
Так что L2P кешируется небольшими частями и «размазана» по всей памяти. И утрата одной из частей — не катастрофа.
Для пользователя это таки обычно катастрофа так как в большинстве простых фирмварей нет в помине каких-либо процедур для реконструкции транслятора.
Даже если контроллер и память одинаковые, накопитель от известного бренда будет гораздо надежней, чем нонейм.
С большими оговорками. Например в случае USB flash, где подобные наборы одинаковых микросхем друг от дружки отличает только текстовая строчка с названием в паспорте устройства и пластик корпуса вряд ли можно назвать справедливым.
Единственное, не понял про GC (в Вашей интерпретации). Возможно, я под ним понимаю более широкий набор алгоритмов. Вплоть до переписывания валидных данных из блока, подготовленного к стиранию. Немного не понял, что Вы подразумеваете под алгоритмом ротации. Все равно надо искать кандидата на erase хотя бы по 2м параметрам: наименьшее количество валидных данных и изношенности. Или в самом простом случае можно обойтись без поиска, взяв самый «старый» блок? Работать, конечно будет, но медленно…
Сейчас будем говорить применительно к USB Flash. Давайте копнем немного работу ОС с носителем c файловой системой FAT32. На котором пусть будет крупный файл (например видео).
При удалении этого файла ОС удалит цепочку занимаемых кластеров из обеих копий таблиц, в директории, где была файловая запись проставит 0xE5 вместо первого байта имени файла. Непосредственно сами данные эта процедура не тронет.
Для NAND контроллера сначала поступит запрос на чтение группы секторов содержащий таблицы FAT и директорию (как правило это весьма небольшое количество блоков).
Следом поступят запросы на перезапись подобного или чуть меньшего объема (зависит от того как именно реализован драйвер, нормальный драйвер не будет предлагать переписывать содержимое таблиц, которое не изменилось).
После этой операции микропрограмма NAND контроллера USB Flash даже не подозревает о том, что огромное количество блоков занимаемых удаленным файлом теперь стали свободными (в случае SSD именно TRIM информирует об освобожденных LBA диапазонах). Эти блоки остаются включенными в трансляцию и по прежнему предоставляют те данные, которое они содержат.
Это утверждение легко проверить. Запишите на USB flash файл, сделайте с помощью WinHex образ. После удалите и опять сделайте образ. И сравните двай файла. Изменения будут только в элементах файловой системы, а в области данных никакой очистки не будет в накопителе без TRIM.
Так вот в случае накопителей, где нет обратной связи с ОС в принципе нет «мусора» (большого количества блоком с очень маленьким заполнением, который бы можно было срастить в одиночный, для более эффективной работы механизма выравнивания износа.)
Знаю несколько человек, у которых диски помирали через полгода-год простоя. QLC — так пока там гарантированное время хранения уже неделями исчисляется, хотя, это данные годичной давности, может что улучшили.
обратите внимание, что я комментировал и указал про исправную память с малым износом. Для того, чтобы SSD или USB flash для пользователя превратились в кирпич достаточно, чтобы транслятор, который записан в тот же NAND перестал читаться. Вероятность попадания транслятора на изношенный блок достаточно высока, так как он постоянно модифицируемый в процессе работы накопителя. Но если в таком умершем накопителе выпаять NAND память, получить дампы, то как правило выясняется, что реальных потерь данных не так уж и много, разумеется если произвести корректную сборку с учетом многих нюансов алгоритмов.
А вот что флешка медленней читается после длительного простоя, думаю тут не только в ретраях дело, но еще и в «спасении» данных, то есть, прочитали на ретраях, перезаписали.
Как бы после чтения «медленных» файлов при второй попытке получите такие же результаты чтения.
Правда существенное торможение еще может быть при чтении неустойчиво читающихся кусках транслятора (не забываем о том, что MCU весьма скромный размер ОЗУ и в некоторых случаях держать полный транслятор недопустимая роскошь). И вот в этом случае, если по какой-то причине микропрограмма перепишет заново транслятор или его проблемную часть можно ожидать оживления накопителя.
1. GC. Без него не будет работать ни один nand-flash накопитель. Будь то серверный или самая дешевая китайская TFка;
Будут работать накопители и без GC и прекрасно работали. Естественно алгоритмы ротации при большом заполнении статически данных становились менее эффективным. С учетом многократного падения надежности NAND памяти c переходом от SLC к MLC, TLC, QLC начали разработки микропрограмм которые могли бы более эффективно размещать данные, дабы большее число блоков участвовало в ротации, ради того, чтобы емкие устройства с дешевой памятью жили несколько больше. Так как микропрограммы контроллеров понятия не имеют в подавляющем большинстве о файловых системах используемых на накопителях, то взаимосвязь с хостом организована посредством TRIM, где контроллер NAND накопителя от хоста получает информацию об LBA диапазоне из логического пространства, который стал свободным от данных (как именно можно прочесть в АТА стандарте на t13.org). Далее эти места транслируются нулями, а микропрограмма контроллера ведет уже анализ какие блоки можно очистить целиком и можно ли собрать из блоков с малым заполнением какой-либо один блок-апдейт для трансляции. В случае конкретно USB flash и карт памяти речи о TRIM не шло и соответственно алгоритмы GC в принципе не закладывались в микрокод, в отличие от SSD.
2. Будет ли FTL «крутиться» без связи с хостом, одному разработчику FW известно.
Вся трансляция, что в картах памяти, что в USB flash, что в SSD работает без участие ОС. ОС компьютера в принципе не имеет представление о том с каким контроллером она работает и сколько микросхем NAND памяти у контроллера, как организован интерлив между ними, синхронный ли он, какого размера блоком оперирует контроллер и т.п. Для ПК это просто накопитель с которым можно работать по определенному протоколу с использованием команд описанных в стандарте. Для ПК доступен лишь LBA диапазон реализуемый устройством, и вся работа ПК с носителем сводится на уровне RW операций. С появлением TRIM лишь чуть-чуть добавилось передаваемых параметров, но ОС так и не получила какой-либо взаимосвязи с алгоритмами NAND контроллеров.
Если подразумевалось именно активность микропрограммы накопителя только лишь при подачи питания и отсутствия коммуникации с хост-контроллером, то в случае USB flash в подавляющем случае ждать попросту нечего по очевидным причинам. Вряд ли кто-то будет писать микропрограмму со сложным анализом расположения данных, когда эффективность этих алгоритмов без того же TRIM будет сводиться к почти нулю. Так как микропрограмма устройства в принципе ничего не знает о файловой системе на нем и лишь обслуживает RW операции. И без сообщения мест которые стали чистыми ей попросту неизвестно, что можно подчищать.
3. Да, данные могут протухать. И достаточно быстро.
При исправной не изношенной NAND памяти сносного качества не так и быстры процессы естественной деградации. Хватает в запасе NAND микросхем, которые уже хранятся не один год и при перечитывании в ридерах PC3000flash или Nand Reader (софт-центр) отдают дампы в которых можно скорректировать битовые ошибки. Но надо отметить, что с каждым годом хранения количество ошибок растет. Многие уже без Read Retry и манипуляций с напряжением нереально прочесть с приемлемым качеством дампа. В условиях живых USB flash мы как правило наблюдаем, что флешка пролежавшая несколько лет читается заметно медленнее и при чтении даже линейно расположенных данных наблюдаем провалы в скорости (из-за того, что контроллеру приходится проводить больше процедур перечитки микросхем и выше накладные расходы на коррекцию битовых ошибок) В случае флешки, где есть изношенные участки памяти (и они включены в трансляцию) такое проявление мы заметим намного быстрее. А если блоки со служебными данными (с тем же транслятором) попадут на изношенный блок, то и вовсе есть риски, что флешка может и не стартануть.
про «полезность» дефрагментации SSD средствами ОС…
учитывая, что ОС не имеет представления о фактическом расположении данных в NAND микросхемах, то дефрагментация ее средствами во многих случаях не будет полезной, а скорее будет просто множеством пустых RW операций сокращающих срок жизни устройства.
Имея некоторый опыт работы с NAND памятью и реверс-инжинирингом алгоритма контроллеров хотел бы задать вопросы автору и внести некоторые уточнения, так как некоторые утверждения автора весьма спорные.
Когда школьник покупает флешку 32ГБайта, а обнаруживает, что на ней только 29 ГБайт, школьник еще не знает, что недостающее место не китайцы на фабрике украли, а разработчики алгоритма FTL.
Начнем с простого, что не стоит все списывать систему трансляции и ее нужды. Разница в емкости в первую очередь продиктована разными единицами измерения.
Гигабайт — это 1 000 000 000 байт
Гибибайт — это 1 073 741 824 байт
Рано или поздно сложится ситуация, когда у нас больше нет свободных блоков, в которые можно писать страницы.
В принципе невозможная ситуация, чтобы не было блоков для записи при наличии свободного пространства в логическом диапазоне.
Как-то немного затрагивал алгоритм работы одного из NAND контроллеров используемых в USB flash .
Если кратко, то в логическом банке число включаемых блоков в трансляцию всегда меньше количества блоков. Всегда есть полностью свободные блоки. Это можете увидеть из материала моей публикации.
Возможны разные подходы при записи данных в зависимости от их объема.
1) в одном случае дополнение данных в блоке будет как чтение блока в буфер, внесение изменений в данные, выбор блока в банке с наименьшим числом записей и запись изменнного содержимого в новый блок, очистка старого блока.
2) при мелких дополнениях некоторые фирмвари не спешат переписывать большие объемы данных и формируют блоки-блоки апдейты, которые отдельными страницами накладывают на логическую трансляцию (т.е. точечные подмены при трансляции для страниц разных блоков)
Проблема нехватки «личного времени» контроллера актуальна и для алгоритма выравнивания возрастов. Алгоритм Wear Leveling выполняется контроллером в моменты простоя накопителя, пока нет задач для записи или чтения пользовательских данных. Если же накопитель работает в режиме «короткометражек», то времени на выравнивание износа блоков просто нет.
Конечно можно делать различные предположения о выравнивании износа и перезаписях старых блоков. Но есть много «НО», которые дадут поле для размышления.
В флешках нет элемента питания и нет внутренних «часов», контроллер не имеет представления были данные записаны год назад или вчера. Через протоколы передачи данных с хостом не предусмотрен запрос времени и даты у компьютера. Поэтому реализовать просто перезапись «старых данных» в принципе не представляется возможным.
Основное выравнивание износа по факту происходит при изменении данных, что достаточно неплохо видно по материалам моей публикации. Отсюда зачастую и наблюдаем, что убитые накопители с NAND flash были заполнены статичными данными, а активное изменение шло в небольшой области, что привело к тому, что не так много блоков участвовало в ротации (имеется в виду, те что включены в трансляцию и подвергались изменению и блоки вне трансляции)
А что будет со страницей, которая утратила актуальность? Данные, записанные в ней больше не нужны, но стереть ее мы не сможем, потому что стирать дозволено только блоками, а в этом же блоке могут быть еще актуальные страницы. Рано или поздно сложится ситуация, когда у нас больше нет свободных блоков, в которые можно писать страницы. Зато, в остальных блоках то там, то сям будут неактуальые страницы. Чтобы такого не случилось, в накопителях крутится функционал «сборщика мусора», который занимается тем, что отыскивает «дырявые» блоки, в которых меньше всего актуальных страниц, и переносит актуальные страницы в новый блок. Таким образом «дырявый» блок освобождается полностью от актуальных страниц и его можно стереть… А в новом же блоке все страницы остаются актуальными. Напоминает дефрагментацию.
Алгоритмы «сбора мусора» — это попытка найти блоки с малым заполнением в NAND накопителях, чтобы сформировать блоки со смешанным содержимым (блок-апдейты), которые странично или группами страниц накладываются в трансляцию. Но для реализации этого алгоритма контроллеру нужна обратная связь с ОС. т.е. при удалении должны сообщаться LBA диапазоны, которые микропрограмма оттранслирует к конкретным блокам. Технология например для SSD и SMR HDD существует и называется TRIM. А много ли вы сможете найти USB flash с поддержкой TRIM?
Наверняка, у вас были случаи, когда вы скинули на флешку какие-то фотографии со свадьбы друга, год флешка полежала в ящике стола (как вам казалось, в целости и сохранности), а потом некоторые из фоток прочитались только наполовину. Дело в том, что единожды записанная в NAND-flash память информация способна «протухнуть» со временем.
Для начала стоит отметить, что если страница не прочиталась, то в принципе контроллер не отдаст каких либо данных. При нечитаемой странице вы получите ошибку чтения и пустой буфер, а не искаженные данные в нем. Всякие половинчатые фотографии это чаще следствие ошибок файловой системы, перекрестные записи, искажение данных при в буферном ОЗУ микроконтроллера, а также различные ошибки в трансляции, когда вместо данных транслируется мусор. Но эти явления в большинстве своем не связаны с естественной деградацией самой NAND памяти и ее содержимого.
Из всего вышесказанного подведу итог: не стесняйтесь «заряжать» флешки, это благоприятно сказывается на их быстродействии и надежности. А если вас захэйтят технари, просто дайте им ссылочку на эту статью.
Процедуры перестроения трансляции при простое могут быть реализованы в некоторых микропрограмма USB flash, но исходя из вопросов выше вряд ли они такие, как себе представляет автор. Также наличие процедур оффлайн сканирования во многих микропрограммах USB flash опять же под большим вопросом. В итоге рекомендация включать USB flash с поданными на них постоянными 5В не кажется однозначно полезной.
Зачем тащить трос? Откуда вы его взяли? Нить/протяжку надо было протащить.
Трос фигурировал в предыдущих комментариях. Вероятно для упрощения описания задачи. Очевидно, что изначально протягивается что-то тонкое и максимально легкое, способной выдержать процедуру протяжки троса. Но даже 4 мили нити это не такая и маленькая масса для машинки или животного. У животного очевидно больше преимуществ в плане проходимости.
Также далее в комментарии предлагается использовать машинку и добавить к ней 4 мили провода, который будет иметь вес заметно больший, чем вес нити, что сделает невозможным использование маленькой машинки.
Машинки побольше вряд ли можно сделать такими, чтобы они после себя не оставили лишней трудноудалимой грязи.
Но немного будет страдать актуальность. И постоянная суета с копирование. Но дешевизна вложений светит постоянным личным участием.
По поводу низкой надежности смерти накопителей от мельчайших чихов в их стороны, есть проблемка, что оба накопителя в RAID 1 будут подвержены одинаковым воздействиям и немало случаев будет, где случится утеря данных сразу на двух накопителя.
По этой причине вариант регулярного копирования за пределы ПК выглядит лучше.
Как на мой взгляд для среднего домашнего пользователя варианты бэкапа будут такими:
1. ручное регулярное копирование на внешний накопитель, а лучше на 2-3 накопителя.
2. недорогой NAS, который недоступен, как шара для ПК и сам лишь периодически на ПК и забирает обновленные данные к себе в хранилище.
3. Облачные сервисы
4. RAID 1 конечно можно рассмотреть, как некую меру страхующую от неприятностей, но слишком уж сильно уязвимая к различным событиям. Я бы эту меру рассматривал как дополнительную к иным мерам. (исхожу из количества изученных ситуаций потери данных пользователем)
Вменяемая лаборатория, как правило проведет диагностику в течение 5-30 минут, после которой обрисует вам возможный план работ и стоимость. А также согласует возможные подобные камни.
Для ударенных стучащих дисков однозначно потребуется вскрытие. Осмотр под микроскопом слайдеров и рециркуляционного фильтра, на предмет наличия черной металлической пыли.
Слайдер пилящегося Seagate Grenada.Хотя визуально пластины чистые.
Диск который совсем молчит может оказаться более простым случаем. Сначала проверить плату. При необходимости адаптировать плату от донора. А дальше уже оценивать его состояние.
Если на этот же ПК, то сохраняется зависимость от воздействий на ПК.
Если на какой-либо сетевой накопитель, то доступная шара также может оказаться уязвимой.
Если это какой-то внешний накопитель, то уже упирается в человеческий фактор. Пользователь как минимум должен обеспечить, чтобы в нужное время был включен ПК и чтобы был подключен внешний накопитель.
Простые схемы бэкапа в виде создания одной копии во многих случаях все равно остаются уязвимыми к различным факторам. Но конечно это лучше, чем полное отсутствие резервного копирования.
Регулярное резервирование вручную (копия с одного на другой накопитель) порядком будет надоедать обычному пользователю и как следствие регулярность страдать.
Если упал отключенным и после был включен и работает нормально, то есть смысл выполнить комплекс тестов, а потом уже решать использовать его хоть как-то или нет
Диск не реагирующий на подачу питания в некоторых случаях может подлежать реанимации для дальнейшего использования. (например при неисправности платы контроллера или мелких проблемах в микрокоде или его структурах). В остальных случаях обычно речь идет о получении данных, но не дальнейшем использовании диска.
А стоило бы подумать:
1. Возможны отказы носителей информации и стороннего оборудования приводящего к выходу из строя накопителей.
2. Возможны различные логические повреждения.
3. Возможны различные атаки вредоносного ПО.
4. Ошибочные действия самих пользователей.
5. Потеря накопителя или его хищение.
Как например в случае описанном выше вероятнее всего имели место быть пункт 2 и 4
Сначала сбой, потом невнимательный пользователя не глядя соглашается с предложением ОС отформатировать и даже записывает несколько файлов, а только потом задается вопросом: «А где все остальные данные?»
По поводу RAID 1 можно сказать, что такая организация резервного копирования конечно лучше, чем одиночный диск, но весьма уязвима:
1. Выгоревший БП или удар шваброй уборщицы по системному блоку легко может уволочь оба диска в мир иной.
2. Какие-либо повреждения файловой системы будут писаться ровненько на два диска.
3. Любой прилетевший шифровальщик прибьет данные на обоих накопителях.
4. Ошибка пользователя точно также отразится на данных на обоих накопителях.
Так что RAID 1 стоит рассматривать скорее, как страховку от простоев при отказе единственного накопителя, а не как надежную меру сохранности данных. Любой RAID с избыточностью хорош лишь как дополнение к мерам резервного копирования.
Ошибочка. При добавлении чего-либо в стек изменение регистра SP (указателя на вершину стека) происходит в сторону уменьшения.
В случае ZX Spectrum, если требовался вывод только пикселов без изменения атрибутов, то указывалось на #5800 (начало области атрибутов) и далее PUSH'илось на экран до #4000.
P.S. приятно вспомнить TASM, STS )
это не программы «переводят», а столбцы Cur Wor Thr содержат некие значения формируемые микропрограммой накопителя, которые обычно ничего не имеют общего с реальным счетчиком в RawValues. Это лишь некие значения, которые формируются по известному авторам конкретной фирмвари алгоритмам, которые при достижении в Cur значения Thr позволят вари посчитать, что SMART status BAD.
В свое время пробовал немного описать о том, как происходит взаимодействие ПК с накопителем и что накопитель может отдать в SMART Важный момент, что в старой заметке не указал интервал мониторинга, который не стоит делать каждую минуту.
Если вы формтирует флешку быстрым форматированием, то будет небольшое число операций записи/чтения по созданию чистой файловой системы. Никакого массового высвобождения блоков без TRIM не случится. Все как было включено в трансляцию так и останется. По мере записи новых данных будет происходить запись в те же или новые блоки. При записи в новые блоки старые будут исключаться из трансляции и очищаться. Такой механизм не очень хорошо выравнивает износ, но при отсутствии TRIM хоть так.
В случае «полного» форматирования в Windows будет еще чтение всего логического диапазона (проверка на его доступность) в остальном все будет тоже самое.
из всего этого важно понять, что форматирование средствами ОС, не приводит к сбросу содержимого NAND накопителей без TRIM.
Дело в том, что во многих алгоритмах флешек транслятор в сравнении с SSD сильно упрощен. Многие каждую попытку записи в тот же FAT будут отрабатывать так:
1) Чтение целиком блока (группы страниц).
2) Очистка прочитанного блока в NAND.
3) Внесение незначительного изменению в одну из страничек.
4) Выбор оптимального блока для записи и запись.
На таких флешках получаем колоссальный провал в скорости записи на мелких файлах.
Как правило более новые алгоритмы уже не спешат трогать оригинальный блок и просто формируют блок-апдейт в котором содержатся группа модифицированных страниц которые включаются в разные места в трансляции.
Блоки-апдейты используются как точечные наложения на трансляцию. Но в ограниченных условиях USB flash их количество не бывает особо большим. Микропрограммы использующие блоки-апдейты во многих флешках весьма просты. Некоторые из них «подглядывают» в юзерзону и определяю положение таблиц FAT или применяют данный метод для первых блоков в трансляции и для них используют методы писания исключительно блоками-апдейтам. У таких флешек есть некоторое подобие «уборки мусора», но оно обычно весьма быстротечно и обычно достаточно нескольких секунд после окончания копирования, чтобы флешках завершила процессы с этим «мусором».
Для современных носителей коэффициент похожий. Для старых коэффициент поболее.
Например флешка 1Гб, размер блока 0x21000 байт (128кб полезных данных), страница 2112 байт, размер данных в ней 2048.
Для блочной трансляции нужно 8192 блоков, чтобы сформировать полный гигабайт. Для описания очередности использования часто применялись двухбайтовые записи с порядковым номером физического блока в логическом банке. Т.е для описания L2P нужно 16 384 байта. Добавим к этому еще дополнительные таблицы похожего размера и в принципе получим реальный размер транслятора. В такой маленькой старой флешке он не превысит 64-128кб в сумме. Округлим до 128кб и это даст соотношение 1 к 8192.
Разумеется даже в таких флешках правило имело место деление на логические банки и у каждого банка была своя табличка трансляции.
многие разработчики в страницы кроме пользовательских данных и ECC отводят место для номера блока/страницы (не везде конечно), различных флажков и т.п. И знаю, где и что значат байты, биты в служебке несложно реконструировать актуальные таблицы трансляции. Или провести сборку образа зная как интерпретировать служебные данные.
Для пользователя это таки обычно катастрофа так как в большинстве простых фирмварей нет в помине каких-либо процедур для реконструкции транслятора.
С большими оговорками. Например в случае USB flash, где подобные наборы одинаковых микросхем друг от дружки отличает только текстовая строчка с названием в паспорте устройства и пластик корпуса вряд ли можно назвать справедливым.
Сейчас будем говорить применительно к USB Flash. Давайте копнем немного работу ОС с носителем c файловой системой FAT32. На котором пусть будет крупный файл (например видео).
При удалении этого файла ОС удалит цепочку занимаемых кластеров из обеих копий таблиц, в директории, где была файловая запись проставит 0xE5 вместо первого байта имени файла. Непосредственно сами данные эта процедура не тронет.
Для NAND контроллера сначала поступит запрос на чтение группы секторов содержащий таблицы FAT и директорию (как правило это весьма небольшое количество блоков).
Следом поступят запросы на перезапись подобного или чуть меньшего объема (зависит от того как именно реализован драйвер, нормальный драйвер не будет предлагать переписывать содержимое таблиц, которое не изменилось).
После этой операции микропрограмма NAND контроллера USB Flash даже не подозревает о том, что огромное количество блоков занимаемых удаленным файлом теперь стали свободными (в случае SSD именно TRIM информирует об освобожденных LBA диапазонах). Эти блоки остаются включенными в трансляцию и по прежнему предоставляют те данные, которое они содержат.
Это утверждение легко проверить. Запишите на USB flash файл, сделайте с помощью WinHex образ. После удалите и опять сделайте образ. И сравните двай файла. Изменения будут только в элементах файловой системы, а в области данных никакой очистки не будет в накопителе без TRIM.
Так вот в случае накопителей, где нет обратной связи с ОС в принципе нет «мусора» (большого количества блоком с очень маленьким заполнением, который бы можно было срастить в одиночный, для более эффективной работы механизма выравнивания износа.)
Как я уже писал в одном комментарии, то можно взглянуть на одну из моих публикаций, где немного описан алгоритм NAND контроллера в USB flash
обратите внимание, что я комментировал и указал про исправную память с малым износом. Для того, чтобы SSD или USB flash для пользователя превратились в кирпич достаточно, чтобы транслятор, который записан в тот же NAND перестал читаться. Вероятность попадания транслятора на изношенный блок достаточно высока, так как он постоянно модифицируемый в процессе работы накопителя. Но если в таком умершем накопителе выпаять NAND память, получить дампы, то как правило выясняется, что реальных потерь данных не так уж и много, разумеется если произвести корректную сборку с учетом многих нюансов алгоритмов.
Как бы после чтения «медленных» файлов при второй попытке получите такие же результаты чтения.
Правда существенное торможение еще может быть при чтении неустойчиво читающихся кусках транслятора (не забываем о том, что MCU весьма скромный размер ОЗУ и в некоторых случаях держать полный транслятор недопустимая роскошь). И вот в этом случае, если по какой-то причине микропрограмма перепишет заново транслятор или его проблемную часть можно ожидать оживления накопителя.
Будут работать накопители и без GC и прекрасно работали. Естественно алгоритмы ротации при большом заполнении статически данных становились менее эффективным. С учетом многократного падения надежности NAND памяти c переходом от SLC к MLC, TLC, QLC начали разработки микропрограмм которые могли бы более эффективно размещать данные, дабы большее число блоков участвовало в ротации, ради того, чтобы емкие устройства с дешевой памятью жили несколько больше. Так как микропрограммы контроллеров понятия не имеют в подавляющем большинстве о файловых системах используемых на накопителях, то взаимосвязь с хостом организована посредством TRIM, где контроллер NAND накопителя от хоста получает информацию об LBA диапазоне из логического пространства, который стал свободным от данных (как именно можно прочесть в АТА стандарте на t13.org). Далее эти места транслируются нулями, а микропрограмма контроллера ведет уже анализ какие блоки можно очистить целиком и можно ли собрать из блоков с малым заполнением какой-либо один блок-апдейт для трансляции. В случае конкретно USB flash и карт памяти речи о TRIM не шло и соответственно алгоритмы GC в принципе не закладывались в микрокод, в отличие от SSD.
Вся трансляция, что в картах памяти, что в USB flash, что в SSD работает без участие ОС. ОС компьютера в принципе не имеет представление о том с каким контроллером она работает и сколько микросхем NAND памяти у контроллера, как организован интерлив между ними, синхронный ли он, какого размера блоком оперирует контроллер и т.п. Для ПК это просто накопитель с которым можно работать по определенному протоколу с использованием команд описанных в стандарте. Для ПК доступен лишь LBA диапазон реализуемый устройством, и вся работа ПК с носителем сводится на уровне RW операций. С появлением TRIM лишь чуть-чуть добавилось передаваемых параметров, но ОС так и не получила какой-либо взаимосвязи с алгоритмами NAND контроллеров.
Если подразумевалось именно активность микропрограммы накопителя только лишь при подачи питания и отсутствия коммуникации с хост-контроллером, то в случае USB flash в подавляющем случае ждать попросту нечего по очевидным причинам. Вряд ли кто-то будет писать микропрограмму со сложным анализом расположения данных, когда эффективность этих алгоритмов без того же TRIM будет сводиться к почти нулю. Так как микропрограмма устройства в принципе ничего не знает о файловой системе на нем и лишь обслуживает RW операции. И без сообщения мест которые стали чистыми ей попросту неизвестно, что можно подчищать.
При исправной не изношенной NAND памяти сносного качества не так и быстры процессы естественной деградации. Хватает в запасе NAND микросхем, которые уже хранятся не один год и при перечитывании в ридерах PC3000flash или Nand Reader (софт-центр) отдают дампы в которых можно скорректировать битовые ошибки. Но надо отметить, что с каждым годом хранения количество ошибок растет. Многие уже без Read Retry и манипуляций с напряжением нереально прочесть с приемлемым качеством дампа. В условиях живых USB flash мы как правило наблюдаем, что флешка пролежавшая несколько лет читается заметно медленнее и при чтении даже линейно расположенных данных наблюдаем провалы в скорости (из-за того, что контроллеру приходится проводить больше процедур перечитки микросхем и выше накладные расходы на коррекцию битовых ошибок) В случае флешки, где есть изношенные участки памяти (и они включены в трансляцию) такое проявление мы заметим намного быстрее. А если блоки со служебными данными (с тем же транслятором) попадут на изношенный блок, то и вовсе есть риски, что флешка может и не стартануть.
учитывая, что ОС не имеет представления о фактическом расположении данных в NAND микросхемах, то дефрагментация ее средствами во многих случаях не будет полезной, а скорее будет просто множеством пустых RW операций сокращающих срок жизни устройства.
Начнем с простого, что не стоит все списывать систему трансляции и ее нужды. Разница в емкости в первую очередь продиктована разными единицами измерения.
Гигабайт — это 1 000 000 000 байт
Гибибайт — это 1 073 741 824 байт
Накопитель емкостью 32 гигабайта 32 000 000 000 байт.
32 000 000 000 / 1 073 741 824 = 29,8 гибибайта.
В принципе невозможная ситуация, чтобы не было блоков для записи при наличии свободного пространства в логическом диапазоне.
Как-то немного затрагивал алгоритм работы одного из NAND контроллеров используемых в USB flash .
Если кратко, то в логическом банке число включаемых блоков в трансляцию всегда меньше количества блоков. Всегда есть полностью свободные блоки. Это можете увидеть из материала моей публикации.
Возможны разные подходы при записи данных в зависимости от их объема.
1) в одном случае дополнение данных в блоке будет как чтение блока в буфер, внесение изменений в данные, выбор блока в банке с наименьшим числом записей и запись изменнного содержимого в новый блок, очистка старого блока.
2) при мелких дополнениях некоторые фирмвари не спешат переписывать большие объемы данных и формируют блоки-блоки апдейты, которые отдельными страницами накладывают на логическую трансляцию (т.е. точечные подмены при трансляции для страниц разных блоков)
Конечно можно делать различные предположения о выравнивании износа и перезаписях старых блоков. Но есть много «НО», которые дадут поле для размышления.
В флешках нет элемента питания и нет внутренних «часов», контроллер не имеет представления были данные записаны год назад или вчера. Через протоколы передачи данных с хостом не предусмотрен запрос времени и даты у компьютера. Поэтому реализовать просто перезапись «старых данных» в принципе не представляется возможным.
Основное выравнивание износа по факту происходит при изменении данных, что достаточно неплохо видно по материалам моей публикации. Отсюда зачастую и наблюдаем, что убитые накопители с NAND flash были заполнены статичными данными, а активное изменение шло в небольшой области, что привело к тому, что не так много блоков участвовало в ротации (имеется в виду, те что включены в трансляцию и подвергались изменению и блоки вне трансляции)
Алгоритмы «сбора мусора» — это попытка найти блоки с малым заполнением в NAND накопителях, чтобы сформировать блоки со смешанным содержимым (блок-апдейты), которые странично или группами страниц накладываются в трансляцию. Но для реализации этого алгоритма контроллеру нужна обратная связь с ОС. т.е. при удалении должны сообщаться LBA диапазоны, которые микропрограмма оттранслирует к конкретным блокам. Технология например для SSD и SMR HDD существует и называется TRIM. А много ли вы сможете найти USB flash с поддержкой TRIM?
Для начала стоит отметить, что если страница не прочиталась, то в принципе контроллер не отдаст каких либо данных. При нечитаемой странице вы получите ошибку чтения и пустой буфер, а не искаженные данные в нем. Всякие половинчатые фотографии это чаще следствие ошибок файловой системы, перекрестные записи, искажение данных при в буферном ОЗУ микроконтроллера, а также различные ошибки в трансляции, когда вместо данных транслируется мусор. Но эти явления в большинстве своем не связаны с естественной деградацией самой NAND памяти и ее содержимого.
Процедуры перестроения трансляции при простое могут быть реализованы в некоторых микропрограмма USB flash, но исходя из вопросов выше вряд ли они такие, как себе представляет автор. Также наличие процедур оффлайн сканирования во многих микропрограммах USB flash опять же под большим вопросом. В итоге рекомендация включать USB flash с поданными на них постоянными 5В не кажется однозначно полезной.
в связи с этим вопрос как набрать цифру 1? Или легкое перемещение диска чуть менее 1мм и будут фиксироваться как ввод единицы?
Трос фигурировал в предыдущих комментариях. Вероятно для упрощения описания задачи. Очевидно, что изначально протягивается что-то тонкое и максимально легкое, способной выдержать процедуру протяжки троса. Но даже 4 мили нити это не такая и маленькая масса для машинки или животного. У животного очевидно больше преимуществ в плане проходимости.
Также далее в комментарии предлагается использовать машинку и добавить к ней 4 мили провода, который будет иметь вес заметно больший, чем вес нити, что сделает невозможным использование маленькой машинки.
Машинки побольше вряд ли можно сделать такими, чтобы они после себя не оставили лишней трудноудалимой грязи.