Чи можуть дані на жорсткому диску погіршуватися без попередження Windows, що це сталося під час спроби отримати доступ до даних?

Чи ймовірно, що фізична деградація жорсткого диска може призвести до того, що біти можуть "перевернути" вміст файлу без "зауваження" ОС та повідомити про це під час читання файлу? наприклад, чи може "p" у текстовому файлі ASCII (двійковий 0111000 0 ) змінитися на "q" (0111000 1 ), і тоді користувач (я) зможе відкрити файл і побачити "q", не усвідомлюючи, що невдача сталося?

Мене цікавлять відповіді, що стосуються FAT, NTFS або ReFS ... якщо це має значення.

Я хочу знати, чи захищає мене ОС від цього, чи потрібно перевіряти мої дані на інваріантність між копіями / з часом.

Так , є річ, яка називається біт гниття.

Але ні , це не вплине на вас непомітно.

Коли накопичувач записує сектор на платівки, він не просто записує біти так само, як вони зберігаються в оперативній пам'яті - він використовує кодування, щоб переконатися, що немає занадто довгих послідовностей того ж біта. , і він додає коди ECC, які дозволяють йому виправляти помилки, що впливають на кілька біт, та виявляти помилки, що стосуються більше кількох біт.

Коли накопичувач читає сектор, він перевіряє ці ECC-коди та відновлює дані, якщо це необхідно і можливо. Що буде далі, залежить від обставин та мікропрограми накопичувача, на яку впливає позначення накопичувача.

• Якщо сектор може бути прочитаний і не має проблем з ECC, він передається в ОС
• Якщо сектор можна легко відремонтувати, відремонтовану версію можна записати на диск, прочитати назад та перевірити, щоб визначити, чи помилка була випадковою (космічні промені ...) чи є систематична помилка із носієм
• Якщо накопичувач визначає помилку з носієм, він перерозподіляє сектор
• Якщо сектор не можна ні прочитати, ні виправити після декількох спроб читання, на диску, призначеному для RAID-накопичувача , привід відмовиться, перерозподілить сектор та скаже контролеру, що виникла проблема. Він покладається на контролер RAID, щоб він реконструював сектор з інших членів RAID і записував його назад на збій диска, який потім зберігає його у перерозподіленому секторі, що, сподіваємось, не має проблеми.
• Якщо сектор не можна прочитати чи виправити на настільному диску , він буде робити набагато більше спроб його прочитати. Залежно від якості накопичувача, це може включати перестановку головки, перевірку чи є біти, які перегортаються при повторному читанні, перевірка, які біти є найслабшими, та кілька інших речей. Якщо будь-яка з цих спроб вдасться, накопичувач перерозподіляє сектор і запише відремонтовані дані.

(Це одна з головних відмінностей між накопичувачами, які продаються як "Настільні", "NAS / RAID" або "Відеоспостереження"). Привід RAID може просто швидко відмовитися і змусити контролер ремонтувати сектор, щоб уникнути затримок на Пристрій настільного комп’ютера буде повторюватися знову і знову, тому що вимагати того, щоб користувач почекав кілька секунд, це, мабуть, краще, ніж повідомляти їм, що дані втрачені. мене навіть не помітять.)

У будь-якому випадку, накопичувач буде знати, чи не було гниття, як правило, відновиться після цього, і якщо він не зможе, він скаже контролеру, який в свою чергу скаже драйверу, який скаже ОС. Потім ОС залежить від того, щоб представити користувачеві цю помилку та діяти на ній. Ось чому говорить кібернард

Я ніколи не був свідком жодної бітової помилки, але я бачив багато жорстких дисків, де цілі сектори вийшли з ладу.

привід буде знати, що з сектором щось не так, але він не знає, які біти вийшли з ладу. (Один єдиний біт, який не вдався, завжди буде спійманий ECC).

Зауважте, що chkdsk та автоматично ремонтує файлові системи не стосуються повторної обробки даних у файлах. Вони спрямовані на корупцію в структурі файлової системи; як розмір файлу, який відрізняється між записом каталогу та кількістю виділених блоків. Функція самолікування NTFS виявить структурні пошкодження та запобіжить їх подальшому впливанню на ваші дані, вони не відновлять жодних пошкоджених даних.

