Могут ли данные на жестких дисках ухудшаться без предупреждения о повреждении?
Мы все беспокоимся о том, чтобы сохранить наши данные и файлы в целости и сохранности, но возможно ли, что данные будут повреждены и будут доступны пользователю без какого-либо уведомления или предупреждения о проблеме? Сегодняшний пост SuperUser Q & A содержит ответ на вопрос взволнованного читателя..
Сегодняшняя сессия вопросов и ответов пришла к нам благодаря SuperUser - подразделению Stack Exchange, группе веб-сайтов вопросов и ответов, управляемой сообществом..
Фото любезно предоставлено обобщением (Flickr).
Вопрос
Читатель SuperUser topo morto хочет знать, могут ли данные на жестких дисках испортиться и получить доступ без предупреждения о повреждении:
Возможно ли, что физическая деградация жесткого диска может привести к тому, что биты «перевернутся» в содержимом файла, при этом операционная система не заметит изменения и не уведомит об этом пользователя при чтении файла? Например, может ли «p» (двоичный 01110000) в текстовом файле ASCII измениться на «q» (двоичный 01110001), тогда, когда пользователь открывает файл, он видит «q», не зная, что произошла ошибка?
Я заинтересован в ответах, касающихся FAT, NTFS или ReFS (если это имеет значение). Я хочу знать, защищают ли операционные системы пользователей от этого, или мы должны проверять наши данные на различия между копиями с течением времени.
Могут ли данные на жестких дисках ухудшаться и быть доступны без предупреждения о повреждении?
Ответ
Участник SuperUser Гунтрам Блом имеет ответ для нас:
Да, есть вещь, называемая немного гнилой. Но нет, это не повлияет на пользователя незаметно.
Когда жесткий диск записывает сектор на жесткие диски, он не просто записывает биты так же, как они хранятся в ОЗУ, он использует кодировку, чтобы убедиться, что нет последовательностей того же бита, которые являются слишком длинными. Он также добавляет коды ECC, которые позволяют исправлять ошибки, затрагивающие несколько бит, и обнаруживать ошибки, затрагивающие более нескольких бит..
Когда жесткий диск читает сектор, он проверяет эти коды ECC и восстанавливает данные, если это необходимо (и, если возможно,). Что будет дальше, зависит от обстоятельств и встроенного программного обеспечения жесткого диска, на которое влияет его назначение..
- Если сектор может быть прочитан и у него нет проблем с кодом ECC, он передается операционной системе..
- Если сектор может быть легко восстановлен, восстановленная версия может быть записана на диск, прочитана обратно, а затем проверена, чтобы определить, была ли ошибка случайной (то есть космические лучи и т. Д.) Или есть систематическая ошибка с носителем.
- Если жесткий диск определяет ошибку носителя, он перераспределяет сектор.
- Если сектор не может быть ни прочитан, ни исправлен после нескольких попыток чтения (на жестком диске, который обозначен как жесткий диск RAID), тогда жесткий диск сдается, перераспределяет сектор и сообщает контроллеру, что возникла проблема , Он использует контроллер RAID для восстановления сектора из других участников RAID и записи его обратно на неисправный жесткий диск, который затем сохраняет его в перераспределенном секторе (который, как мы надеемся, не имеет проблем).
- Если сектор не может быть прочитан или исправлен на жестком диске настольного компьютера, то на жестком диске будет больше попыток его прочитать. В зависимости от качества жесткого диска, это может включать в себя изменение положения головки, проверку на наличие битов, которые переворачиваются при повторном чтении, проверку, какие биты являются самыми слабыми, и некоторые другие вещи. Если любая из этих попыток удастся, жесткий диск перераспределит сектор и запишет восстановленные данные.
Это одно из основных различий между жесткими дисками, которые продаются как «настольные», «NAS / RAID» или «видеонаблюдение». Жесткий диск RAID может просто быстро сдаться и заставить контроллер восстанавливать сектор, чтобы избежать задержки на стороне пользователя. Настольный жесткий диск будет продолжать попытки снова и снова, потому что пользователь подождет несколько секунд, вероятно, лучше, чем сообщить им, что данные потеряны. И видео жесткий диск оценивает постоянные скорости передачи данных больше, чем восстановление после ошибок, поскольку поврежденный кадр обычно даже не заметят.
В любом случае, жесткий диск будет знать, была ли гниль, как правило, восстановится после него, и если он не сможет, он сообщит контроллеру, который, в свою очередь, сообщит драйверу, который затем сообщит операционной системе. Затем операционная система должна представить ошибку пользователю и действовать в соответствии с ней. Вот почему кибернард говорит:
- Я никогда не был свидетелем ни одной ошибки, но видел множество жестких дисков, на которых не работали целые сектора..
Жесткий диск будет знать, если что-то не так с сектором, но он не будет знать, какие биты вышли из строя. Один бит, который потерпел неудачу, всегда будет перехвачен ECC.
Обратите внимание, что chkdsk и файловые системы, которые автоматически восстанавливают сами себя, не решают проблему восстановления данных в файлах. Они нацелены на повреждение в структуре самой файловой системы, как разница в размере файла между записью каталога и количеством выделенных блоков. Функция самовосстановления в NTFS обнаружит структурное повреждение и предотвратит дальнейшее воздействие на ваши данные, но не восстановит уже поврежденные данные.
Конечно, есть и другие причины, по которым данные могут быть повреждены. Например, сбой ОЗУ на контроллере может привести к изменению данных до того, как они будут отправлены на жесткий диск. В этом случае никакой механизм на жестком диске не будет обнаруживать или восстанавливать данные, и это может быть одной из причин, почему структура файловой системы повреждена. Другими причинами являются ошибки программного обеспечения, отключение при записи на жесткий диск (хотя это устраняется журналированием файловой системы) или сбой драйверов файловой системы (драйвер NTFS в Linux долгое время оставался доступным только для чтения, так как NTFS был подвергнут обратному проектированию, не документировано, а разработчики не доверяют собственному коду).
- У меня был такой сценарий, когда приложение сохраняло все свои файлы на двух разных серверах в двух разных центрах обработки данных, чтобы рабочая копия данных была доступна при любых обстоятельствах. Через несколько месяцев мы заметили, что около 0,1 процента всех скопированных файлов не соответствуют контрольной сумме MD5, которую приложение хранит в своей базе данных. Оказалось, что неисправен оптоволоконный кабель между сервером и SAN.
Эти другие причины - то, почему некоторые файловые системы, такие как ZFS, хранят дополнительную информацию контрольной суммы, чтобы обнаружить ошибки. Они разработаны, чтобы защитить вас от гораздо большего, что может пойти не так, как гниение.
Есть что добавить к объяснению? Отключить звук в комментариях. Хотите узнать больше ответов от других технически подкованных пользователей Stack Exchange? Ознакомьтесь с полным обсуждением здесь.
