Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Рекомендации по восстановлению данн..."	+/–
Сообщение от auto_tips (??) on 28-Фев-18, 22:53
USB флехи и SSD предмет простой: или прочиталось или нет. Шансов что при повторной попытке не читавшийся сектор прочитается - мало. Если заряд в флехе утек, то утек. Если там что-то более системное, слет таблиц трансляции, кончина (фирмвари) контроллера и прочее - ddrescue опять же не поможет. Это или спецутилиты под конкретный контроллер или подпайка к NAND и вычитывание на программаторе. Сам не сделаешь с такими вопросами. HDD - интереснее, механика мрет разнообразно. Довольно часто с цатой попытки чтение нестабильного сектора все же проскакивает. Если наивно монтировать диск средствами ОС, ядро наткнувшись на read error быстро сдастся, файлов не получишь, если не прочиталось по быстрому что-то важное типа суперблока, таблиц разделов и проч. А если построить образ за несколько проходов - может выйти довольно живым, монтируемым и с доступными файлами, плюс-минус то, что не прочиталось совсем. Идея такая, что проходов чтения несколько: 1) Параметры 1-го прохода - при ошибке чтения пропускаем большой кусок, чтобы физически проблемную область обойти. Активное тормошение сбойной области может добить нестабильную механику или вызвать фатальные глюки прошивки диска. Будет у тебя половинка образа - потеряешь как дурак большинство файлов. 2) Когда образ из 1) готов, дочитываем более дотошно, с повторными попытками и прочими камасутрами, например реверс направления чтения или что еще, в надежде что чтение все же проскочит. Количество "уточняющих" проходов - пока не задолбаешься, или пока не перестанут вычитываться сектора. Или как вариант пациент может умереть на очередной итерации, но это уже не важно, образ уже достаточно хороший, это была минимизация потерь. Насколько получится - столько и будет. Чем больше тем лучше, но HDD может решить иначе. Если не идиотничать, получишь большинство файлов в целости и сохранности. Некоторые моменты: 1) Читать имеет смысл по размеру блока ECC. У старых жестких дисков 512 байтов. У новых ("advanced format") - 4096 байтов. Чем меньше блок тем медленнее чтение. Прочлось-не прочлось индивидуально для ECC-блока ("hardware sector"). Необоснованно крупные блоки увеличивают потери данных. Если читать блоком мегабайт - даже если не прочтётся 1 сектор, чтение завалится для всего мегабайта и потеряется целиком. А если это 512 байтов сектора и не прочелся 1 сектор а остальные ок - мы получим почти мегабайит данных, кроме 1 сектора. Разница однако. Особенно если это партишн или суперблок, без которых так сходу ФС вообще не смонтируется. 2) При желании этим заниматься неплохо бы узнать кто такие UNC, IDNF, defect lists, атрибуты smart и проч, чтобы хотя-бы примерно понимать на что нарвался и перспективы (pending sectors, ...). Неплохо бы понимать логи/битмап чтения используемой софтины. По крайней мере чтобы не напортачить. Например если при разных попытках использовать разные размеры блока - есть риск ушатать образ, когда утилита читанет очередные сектора в неправильное смещение образа, считая не тот размер блока который реально был. Do not use force, try to think, Luke. 3) В тяжелых случаях может потребоваться подкрутить таймауты ядра на link reset, число попыток и все такое прочее. Иначе ядро разочаруется в HDD и потеряет его. "Насовсем" - до ребута. Но это лечится - можно вручную пересканировать и найти пропавший жесткий диск. 4) Перезагружать и особенно выключать компьютер с нестабильным жестким диском - худшая идея на свете. Если жесткий диск не стартанет - облом стопроцентный, после этого данные сможет вынуть только серьезный специалист. Необдуманный ресет может облегчить кошелек на очень круглую сумму. Если жесткий диск все-же потерялся, как в 3) - гуглишь как вызвать рескан жестких дисков, изучаешь /sys и заново ресканишь свой жесткий диск. Через минутку-другую после отвала. Фирмварь в это время может вкалывать пытаясь ремапнуть проблемный сектор, ядро же думает что жесткий диск повис и пытается link reset устроить. Фирмвара может думать довольно крепко, не ответит даже на IDENTIFY пока не закончит. В этом случае ядро очень огорчается и считает девайс мертвым. Так что подождать немного до того как ресканить. Никаких ребутов и выключений питания - после них жесткий диск может не запуститься совсем. 5) Если бэдов всего несколько штук, можно записать в них что-нибудь, жесткий диск проверит читается ли это и если нет - переназначит на резервные. Но это имеет смысл только если бэдов не больше 3-5 штук. Со стукнутым жестким диском это или самообман или скрытые грабли для тех кому его всучишь, разрушения на этом не закончатся, по мере разлета пыли бэдов станет больше. 6) Если порушено много - осторожно! После того как у жесткого диска закончится grown defect list (таблица ремапа, типично жесткий диск может перенести 2000-4000 проблемных секторов) - может случиться все что угодно. WD уходят в что-то типа safe mode, считая девайс слишком дохлым, и обычными способами уже ничего не получишь. ATA командами "read sector" - читается. Но вот всякие NCQ и READ MULTI отваливаются, ядро так с наскока получает от ворот поворот и видит сплошные read error. Наверное можно переубедить, заставив забить на NCQ и читать по 1 сектору, но - лучше не нарываться. URL: https://www.opennet.me/openforum/vsluhforumID3/113652.html#14 Обсуждается: http://www.opennet.me/tips/info/3054.shtml
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
Сообщение от Аноним (??) on 28-Фев-18, 22:53
Спасибо, познавательно. Лично я до чтения статьи ограничился бы одним проходом... Теперь буду читать пока крутится :) Правда, не всегда HDD на 1 Тб можно прочитать несколько раз, так как некуда складывать эти разы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
	Сообщение от Аноним (??) on 01-Мрт-18, 11:09
	Не нужно "складывать все эти разы". Утилита ddrescue, например, умеет строить map-файл диска и при первом проходе пропускать нечитаемые сектора, а при последующих проходах складировать удачно прочитанные сектора в нужные места. Так можно за несколько проходов сделать точную копию сыплющегося диска с минимумом потерь данных, пока механика или контроллер совсем не умрёт или количество неудачных чтений сектора не превысит указанных в параметрах значений.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
	Сообщение от Аноним (??) on 01-Мрт-18, 22:38
	Один раз так прочиталось, другой раз эдак. Или считаем прочитанные без ошибок данные всегда верными?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	6. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
	Сообщение от angra (ok) on 02-Мрт-18, 04:46
	> Один раз так прочиталось, другой раз эдак. Хоть раз такое встречал? ЕМНИП на каждый сектор идет несколько байт CRC, если совпадения не произойдет, то контроллер выдаст ошибку, а не данные. Теоретически конечно возможны изменения в данных, которые дадут такой же CRC, но маловероятны.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	11. "Рекомендации по восстановлению данных со сбойного накопителя"	+1 +/–
	Сообщение от Аноним (??) on 03-Мрт-18, 14:50
	> Хоть раз такое встречал? ЕМНИП на каждый сектор идет несколько байт CRC, > если совпадения не произойдет, то контроллер выдаст ошибку, а не данные. > Теоретически конечно возможны изменения в данных, которые дадут такой же CRC, > но маловероятны. Сейчас там чаще всего не CRC а FEC - код коррекции ошибок. Поэтому ошибка чтения всего нескольких битиков не ведет к завалу чтения всего сектора. Вместо этого FEC корректирует ошибки и на гора отдаются исправные данные. А накопитель пытается исправить проблемный сектор. Если не получается и после перезаписи исправными данными все-равно не читается - фирмвара переназначит проблемный сектор в grown defect list. По той же причине в новых дисках сектора сделали 4096 байтов вместо 512. Так соотношение служебных данных FEC и данных сектора лучше. Поскольку данные FEC не входят в емкость накопителя заявляемые на этикетке, производителей душила жаба: место есть, но на этикетке не декларируется. Придумали как тратить меньший процент места на FEC не в ущерб результату. Для более крупных блоков соотношение между FEC и данными лучше при прочих равных. Но слишком крупные блоки с другой стороны дольше ворочать при мелких операциях. Ограничились компромиссом. При чтении важно использовать размер блока чтения как блок FEC. Нет смысла насиловать 4096-байтный накопитель с Advanced Format 512-байтовыми чтениями - фирмварь читает 4096 байтов, испправляет FEC если надо, а потом отбрасывает все кроме запрошенных 512 байтов. В результате только чтение тормозится, а ничего нового не прочтется. А для 512-байтового накопителя читать 4096 байтов чревато тем что из-за проблем с 1 сектором потеряется и еще до 7 секторов. Возможно читаемых. SMART зачастую ведет статистику "soft" read errors - это то что при чтении не прочлось но FEC выдюжил и данные не потерялись. Еще обычно ведется статистика "pending sectors" - накопитель заметил что сектор сбойнул при чтении. При попытке записи в него накопитель проверит читается ли записаное и если нет - решит что сектор проблемный и переназначит его. Эти параметры помогают понять насколько дохлый у вас экспонат и чего от него ждать. Это в теории. На практике фирмвари могут откалывать чудеса налетая на проблемные секторы и картина может несколько отличаться от идеала.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	12. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
	Сообщение от Аноним (??) on 03-Мрт-18, 14:56
	> Один раз так прочиталось, другой раз эдак. Или считаем прочитанные без ошибок > данные всегда верными? У современных накопителей довольно мощные коды FEC, поэтому отдавать разные данные для них не характерно и что-то такое можно скорее увидеть при жестких глюках контроллера. Но врядли кто-то в здравом уме пойдет читать проблемный винч на глючном контроллере. И таки dmesg полезно читать, не игноря признаки проблем. На такие случаи как глюки контроллера или фирмвари накопителя - файловые системы делают свои чексуммы. Но если этого в оригинале не было - как мы вообще узнаем какая разновидность прочитанного правильная?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	10. "Рекомендации по восстановлению данных со сбойного накопителя"	+1 +/–
	Сообщение от Аноним (??) on 03-Мрт-18, 14:23
	> Спасибо, познавательно. Лично я до чтения статьи ограничился бы одним проходом... С этим можно налететь. Вплоть до того что если у вас MBR или суперблок с 1 попытки не прочитался - вы потом вообще никаких данных так сразу не получите. Слетевшую таблицу разделов конечно можно перестроить, а суперблок попробовать и запасной, но это лишняя возня и есть риск облажаться. > Теперь буду читать пока крутится :) Правда, не всегда HDD на 1 > Тб можно прочитать несколько раз, так как некуда складывать эти разы. Так читать надо в один и тот же файл образа. Утилиты такого плана ведут лог или битмап в котором отмечено что прочлось/не прочлось. Стирать файл с логом/битмапом нельзя, разумеется, это часть процедуры. И поэтому второй и далее проходы - с использованием вот этих данных. Чтобы читать только то что не прочлось. Нет никакого смысла читать дважды то что уже успешно прочитано. А при душняке с местом очень помогает btrfs, в котором можно сжатие врубить и делать экспериментальные варианты образа используя cp --reflink, так что храниться будут только отличия от "базового". Удобно в случае если например fsck хочется запустить, но есть опасения что он вместо починки добьет образ. Особенно актуально для reiserfs, где fsck это умеет, но подстраховаться не лишне и для остальных, потому что если fsck испортит образ а у вас не было на этот счет плана - вы пролетаете. А копировать терабайт целиком - не только место занимает но и просто долго. Так что cp --reflink для таких вещей невероятно рулит. Копирование завершается "мгновенно" а по мере записи в копию - файлуха будет "unshare"-ить блоки отличающиеся от оригинала. Это такой доведенный до абсолюта dedup, когда явно указывается что копия изначально  - 100% дубликат оригинала, а дальше как получится.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Рекомендации по восстановлению данных со сбойного накопителя"	–2 +/–