Звичайно, є й інші причини, через які дані можуть пошкодитися. Наприклад. погана оперативна пам’ять на контролері може змінити дані, перш ніж вона навіть надсилається на накопичувач. У такому випадку жоден механізм на диску не виявить або відновить дані, і це може бути однією з причин пошкодження структури файлової системи. До інших причин відносяться звичайні помилки програмного забезпечення, затемнення під час запису на диск (хоча це вирішується журналом файлової системи) або погані драйвери файлової системи (драйвер NTFS в Linux довгий час був дефолт для читання, оскільки NTFS був спроектований реверсом, не задокументований , і розробники не довіряли власному коду).

У мене був такий сценарій одного разу, коли програма зберігала всі свої файли на двох різних серверах у різних центрах обробки даних, щоб зберегти робочу копію, якщо дані за будь-яких обставин. Через кілька місяців ми помітили, що в одній із копій приблизно 0,1% усіх файлів не відповідають сумі MD5, яку додаток зберігав у своїй базі даних. Виявився несправний волоконний кабель між сервером та SAN.

Ці інші причини - чому деякі файлові системи, наприклад ZFS, зберігають додаткову інформацію контрольної суми для виявлення помилок. Вони створені, щоб захистити вас від набагато більше речей, які можуть піти не так, ніж просто гниття.

Так, жорсткі диски можуть і деградувати без попередження з ОС. Це називається бітова гниль . Я ніколи не був свідком жодної бітової помилки, але я бачив багато жорстких дисків, де цілі сектори вийшли з ладу.

У Windows немає вбудованого захисту вмісту файлу, що не відповідає структурі файлової системи NTFS. Подумайте про NTFS як про книгу: добре, вона лише захищає зміст і перевіряє, що все відповідає. Однак якщо збиток знаходиться в середині сторінки, він не забезпечує захисту. В FAT немає нічого. Жорсткі диски використовують виправлення помилок ECC на кожній секторі, але він не повідомляє Windows. У деяких типах файлів спеціально є хеші CRC, MD5 або SHA для виявлення корупції, але вони нічого не виправляють .

Навіть тоді хеш говорить лише про те, що є проблема, але він не знає, де знаходиться помилка.

На жорсткому диску є SMART, який стежить за станом жорсткого диска, але, якщо диск не знаходиться у дверях смерті, BIOS не попередить вас. Найгірше, але SMART часто відключається у вашому BIOS. Ви можете контролювати номери за допомогою програмного забезпечення, але різні диски мають різні проблеми. Якщо у вас є маса переселених секторів, або ваші помилки ECC постійно збільшуються. Якщо у вас є 100 000 нових ECC щодня, це поганий знак.

Багато типів файлів не мають захисту від бітової гнилі . Мовляв, TXT і BMP, які взагалі не мають захисту. Winrar має необов'язковий варіант додавання даних паритету до архіву, що зробить файл більшим, але він може виявити (пропорційно кількості доданих даних про паритет) та виправити подібну помилку.

Усі інші програми стиснення, про які я знаю, виявляють помилки, але безпорадні нічого з цим робити.

Зрештою, помилки в секторі будуть настільки поганими, що ECC не може виправити це, і привід дасть вам прочитане, навіть якщо воно невірно.

Ви можете використовувати QuickPar або подібні для створення файлів даних про парність, але, наскільки я знаю, немає можливості його автоматизувати. Наприклад, ви фактично самі змінюєте файл, коли вам доведеться вручну оновити паритет. Ви також можете мати дані парності для групи файлів, але ви зміните 1 файл, і весь набір парності повинен бути відтворений. Це справжній головний біль для всіх, але невелика кількість файлів.

Так, можливо. Windows - це лише програмне забезпечення. Програмне забезпечення - це низка інструкцій, якими слід керувати комп’ютер.

Подумайте про інший тип серії інструкцій: книгу. Що можуть зробити ці вказівки, якщо вони написані в книзі, яка сидить на полиці, і ніхто не заважає відкрити книгу і прочитати ці вказівки?

