| 0
- 21.08.2019 - 11:47
|
День добрый! Кто-то разбирается в жестких, подскажите, пожалуйста! Может ли на HDD или SSD повредиться файл, так что я об этом не узнаю? Например, появится бэд или еще какой косяк в том месте, где файл записан. Я скопирую файл, а он окажется испорченным. Если так, то архивирование информации на другой носитель не дает гарантий. Прошу прощения за такой простой вопрос, просто сейчас для работы придется делать архивные копии очень большого количества файлов (на USB HDD), и не хотелось бы, чтобы они повредились, а я случайно узнал об этом, только когда придется восстанавливать эти файлы с внешнего HDD, открывать их, и они окажутся испорченными, а другой архивной копии не будет. Ну или файл повредится на основном HDD, и я скопирую на архивный уже испорченную версию.     | | |||
| 1
- 24.08.2019 - 10:38
| я бакаплю ежедневно на железки (автоматом) плюс раз в неделю (вручную выборочно) на яндекс облако там сто рублей террабайт или около того | | |||
| 2
- 25.08.2019 - 18:45
| Было однажды что жопеги на диске попортились. Несколько файлов всего. Узнал потом случайно. Ошибок чтения не было, так по бэкапам они битые и расползлись. Диск тот работал с перегревом. В нормальных условиях такое в теории тоже вероятно, но не встречал. Поэтому для ценной информации нужно как минимум 2 бэкапа + архивы. | | |||
| 3
- 26.08.2019 - 08:29
| Цитата:
| | |||
| 4
- 26.08.2019 - 09:43
|
3-no_name > Это разве не очевидно? У вас наверное ещё ssd не подыхали? При критической поломке диска можно будет восстановить весь комп за полчаса. Ежедневно (ну или еженочно) бекапятся только изменения. wbadmin ковыряйте - там всё просто. Ежу понятно, ежели у вас фотоархив (или чтонибудь такое) то проще залить всё на облако или на носитель и никогда не доставать | | |||
| 5
- 26.08.2019 - 10:58
| Володик, ответ по вопросу в вашей теме: комп при считывании проверяет целостность данных, и если файл считался то на источнике он точно не повреждён. Проверка записанной на резервный диск информации может проводится, а может и нет. На это надо смотреть при настройке программы резервного копирования. | | |||
| 6
- 26.08.2019 - 14:16
| 5-Еще год на этом форуме > не всегда ошибки контрольной суммы обнаруживаются, поэтому есть шанс получить кривой файл во всех бэкапах. | | |||
| 7
- 27.08.2019 - 13:26
| Интересно... Если есть еще какие советы по созданию архивов на внешних HDD в домашних условиях, напишите. | | |||
| 8
- 27.08.2019 - 18:36
|
7-Volodik > Не впадай юноша в ПАРАНОЮ Просто делай бекапы как ты считаешь нужным в зависимости от важности даты | | |||
| 9
- 28.08.2019 - 18:55
| Смотря что у тебя за данные. По классике, архивируется первичка (исходники) на read-only носители (диски, ленты). Потом они обрабатываются, делаются копии оперативного бекапа по необходимости (например в конце дня) поочередно на 2 разных носителя. Потом когда обработка завершена, делается бэкап результата одновременно с архивом. Так, по крайней мере, у тебя будет первичка. Если же речь идёт только об оперативных данных без первички (прямой ввод с клавиатуры, например), то делать множество бекапов с определенным интервалом. Количество и интервалы определяются ценностью информации. Если не ценная, то надежности накопителей хватает, чтобы вообще не делать бекапы. | | |||
| 10
- 29.08.2019 - 15:56
| Цитата:
| | |||
| 11
- 30.08.2019 - 01:49
| Цитата:
| | |||
| 12
- 30.08.2019 - 16:34
| Самой частой причиной ситуации с ошибками резервных копий являются сбои памяти! Файл скачивается в память при резервном копировании, и только оттуда переносится на резервный носитель! Разумеется, ни каких "контрольных сумм" при считывании из кэша не проверяется... | | |||
| 13
- 30.08.2019 - 20:11
| не делаю бэкапы вообще. | | |||
| 14
- 31.08.2019 - 10:24
| 12-As > а как же ECC? Если речь зашла о бекапах, разумеется, мы наверное говорим о сколь-либо приличном оборудовании, а не о ноутбуке из ближайшего магазина «все для быта». | | |||
| 15
- 31.08.2019 - 14:38
| Цитата:
Если речь о сообщении Rat, очевидно, что он не понимает что такое хэш-функция. Так же очевидно, присутствующие не совсем понимают как устроена весьма отказоустойчивая ntfs. | | |||
| 16
- 01.09.2019 - 01:52
| Цитата:
И любой юзер просто НАДЕЕТСЯ на то что забэкапленый им файл был правильно перенесен с одного носителя на другой. Цитата:
Ведь как исходно поставлен вопрос? Цитата:
Возьмем на пример вот это фото  А сотворили с ним такое всего-навсего 4 поврежденных 4-х килобайтных сектора - 16 384 байта из 2 858 794 байт содержимого файла, чуть больше чем 0,5% от его объема. И при этом файл по прежнему великолепно читается средствами "отказоустойчивой NTFS" и великолепно переносится куда угодно, в том числе и в интернет-облака, белогривые лошадки. Но можно ли считать такой файл ЦЕЛЫМ? | | |||
| 17
- 01.09.2019 - 10:56
| Цитата:
Цитата:
Про отказоустойчивость ntfs я просто указал что кто-то писал про ошибки в момент выключения напруги. Про Rat я указал что про "ошибки контрольной суммы" - "вероятность исчезающе мала" на деле её "физически просто не может быть", ибо хешфункция это такая крутая штука, вобщем сами разберётесь. Хотя ECC и хэш это конечно не одно и тоже, простите мой косяк, ECC это полином, который ещё и пытается восстановить данные при расхождении записанного и считаного кода, но в целом думаю понятно. | | |||
| 18
- 01.09.2019 - 11:20
|
хм, я не совсем внимательно прочитал пост 16, там пугаете молодёжь BADом? Ситуация когда контроллер сталкивается с несоответствием контрольных кодов чтения и записи это отдельная и большая тема. Но то что производители и разработчики втихаря от пользователя ремапят сектора и повреждённые файлы выдают как целые мне кажется сильно натянутой историей | | |||
| 19
- 01.09.2019 - 11:59
| Цитата:
Так что наивная уверенность в том что "если файл читается то он в порядке" исходит именно из того что кое-кто не понимает принципиальной разницы между ЕСС файла и ЕСС сектора у накопителя. Я показал конкретный пример файла, в котором накопитель вывел из обращения и заменил на резервные 4 сектора - два поряд с 74000(Н) по 75FFF(H) и два подряд с 29F000(H) по 2AFFFF(H). Поскольку у конкретного накопителя сектора имели размер 4 килобайта то суммарно заремаплено 16 384 байта - что изменило КОНТРОЛЬНУЮ СУММУ САМОГО ФАЙЛА. Но не повлияло на возможность прочитать этот файл с накопителя, поскольку с точки зрения ОС все сектора имевшие отношение к файлу успешно считаны. Цитата:
| | |||
| 20
- 01.09.2019 - 13:15
| 19-Wlad > | | |||
| 21
- 01.09.2019 - 13:28
|
Я вот не уверен, но по-моему вы не правы. При офлайн сканировании, сектор с которого всеми физическими способами вычитка невозможна ставится во временный дефект-лист и всё, точка. Пока тот файл...СЕКТОР не понадобится для чего-нибудь хосту. Вот тогда и будут реализовываться дальнейшие сценарии. Вы же утверждаете если я правильно понял, что микрокод контроллера замаскированно ремапит UNC сектора, произведя деструктивные действия в отношении ОС. Полагаю это запрещено всеми логиками всех производителей. | | |||
| 22
- 02.09.2019 - 02:37
| Цитата:
Цитата:
В общем, не нужно обольщаться и выдавать желаемое Цитата:
Итак, юзеру стоит принять за данность что его данные производителю харда по барабану, и у производителя совсем другие интересы - и первый из них МИНИМИЗИРОВАТЬ КОЛИЧЕСТВО ВОЗВРАТОВ НАКОПИТЕЛЕЙ ПО ГАРАНТИИ. Поэтому система внутренней самодиагностики накопителя заточена именно на это, а не на то чтобы уберечь пользовательские данные. Ну и еще один веселый момент: на производителя работает статистика больших чисел. В том же терабайтном накопителе имеется почти два миллиарда секторов по 512 байт - ну подумаешь, сотня-две из них перестали читаться и находящиеся там данные утратились! Часть секторов попадет в незанятое место, часть в занятое бесполезными и не влияющими на работоспособность системы данными, часть в файлы которые заменяются операционной системой, как на пример системные dll замещаемые при повреждении из dll-cash. Часть угодит в аудио-видеофайлы, где на один поврежденный сектор в 99,99999% случаев посрать и розами засыпать и о том что в кинухе "имеются повреждения" никто никогда не подумает. Часть угодит в файлы обладающие большого уровня избыточностью, на пример в те же изображения в Raw, и опять таки останется маленьким белым пятнышком на которое юзеру покласть с посвистом. А те пара-тройка десятков секторов которые попали в те файлы в которых их появление критично, навродя представленного выше jpeg будут в основном кочевать из одного накопителя в другой, пока след откедова они появились не затеряется окончательно и бесповоротно. И обнаружится трабла через пятилетку, и то нежданно-негаданно, когда юзер наконец-то решит посмотреть фотку.... И в любом случае к производителю накопителя юзер не может предъявить претензию - производитель не отвечает за сохранность данных. | | |||
| 23
- 02.09.2019 - 13:23
| Влад, а вас не затруднит в конце каждого невменяемого потока сознания отдельной строкой писать: Резюме - и там десять слов. | | |||
| 24
- 02.09.2019 - 13:34
| Весь прикол в том что описанная ДЫРА появляется в момент изготовления диска, и при первичной разметке такие сектора выводится из работы. При эксплуатации сектор никогда не сдыхает прям нафик сразу, он с первого оборота может не читаться, это да, такие сектора вполне восстановимы аппаратными ресурсами, сдвиг головок, изменение токов чтения, применение есс и тд. Именно подозрительные сектора авторемап и переносит втихоря, изменяя только показатели смарт. А вот совсем-совсем дохлые - маркированные как бэды, без уведомления ОС не переносятся никогда. | | |||
| 25
- 02.09.2019 - 23:52
|
Володя, ты неправ. Ситуация, когда накопитель записал без ошибки данные в сектор, а потом из этого сектора прочитал другие данные также без ошибки - из ряда вон выходящая. Т.е. они, конечно, бывают, сам встречал, например на Самсунгах M8E, когда дефектная поляна читалась очень медленно, но без ошибок, а в секторах были сплошные 00, хотя там должны были быть другие данные. Но, это кривые руки программистов - разработчиков софта накопителя и встречаются такие ситуации крайне редко. Правильно функционирующий накопитель должен или выдать ошибку при операции чтения или записи или отдать верные данные. Ремапиться сектор должен из списка кандидатов при записи или, как твой оппонент писал, нестабильные, но все же читающиеся сектора при внутренних сканах или при удачных операциях чтения. | | |||
| 26
- 03.09.2019 - 01:02
| Цитата:
Цитата:
Цитата:
В том то и замес что для работы с накопителем в формате "юзер обыкновенный" когда никакие методы отключения всех этих дурацких самодиагностических процессов у накопителя невозможно для юзера априори процессы вывода из обращения секторов которые "савсэм мёртвий" и обнаруженных при автоскане все равно происходит, только вот юзер нифига это не понимает. Ну затупил чегось комп, завис, юзер его ребутнул и счастливо продолжил работу. А почему так - темна вода во облацях. Вспомни "волшебные" галки в паспорте Сигеля, и как там вторая сверху строчка называется, та, которая с "А"? И если убрать галку с третьей сверху строки то мы вообще все это Авто "влет" получим, а не в момент новой инициализации харда с соответствующими изменениями в трансляторе. К тому же не будем рассматривать ситуевину когда мы записали файл и тут же к нему обращаемся. Нет, рассмотрим ситуацию именно когда мы файл сбросили на накопитель, а потом к этому файлу никогда не обращаемся, и лезет к нему лишь самодиаг в режиме оффлайн скана. Кратко резюмирую - ситуации с замещением исходных данных ВОЗМОЖНЫ. Редко-часто это в общем то другой вопрос. Главное что они есть, они не могут не есть - и в результате ИНОГДА получается погрызенный файл. | | |||
| 27
- 03.09.2019 - 01:31
| Цитата:
Замещать данные и не уведомить хост о проблеме - нонсенс или же явный баг в фирмваре. Иначе можно докатиться до того, что нафиг нужны эти контрольные суммы, ECC и прочая лабуда. Ну и что, что иногда данные будут не те, зато работать будет быстрее и по гарантии не вернется, пока совсем не умрёт:-) | | |||
| 28
- 03.09.2019 - 12:14
| Цитата:
Причем не один и даже не десять раз была ситуация, когда помимо файлов конкретно битых и занесенных в Problem в виду того что некоторые их сектора были не прочитаны среди вычитанных без ошибок тоже имеет место битое. Как ты это объяснишь, а? С точки зрения "если все прочлось без ошибок то файл целый" нихрена объяснение не вытанцовывается, все прочлось но файл битый! При этом все методы по отключению "автомата" выполнены, то есть заведомо в процессе вычитки тобой уже нихрена не подменялось. То есть какой вывод? А простой и логичный - все | | |||
| 29
- 03.09.2019 - 19:11
|
Вообще-то абсолютно все данные на любые носители, с момента изобретения таковых носителей, пишутся с коррекциями ошибок, а не инфопоток напрямую. Поэтому эти ваши дохлые 512 байт и можно в принципе переназначить куда-то контроллером. С уважением, ваш К.О. | | |||
| 30
- 04.09.2019 - 07:25
| Повторюсь, на вполне живом диске данные в картинках попортились, картинки рассыпались на блоки и перестали быть нормальными картинками. Диск читался, писался, гудел, вращался, в системе определялся и в целом вёл себя как абсолютно живой. Потом он ещё долго работал. Это был какой-то сигейт на 160 гб, кажется. В бэкапе с него, конечно, тоже битые картинки оказались. Никогда ни до, ни после такого не видел. | | |||
| 31
- 06.09.2019 - 12:15
|
сначала происходит вот это: затем происходит вот это:  Всё остальное я хз откуда вы берёте. Уж сколько петабайт данных я перехранил не сосчитать... НИ РАЗУ НЕ ВИДЕЛ битой картинки если её перед этим сервисной программой не прогнать. | | |||
| 32
- 06.09.2019 - 14:56
|
31-Еще год на этом форуме > Полный пипец.... Человече, у тебя походу даже с банальной логикой проблемы! Ты привел скрин Попробуй ПОДУМАТЬ что дальше! Не на уровне дяди Кипящего Чайника, а исходя из внутренней логики работы накопителя. Во первых, исходим из предположения что сектор на котором споткнулся накопитель поврежден настолько что содержащаяся в нем информация не может быть считана, никакие ЕСС не помогают, чтобы не было Цитата:
Но что в первом что во втором варианте в отношении конкретного файла результат монописуален - ФАЙЛ УЖЕ БИТЫЙ. И то что его можно вычитать "после того как" это всего-навсего тонкий намек на ту граблю о которой говорилось выше, а именно ПОЯВЛЕНИЕ БИТЫХ ФАЙЛОВ СРЕДИ ВЫЧИТАННЫХ БЕЗ ОШИБОК. Оно понятно что рассуждения у парадного подъезда исходящие от человеков которые в своей жизни сделали пяток-десяток копий с собственной пары-тройки накопителей вообще не должны приниматься во внимание, но наш благословенный интернет населяют сотни миллионов таких юзверей, а вот тех кто восстанавливал данные с накопителей с проблемами в лучшем случае десток человек на миллион, а тех кто при этом соображает что делает и разбирается в процессах происходящих в накопителе и того меньше. И фигли мне показывать на ? На каком основании Винда выдала эту картинку? Посмотрев показания SMART, нарвавшись на битый файл среди тех которые загружала и который был заменен имеющейся в распоряжении Винды резервной копией? Ну и какое это отношение вообще имеет к пользовательским данным, тем самым которые уникальны и неповторимы в отличии от Винды которую может переустановить любое школоло? Винда своими тупыми мессагами лишь сообщает о том что В ЕЕ РАБОТЕ есть траблы, и пытается пнуть юзверя в каком-то направлении. Но при этом думать Винда естественно не умеет, а реагирует на заложенные при ее написании сценарии. И если сценарий не предусмотрен то юзверь ваще не в курсах о том что у накопителя имеются проблемы - как на пример накопитель в режиме оффлайн скана обнаружил битый сектор, влет заремапил или отложил до перезагрузки с пересчетом трансляции - но Винда о этом ни сном ни духом, поскольку оффлайн скан осуществлялся в тот момент когда с точки зрения Винды накопитель находится В ПРОСТОЕ. В общем, смысл разговора с слепыми о радуге считаю нулевым, и предоставляю им оставаться при собственном мнении о том что их данные в целкости и сохранкости потому что они прочитались... | | |||
| 34
- 10.09.2019 - 09:45
|
Wlad вы уж простите, но читать ваши излияния даже до половины я больше не могу. Однако держите пару тезисов: 1. Ваши "выпады" а каждом посте настолько же наивны насколько и неуместны. Если желаете услышать вашу характеристику в ответ, пожалуйста: фрагментированность знаний и неумение выражать научное мышление говорит о вас как о мартышке, которая ударив по ЭЛТ-телевизору заставила его работать и уверена что починила. Слишком уж видно что ни системного образования в области носителей информации, ни углубленной подготовки от производителей у вас нет. И ремонтируете вы их почитывая сервис мануалы или другую лежащую на поверхности инфу 2. По роду деятельности, я не умею возможности досконально изучать все аспекты ИТ, и углубляюсь только когда сталкиваюсь с проблемой. Я правильно понял, все ваши посты вы тупо оспариваете тезис: "если файл прочитался то он не повреждён"? Итак. Вы готовы поставить свою бессмертную душу на спор, что микрокод контроллера после невычитывания сектора и маркировки его как unc или bad выпиливает данные НЕ СООБЩАЯ ОБ ЭТОМ ХОСТУ (ОС)? | | |||
| 35
- 10.09.2019 - 10:15
|
Wlad вы уж простите, но читать ваши излияния даже до половины я больше не могу. Однако держите пару тезисов: 1. Ваши "выпады" а каждом посте настолько же наивны насколько и неуместны. Если желаете услышать вашу характеристику в ответ, пожалуйста: фрагментированность знаний и неумение выражать научное мышление говорит о вас как о мартышке, которая ударив по ЭЛТ-телевизору заставила его работать и уверена что починила. Слишком уж видно что ни системного образования в области носителей информации, ни углубленной подготовки от производителей у вас нет. И ремонтируете вы их почитывая сервис мануалы или другую лежащую на поверхности инфу По роду деятельности, я не умею возможности досконально изучать все аспекты ИТ, и углубляюсь только когда сталкиваюсь с проблемой. 2. Я правильно понял, все ваши посты вы тупо оспариваете тезис: "если файл прочитался то он не повреждён"? Итак. Вы готовы поставить свою бессмертную душу на спор, что микрокод контроллера после невычитывания сектора и маркировки его как unc или bad выпиливает данные НЕ СООБЩАЯ ОБ ЭТОМ ХОСТУ (ОС)? | | |||
| 36
- 10.09.2019 - 11:44
|
34-Еще год на этом форуме > Цитата:
А в качестве второго тезиса вопрос - сами вы на каком уровне? В нутро накопителя заглядывали хоть раз, или начитавшись статей таких же как и вы ламеров рассуждаете? Контрольный вопрос на засыпку: почему модуль 6F у накопителей WD всегда читается с ошибкой и какая эта ошибка? | | |||
| 37
- 10.09.2019 - 11:50
|  воткнул 2х2 Tb HDD RAID1 (плюс USB 2 Tb и 500 Gb), доступ из любого места и с любого устройства (кроме микроволновок, чайников и тп) полтора года не кашляет. | | |||
| 38
- 12.09.2019 - 09:52
|
Божечки, вы всё пенитесь как я посмеялся над вами в теме про 3битные ячейки в ssd накопителях? Ну так производители же услышали ваши стоны и сделали ... 4х битные. Отсутствие академических знаний, ранимость, зависимость от чужого мнения ... у вас женщина-то есть? Цитата:
И так как пари из п.2 поста 35 не заключено, то можете смело наклеить вашуже цитату себе на лоб Цитата:
| | |||
| 39
- 12.09.2019 - 10:18
|
Господа, прошу, подключайтесь: Я утверждаю: при подыхании сектора микрокод контроллера в процессе диагностики пытается его вычитать и перенести, а если вычитывание невозможно контроллер заносит сектор в стоплист и ждёт пока ОС не обратится к этому файлу/сектору, дабы решение принял юзер. Предоставил пруф в виде "невозможности считывания файла". По заверению Wlad, вы никогда не узнаете что ваши файлы биты, фотки будут неожиданно крошится, музыкальные треки будут заикаться как на царапаном сидюке... ибо микрокод будет переносить невычитываемые сектора в резерв не спрашивая вашего разрешения. Пруфом предоставлена некая фотка, и показания Rat. Хотя тут пологаю авто запуск chkdsk просто прогнал диск и спросив разрешения исправил ошибки. | | |||
| 40
- 12.09.2019 - 14:31
| Цитата:
Так что умничайте в детском саду, академик. А я предпочитаю разговоры о том что происходит с накопителями вести с людьми которые в отличии от вас ПРАКТИКИ, то есть понимают о чем я говорю. Вас спросили элементарщину, то о чем знает любой человек работавший с накопителями WD на уровне технокоманд. Вы же проигнорировали мой вопрос И ваше заявление Цитата:
Далее - какое нахрен решение может принять юзер если сектор битый? Вы хотя бы попробуйте понять, что вы несете! Юзеру доступно три варианта, и те определяет операционная система . И когда вы привели воэ это то в общем-то знатно лоханулись, поскольку вообще-то в реальности варианты звучат как "Abort, Retry, Fail?" и то что Беня Гей-тс их перетолмачил на русский через задницу и забыл объяснить ламерам что Fail происходит от английского слова failed означаюшее "неудачно" и для ламерья это стало почему-то "Отмена" вместо того чтобы ПРИЗНАТЬ ЗА ДАННОСТЬ НЕУДАЧНОЕ ЗАВЕРШЕНИЕ ОПЕРАЦИИ. Итак, академик, у нас имеется три варианта: 1. ретрить, то бишь повторять до посинения. 2. игнорить, то есть пропустить ошибочно считываемый файл. 3. признать то что операция закончилась с ошибкой. Все три варианта по сути одно и то же - ФАЙЛ НЕ ВОЗМОЖНО СЧИТАТЬ БЕЗ ОШИБКИ. То есть ОШИБКА ИМЕЕТ МЕСТО, от нее никуда не деться, она УЖЕ ЕСТЬ Вот так то, академик. Булькайте дальше, мне с вами говорить не о чем, вы НЕУЧ, МНОГО О СЕБЕ ВОЗОМНИВШИЙ. | |
Интернет-форум Краснодарского края и Краснодара |
