Программы


Ответить в тред Ответить в тред

<<
Назад | Вниз | Каталог | Обновить тред | Автообновление
32 5 9

Восстановить данные в внешнего HDD на 1 ТБ. Файорвая Аноним (Ubuntu Linux: Chromium based) # OP 22/04/19 Пнд 17:22:39 25515001
53453543.jpg (49Кб, 680x451)
680x451
Восстановить данные в внешнего HDD на 1 ТБ.
Файорвая система EXT4.

По ошибке в Gnome Disks было выбран параметр - "полное форматирование (замена нулями)".

Через две секунды после начала форматирования, ошибка была замечена и USB кабель был выдернут.

При подключении он не определяется, что логично, но есть в Gnome Disks. С исправностью всё норм, наверное.

Думаю, данные сохранены, но как их восстановить, ведь таблице, как я понимаю - пиздец?

Аноны, выручайте, диск не мой!
Аноним (Ubuntu Linux: Chromium based) # OP 22/04/19 Пнд 17:29:02 25515042
8797897.jpeg (8Кб, 234x216)
234x216
Бамп панический
Аноним (Microsoft Windows 10: Firefox based) 22/04/19 Пнд 17:41:39 25515093
>>2551500 (OP)
По идее testdisk'ом можешь попробовать восстановить таблицу, если ничего не писал на него
Аноним (Ubuntu Linux: Chromium based) # OP 22/04/19 Пнд 18:01:12 25515314
>>2551509
Ничего не записывал.
Сейчас делаю анализ GParted на возможность восстановления.
Если не поможет, попробую testdisk ом.
Аноним (Ubuntu Linux: Chromium based) # OP 23/04/19 Втр 16:13:53 25520125
Ситуация на данный момент - gparted с помощью gpart сканирует диск уже 22 часа.
Аноним (Google Android: Mobile Safari) 23/04/19 Втр 18:40:03 25520576
Аноним (Ubuntu Linux: Chromium based) 23/04/19 Втр 19:23:30 25520727
>>2552057
Буду бороться до конца!
Аноним (Google Android: Mobile Safari) 23/04/19 Втр 19:51:25 25520868
Ну как дела?
Аноним (Ubuntu Linux: Chromium based) 23/04/19 Втр 20:02:40 25520889
>>2552086
Сканирование gpart ом идёт 26 час. Жду.
Аноним (Ubuntu Linux: Chromium based) # OP 24/04/19 Срд 00:40:27 255223610
Шёл 31й час сканирования внешнего жёсткого диска gpart ом...
Аноним (Google Android: Mobile Safari) 24/04/19 Срд 01:41:44 255225911
Если разделы на месте, то при монтировании просту укажи резервный суперблок. Если разделы по пизде, то сначала создай их на том же месте без форматирования, бля
Аноним (Ubuntu Linux: Chromium based) # OP 24/04/19 Срд 02:07:19 255226212
>>2552259
Там форматирование нулями шло около двух секунд. Поэтому таки часть будет потеряна.
Аноним (Ubuntu Linux: Chromium based) # OP 24/04/19 Срд 03:10:45 255226913
Шёл 34й час сканирования...
Аноним (Microsoft Windows 10: Firefox based) 24/04/19 Срд 07:50:37 255228214
>>2552269
Качай пока R-Studio Emergency живой диск с варезников. Там чуть больше шансов восстановить хоть часть фалов.
Аноним (Ubuntu Linux: Chromium based) 24/04/19 Срд 16:24:53 255253015
>>2552282

Я под Линем. Если не прокатит вариант с GParted ом буду пробовать testdisk - в прошлом был успешный опыт работы с этой программой.

А пока... шёл 47й час сканирования жёсткого диска gpart ом.
Аноним (Ubuntu Linux: Chromium based) # OP 24/04/19 Срд 19:11:51 255261616
49 часов сканирования gpart ом это вообще нормально?
Диск объёмом 1 ТБ. Занято информацией было 500 ГБ.

Эта программка проверяет какждый сектор пытаясь определить, кусок ли это файловой системы и если да то какой. Подобное время для таких объёмов - это норма?
Аноним (Microsoft Windows 10: Firefox based) 24/04/19 Срд 20:23:12 255265217
>>2552530
>Я под Линем.
И что тебе мешает запустить живой диск?
Аноним (Ubuntu Linux: Chromium based) 24/04/19 Срд 20:36:11 255265618
>>2552652
Я не произвожу запись на диск. Сначала попробую дождаться gpart.
После, если не поможет, попробую testdisk. Если и это не поможет, то будут пробовать R-Studio.
Аноним (Linux: Firefox based) 24/04/19 Срд 23:05:23 255270119
>>2552262
Я всё сказал, а ты даже не попытался уточнить и погуглить.
Аноним (Linux: Firefox based) 24/04/19 Срд 23:06:11 255270220
>>2552616
>Эта программка проверяет какждый сектор пытаясь определить, кусок ли это файловой системы и если да то какой. Подобное время для таких объёмов - это норма?
У ext4 копии суперблока по всей поверхности размазаны! Искать ничего не надо, на предопределённых местах лежит.
Аноним (Ubuntu Linux: Chromium based) # OP 24/04/19 Срд 23:50:20 255271821
>>2552702
Я лажанулся, когда писал шапку. Там NTFS.
Аноним (Google Android: Mobile Safari) 24/04/19 Срд 23:51:49 255271922
Аноним (Apple Mac: Firefox based) 24/04/19 Срд 23:59:31 255272523
>>2551500 (OP) Своруй уже r-studio или recovery explorer.
Аноним (Ubuntu Linux: Chromium based) 25/04/19 Чтв 00:15:27 255273224
>>2552719
>>2552725