Сообщение от Аноним (??) on 01-Мрт-18, 11:18
Без реальных примеров - грош цена статье. Теория, теория...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
	Сообщение от Аноним (??) on 07-Мрт-18, 07:52
	> Без реальных примеров - грош цена статье. Теория, теория... Это из практического опыта бега по граблям, используя Linux, при желании вынуть данные с минимумом потерь, и чтоб не стоило как самолет. А если кто хотел заучить 5 команд и стать типа экспертом, команда одна: идете с винчом и круглой суммой в лабу к спецам. Потому что надо соображать что и зачем делаешь, а не глупо вводить команды. Иначе станет только хуже. p.s. если винч отпал из-за тупняков фирмвари на сбойных секторах, рескан дисков так: echo "- - -" > /sys/class/scsi_host/host5/scan "host5" - пример, надо менять на нужное. На экзотичных контроллерах может не сработать.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
Сообщение от Аноним (??) on 01-Мрт-18, 11:56
Довольно рваная информация, но интересная По ddrescue: смысл в том, что сначала читается весь диск с максимально возможной скоростью, обнаруживая и пропуская "медленные" и плохие сектора, а затем происходит глубокая вычитка этих отдельных секторов. Статей много в интернетах
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
Сообщение от Аноним (??) on 02-Мрт-18, 19:12
Какой алгоритм для восстановления microSD? Можно по шагам: подключить ридер, запустить такую-то утилиту с такими-то параметрами?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Рекомендации по восстановлению данных со сбойного накопителя"	+1 +/–
	Сообщение от Аноним (??) on 04-Мрт-18, 03:32
	> Какой алгоритм для восстановления microSD? Можно по шагам: подключить ридер, запустить > такую-то утилиту с такими-то параметрами? Самое очевидное - понять что с картой и куда копать. Разобраться в ситуации в Linux можно hexdump он же hd, есть в большинстве дистров. Или просмотрщиком mc в режиме HEX (вырубить format, unwrap и прочие "улучшения" - тупят на больших файлах). Им удобнее. Если видно mbr, структуры ФС, какие-то осмысленные данные и проч - все не так уж плохо. Разумеется сначала образ снять и работать с *КОПИЕЙ* *образа*. И лучше ddrescue/myrescue/подобными, на случай если что-то все же не прочтется, dd обломается на первой же ошибке и образ не получится. Логические разрушений ФС, слет MBR (типично для SD которые на свое горе отформатили, снеся фабричную ФС) и прочие логические ошибки чинятся "как обычно". Хоть fdisk-ом и fsck. Главное понимать как устроено и что где должно быть (чаще всего структура как у "HDD" с 1 MBR разделом и FAT в нем). MBR можно посчитать и записать заново. У FAT часто выживает вторая копия. Если совсем не прокатило (например оба FAT сдохли) - testdisk и photorec помогут вынуть фоточки и т.п.. Более потрепано - вынется то что не фрагментировано. Суперценные файлы можно попробовать пересобрать из фрагментов, но геморно. Я так разок вынул стертый :) музон с карты найденой в речке. Так что если вы думали что стерли, выбросили в речку и все шито-крыто... да как же :) Если чтение с карты идет, но не работает запись - возможно, карта протерлась и контроллер ушел в readonly. Уважающие себя производители (например SanDisk) так делают когда wearout флеша превысил резервные сектора. Данные вынуть, карту выкинуть. Хреновые карты могут умереть целиком - бэкапы рулят. Если с карты что-то читается, но совсем хлам (структур ФС в ожидаемых местах не видно, etc) - это ж.., Карл! Таблица трансляции слетела. Будете записывать что либо - убьете данные. Технически это блоки данных, но - в неправильном порядке. Отдайте спецам, пока не добили. Сами не сделаете. Те кто имеет шансы - не будет задавать ТАКИЕ вопросы. Халявные общедоступные решения не попадались, на подобных know-how спецы зарабатывают на хлеб с маслом. Если данные не нужны, можно попробовать форсануть перестройку транслятора, несколько раз перезаписав всю поверхность карты (разными данными). За несколько итераций контроллер закартирует всю поверхность заново. Карта починится. Но для ответственных вещей не годится - если что-то где-то не достроилось, может развалиться опять. И горе вам если там ценные данные были. Однако пару халявных трупиков я так себе поднял, до сих пор живые. Хороший способ убить транслятор - выдернуть карту без размонтирования. Всего одно глупое действие может облегчить недотепу на убедительную сумму. После размонтирования неплохо подождать пару секунд, мало ли какие внутренние процессы у карты, фирмвары бывают дурные. Более сложные вещи, так что образ не читается и карта не определяется нормально, например размер аномальный или нечто неизвестное - визит к специалистам. Дальнейшее для тех кто думает что сможет что-то продвинутее. Если напортачите, данные потом не вынут даже эксперты, или сдерут три шкуры за возню после вас. Если у контроллера карты (или usb-флехи) слетела фирмварь - для некоторых утилиты можно найти (обычно виндовые, увы). Придется понять что за контроллер и флеха, искать правильные утилиты и прошивки и если что не так, а вы впервые - ой. Иногда проще заплатить тем кто уже набил шишек. Гугл в помощь, склады с этим в инете есть. Для продвинутых манипуляций может захотеться "mmc host" интерфейс. Usb ридеры делающие из карты mass storage - не умеют слать в карты "вендорские" команды. "MMC host" видит карту в нативном виде,  можно убедить слать произвольные команды. Но это для желающих залезть "руки по локоть". Даже в Linux видны некоторые продвинутости (всякие служебные описатели карты, trim работает, ...). Где кто возьмет это - его проблемы. Бывает в некоторых ноутах, на одноплатниках, можно на микроконтроллере сделать, ... - кому надо, найдет вариант. Если контроллер оживить не получилось, в отчаянных случаях паяются к NAND и читают напрямую. Если это крупная SD с большой микросхемой, все понятно. С microSD - флеш chip scale. И все-же, под ним на плате есть пятаки. Нижняя часть microSD - печатная плата покрытая паяльной маской. Если ее аккуратно стереть самой мелкой наждачкой, к пятакам припаиваются. Ну а дальше это NAND. Типовые пинауты пятаков гуглятся (их несколько). Что делать с NAND тот кто этим займется должен знать. Линуксоиды могут попробовать сделать читалку NAND на FTDI2232 или купить готовый адаптер на этом чипе, линуксная софтина для чтения NAND через 2232 болтается в инете. Так что кому по...ться завернуть - берите и e#$тесь, если думаете что крутые :). Но правда образ с NAND это еще не данные. ECC надо убрать и исправить, битые блоки - пропустить (как bad block marker-ы устроены - как раз и разберетесь, в даташитах на чипы есть подсказки, но это "factory defect list". А "grown defects list" может быть как угодно в меру заскоков фирмвары контроллера). А потом - потом надо еще таблицу трансляции к этому применить. Но если какой-то маньяк зашел так далеко, возможно что и с этим разберется. А лучшая утилита с одной кнопкой "сделать зашибись" это спец по восстановлению данных. На вход карта и деньги, на выходе ваши данные. Это наиболее реалистичный способ не греть мозг самому.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