Так само, як ці письмові інструкції вимагають від людини прочитати інструкції та почати слідувати цим інструкціям, комп'ютерне програмне забезпечення вимагає обладнання, щоб зробити речі корисними. Навіть якщо у книзі є інструкції, написані з казковою точністю, це не запобігає проблемам, якщо людина вирішить прочитати інструкції, але потім виконати їх неправильно. Аналогічно, програмне забезпечення не може перешкодити апаратним засобам робити погані речі. Таким чином, зламане обладнання може фізично перемогти над тим, що може робити будь-яка частина програмного забезпечення, включаючи Microsoft Windows.

Тепер ReFS може бути розроблений з наміром, що програмне забезпечення буде зберігати дані про дані, а потім програмне забезпечення може порівняти ці дані. Просте поняття - "контрольна сума", де програмне забезпечення додає певні значення та гарантує, що ці значення відповідають очікуваному результату. Якщо апаратне забезпечення реалізує це програмне забезпечення, то можуть бути виявлені певні погані результати. Це навіть може бути дуже імовірним. Однак, оскільки кількість потенційних проблем, які теоретично можуть існувати, є в основному нескінченним числом, немає гарантії, що програмне забезпечення обов'язково виявить кожну проблему. (Майте на увазі, що програмне забезпечення - це низка інструкцій, створена достроково.)

FAT особливо низький. FAT12 був розроблений для дискети, а FAT16 для систем об'ємом до 4 Гб (хоча більшість реалізацій Майкрософт FAT16 прагнув не працювати вище 2 ГБ). Без розширення VFAT жоден з них не підтримував імена файлів довше 11 символів (деякі з них були б у частині, що називається "розширення"). FAT був просто розроблений для зберігання даних у той час, коли можливість зберігання даних була новою концепцією, про яку потрібно навчати дорослих. Коли FAT вважався «передовою» технологією, комп’ютерна техніка ще не була достатньо поширеною і розробленою, щоб люди могли переживати за розширені можливості.

NTFS додала підтримку ще декількох функцій, можливо, найбільше того, що операційна система змогла легко відслідковувати дозволи користувачів. Існують різні версії NTFS. Наприклад, Moab вказує, що Windows Server 2008 додав підтримку самолікування NTFS, яка може виявити деякі речі. Тим не менш, ця функція була новою для Windows Server 2008, тому вона зовсім не щось підтримується Windows XP (або Windows Server 2003, або раніше). Навіть все ж, переглядаючи перелік функцій, виявляється, що це стосується деяких метаданих, які допомагають операційній системі помітити проблеми, настільки серйозні, що диск не може встановити, або інші ключові області диска, які впливають на ядро ​​операційної системи. Це виглядає не так, як кожен окремий фрагмент даних, у кожному файлі, впливає ця одна особливість.

Програмне забезпечення для таких операційних систем навряд чи помітить подібні речі, якщо вони не спричинить помітних проблем для виконання операційної системи. Можуть бути деякі винятки, як, наприклад, частини операційної системи, які перевіряють диски (CheckDsk / ChkDsk / ScanDisk / ScanDskW, залежно від операційної системи), але навіть вони будуть досить обмежені у тому, що вони можуть виявити, значною мірою тому, що файлові системи не мають не зберігайте дуже великий обсяг даних, який повинен був бути корисним для перевірки диска.

(RAID5 може виявляти більш схильний до виявлення таких речей. Кожен біт має біт парності, який допоможе помітити щось незвичне. Навіть тоді було б реалізація RAID запустити перевірку, щоб помітити проблему. Якщо проблема виникла на частина диска, з якою активно не працює, проблема може залишитися непоміченою, поки хтось не спробує почати використовувати ці дані.)

У більш пізні часи більша кількість бітів означала, що невелика ймовірність, як, наприклад, "1 на 10 мільйонів", скоріше вплине на речі. Широка громадськість також дізналася про "космічні промені", які можуть мати невеликий вплив на речі. Оскільки біти стискаються настільки щільно в нових пристроях, фізичні вимоги до зображення трохи менше, тому навіть невеликі впливи швидше псуються з тим, як розпізнається біт. ReFS має деякі функції, розроблені для того, щоб допомогти виявити їх. У статті Вікіпедії про ReFS йдеться про це як "автоматичну перевірку цілісності". Оскільки це описано як помітну особливість цієї файлової системи, такі функції, швидше за все, більш розвинені, ніж у NTFS (і, звичайно, більше, ніж FAT, що було порівняно просто,