ОК. Попробую. Но это после того, что описал выше.

Просто вот думаю, а что если процесс уже скоро закончится, а я возьму и остановлю. Тем временем сканирование идёт уже 55 час.

Что самое паскудное, в Gparted нет показания прогресса этого процесса. Может он завис, а может идёт. Хуй знает.

Но диод показывает, что осуществляется чтение диска.

Аноним (Google Android: Mobile Safari) 25/04/19 Чтв 00:23:14 255273325
>>2552732
> Но диод показывает, что осуществляется чтение диска.
> идёт уже 55 час.
Не добей диск физически.
Аноним (Google Android: Mobile Safari) 25/04/19 Чтв 01:01:58 255274826
>>2552732
> самое паскудное, в Gparted нет показания прогресса этого процесса.
Возможность отображения прогресса какого-либо процесса - фишка весьма ресурсоемкая. Поэтому разработчики ПО умышленно отключают её. Особенно в тех циклах и участках кода, которые уж очень глубокие и витиеватые.
Так ты прождал 50 часов и работа сделана на 50 часов, а с отображением графика прождав 50 часов, работа будет сделана как за 35 часов.
Аноним (Ubuntu Linux: Chromium based) 25/04/19 Чтв 01:02:48 255275127
>>2552733
>>2552748
Всё. Решил остановить. 55 часов это перебор. Сейчас попробую утилиту testdisk и дальше по списку.
Всех благодарю за советы, но не прощаюсь.
Аноним (Google Android: Mobile Safari) 25/04/19 Чтв 01:06:47 255275428
>>2552751
Ещё раз подумай. Всеравно ночь на дворе. Оставь до утра. Утро вечера пмудреней.
1хуй уже столько прождал.
Аноним (Ubuntu Linux: Chromium based) # OP 28/04/19 Вск 05:39:09 255513929
Заключительный пост

Сканирование с помощью Gparted, а он использует утилиту Gpart не принесло результата. Все 55 часов он просто оставался ЗАВИСШИМ.

Используя testdisk без проблем, легко и просто восстановил почти всю информацию. Потерянные файлы составляют менее 1% и не являются важными.

Я выкрутился из ситуации без потерь, не считая времени и незначительной потери нервных клеток.

Мораль: делайте резервные копии и резервные копии резервных копий. Будьте внимательны при форматировании носителей информации.

Вопрос решён. Всех благодарю за советы.
Аноним (Linux: Firefox based) 28/04/19 Вск 05:48:06 255514130
29.jpg (40Кб, 450x300)
450x300
>>2551500 (OP)
Нужно хотя бы S>M>A>R>T, какие данные он видит и потом уже попытаться восстанавливать. Огринеть пгосто, ты криворук. Я когда был молод, у меня почти такая же ситуация была.
Аноним (Linux: Firefox based) 28/04/19 Вск 05:57:31 255514331
.jpg (54Кб, 750x500)
750x500
Через HEX-редактор восстанови загрузочные сектора, я всегда так делаю...А потом покупаю диск на авито, но ты гришьу у тебя инфа и много прона, это миняет ситуацию.
Аноним (Ubuntu Linux: Chromium based) 28/04/19 Вск 06:00:11 255514532
>>2555141
>>2555143

Так это внешний жёсткий диск и он исправен.

Я запустил на нём форматирование нулями, вместо флешки, но уже через 2 секунды выдернул USB разъём.

Что я должен был увидеть в SMART? Там всё было и есть отлично. Диск новый.
Аноним (Linux: Firefox based) 28/04/19 Вск 06:33:06 255515133
20 (69).jpg (44Кб, 650x522)
650x522
>>2555145
Ну часть иформации затёрлась, есть огромное количство програм, как и под Linux так и под Windows, как восстановить, просто ты спрашиваешь в треде про софт, никто не станет даже заморачиваться, это никаму не нужно, понямаешь)
Настройки X
Ответить в тред X
15000 [S]
Макс объем: 40Mб, макс кол-во файлов: 4
Кликни/брось файл/ctrl-v
Стикеры X
Избранное / Топ тредов