8. "Рекомендации по восстановлению данных со сбойного накопителя"	–1 +/–
Сообщение от demimurych (ok) on 02-Мрт-18, 21:03
Манера подачи материала отбивает желание с ним знакомиться. Это раз. Попытка прочитать сбойный сектор по нескольку раз известна с махровых Нортон Диск Доктор и прочих похожих утилит.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
	Сообщение от Michael Shigorin (ok) on 03-Мрт-18, 10:47
	> Манера подачи материала отбивает желание с ним знакомиться. Это раз. Это был развесистый комментарий в обсуждении новости о ddrescue, если что.  А в советы его предложил вытащить я, так что и претензии ко мне.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	14. "Рекомендации по восстановлению данных со сбойного накопителя"	+1 +/–
	Сообщение от Аноним (??) on 04-Мрт-18, 03:58
	> Манера подачи материала отбивает желание с ним знакомиться. Это раз. Это вообще по хорошему должно бы быть где-то в wiki и отрихтовано. Если хотите и знания позволяют, займитесь. Если вы найдете материал структурированный лучше, да еще с уклоном в Linux - я рад за вас, ссылочку на него и вопрос исчерпан. > Попытка прочитать сбойный сектор по нескольку раз известна с махровых Нортон Диск > Доктор и прочих похожих утилит. Только NDD под Linux нет. И битмапы/логи он вроде бы не строил. А они позволяют повторить попытку как-нибудь потом. И даже переиграв параметры, например читая с конца диска или делая прыжки в сторону между чтениями. Это может спровоцировать подлет голов чуть иначе, может прочитаться что-то еще. Такие утилиты позволяют опробовать несколько вариантов которые как-то по разному отвзаимодействуют с фирмварью накопителя. В результате опробовав пяток разных способов можно вынуть "почти все". Ну как, с диска который уронили включеным я вынул все минус 2000 секторов (там где головы чиркнули по блинам). Потом у него пыль от запилов долетела до служебки и он все-же умер окончательно, но 2000 секторов при настолько тяжелом случае весьма маргинальные потери. Если делать глупо, "умер окончательно" может наступить до того как вы вообще что-то осмысленное прочитаете.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

15. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
Сообщение от illkman on 05-Мрт-18, 21:44
На pc3000 если нужны данные, если нет то можно добивать долбать и тп.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
	Сообщение от Аноним (??) on 07-Мрт-18, 08:14
	> На pc3000 если нужны данные, если нет то можно добивать долбать и тп. А за хлебом в магазин надо на самолете подкатывать? Иначе не по пацански? Если у диска в целом хорошее состояние, но с десяток секторов не читается, так что MBR, например, не удалось читануть с 1 попытки, но прокатило с 10-й, а накрайняк его и перестроить можно - нафуя там PC3K?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

18. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
Сообщение от Сергей (??) on 07-Мрт-18, 08:56
Не когда не доводилось восстанавливать! Обычно zabbix спамит об ошибках диска. Идешь в магазин и покупаешь новый диск.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
	Сообщение от Crazy Alex (ok) on 19-Мрт-18, 15:58
	Особенно о проблемах на компе родителей, ноутбуке жены и так далее, угу. Face it - большинство "простых пользователей" бекапов не делает. А жаловаться всё равно потом к кому-то бегут.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	21. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
	Сообщение от Аноним (??) on 24-Мрт-18, 13:44
	А еще Zabbix не помогает если кто-то по запаре махнул рукой и коробка с внешним диском улетела со стола.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

19. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
Сообщение от L (??) on 09-Мрт-18, 18:14
Прекрасный материал. Очень интересно. Автору большое спасибо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
Сообщение от Аноним (??) on 09-Апр-18, 00:06
Если на диске есть ценная информация, то лучше отдать в специализированный сервис. Там правильно диагностируют причину отказа, и с большей вероятностью восстановят данные. Зачастую после "самолечения" дисков в домашних условиях, данные с них восстановить намного сложнее и дороже.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	23. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
	Сообщение от Аноним (??) on 10-Апр-18, 08:50
	В идеале - да. Но за услуги именно хороших профессионалов - дерут. Потому что хорошие профессионалы - при деле. И достают именно реально ценные данные, всяким корпоративщикам с ж-й в огне и проч. За это им прилично платят. Так что за три копейки они плясать не станут. И то что приемлимо для жирного корпоративщика по цене - может вызвать афиг у индивидуала. И еще гарантий что в первом попавшемся сервисе нормальные специалисты никто не даст. А найти правильный сервисник с дельными спецами - отдельная задача само по себе. А если кто немного в теме и знает где правильные спецы... то в половине случаев ему сервисник и не потребуется в легких случаях. И вот это в основном для них. А если кто сдуру все усложнит и удорожит - кто ему доктор? На будущее научится более реалистично силы оценивать. А так в половине сервисов сейчас извините джамшуты, которые пытаются по легкому бабла срубить. И если рандомно сунуться в произвольный сервис, не раскуривая пару дней специфику - большой вопрос что получится в результате.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	24. "Рекомендации по восстановлению данных со сбойного накопителя"	+/–
	Сообщение от Аноним (??) on 11-Апр-18, 10:32
	В 2011 знакомая обращалась в известный центр в Москве. За восстановление морских фотографий с диска, который уронили, взяли около 15 т.р. В эту сумму была включена стоимость диска-донора. Так что, по крайней мере, в то время цены были вполне норм.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема