Проблемы после acronis. Нет разрешений на доступ к этой папке

[9285]

Продолжение.
Нужны дампы секторов 122808640 и 125808776+3.
Описание того как делаются дампы есть в Как восстановить MFT внешнего жесткого диска#5

На всякий случай, для контроля все ли записи MFT на своём месте можно сделать своеобразную проверку. Открываешь в DMDE проблемный том, после чего или в меню Сервис выбираешь Все найденные / виртуальная ФС или кликаешь дважды по "папкам" с таким названиям, соглашаешься с предложенным и смотришь что дальше будет. Если не появятся сообщения типа "Ошибка чтения MFT номер хххх", то значит всё на месте.
Как вариант - выложи лог полного сканирования, посмотрю по нему все ил записи на месте.

И ещё один очень интересный момент. Всё таки надо бы понять до какой степени произошли смещения. Вот у меня есть предположение что акронис пересчитал энное количество записей под новое начало тома, но на какой то обломался и не успел перенести MFT. И, учитывая написанное ранее, на роль стопа подходит файл подкачки. Вопрос только в том какой у него номер и сколько записей MFT всего. Ответы на этот вопрос получаются элементарно
После открытия тома, в меню Редактор выбираешь Фаловая запись и в окне выбора будет виден диапазон записей.
А номер записи любого файла (папки) виден в правом верхнем столбце в столбце ID - цифра без учёта написанного в скобках.
И если моя гипотеза верна, то по логичке всё данные номера записей которых больше чем у своп-файла должны восстанавливаться нормально.
Сделай вот такое тоже и напиши результат.

[Barakurt]

Цитата

Нужны дампы секторов 122808640 и 125808776+3.

Цитата

Как вариант - выложи лог полного сканирования, посмотрю по нему все ил записи на месте.

Цитата

Вопрос только в том какой у него номер и сколько записей MFT всего

Сделал прикрепил ниже. Так же на всякий, сделал скрины того что вписывал. Лог сканирования двухдневной давности, думаю он подойдёт.

СПОЙЛЕР »

https://drive.google.com/file/d/1SNq...w?usp=drivesdk

Пришлось залить на гугл, 9мб не ужимаются

Цитата

На всякий случай, для контроля все ли записи MFT на своём месте можно сделать своеобразную проверку

Сделал, к сожалению вылезла ошибка чтения MFT, но в самом конце проверки, на 99%. Скрин тоже прикрепил.

Цитата

И если моя гипотеза верна, то по логичке всё данные номера записей которых больше чем у своп-файла должны восстанавливаться нормально.

Не понял этот момент. Своп-файл (он же файл подкачки), как узнать у него ID? Или же что-то другое нужно? К примеру есть файлы с ID 707485 но если файл подкачки будет ID 807485 (все значения чисто условно), то данные будет не восстановить? Скорее всего я просто ничего не понял, ибо вообще не вяжется)

P.S

Цитата

Банально, но существуют такие вещи как бэкап, дефрагментация и даже архивирование - последнее, даже в случае отсутствия бэкапа позволяет по той же сигнатуре найти архив и поиметь всё структуру папок и имён.

1. Бэкап был конечно же, но по своей тупости я этот бэкапчик выкинул обратно на диск, ибо нужна была срочно флешка по каким-то причинам, а обратно залить бэкап ну или на облако закинуть я либо забыл, либо просто идиот (скорее всего и то и то). Вот к сожалению получилось так.
2. По дефрагу. Немного хочу узнать про этот момент. Как я понял когда файл фрагментирован, он раскидан по диску, дефраг это как бы исправляет. И этот же файл становится уже не фрагментированным? А как это поможет в восстановлении? Из-за того что он будет в одном месте, можно просто будет сделать поиск по блокам? Или как?
3. Про архивирование это да, хорошая вещь оказалась
Не думал что простая архивация может вот так спасти данные. По сигнатурному поиску нашёл январскую версию своих LUA скриптов, этого конечно не достаточно, хочется апрельскую, ибо там основные изменения, но всё же. Зная смещение (если оно одно) вообще становится просто искать те или иные данные. Просто можно посмотреть LBA файла на проблемном томе, а потом просто прибавить смещение и найти в RAW. Круто.
А ещё вопрос. Если бы я к примеру в каждом своём файле добавлял некий одинаковый комментарий в самом начале файла, ну к примеру "-- LUA". Ну и конечно делая дефраг. Можно было бы воспользоваться сигнатурным поиском? Ведь некая константа в начале файла присутствует, соответственно можно сделать поиск по ней. Или же есть подводные камни?

[9285]

В дампах пока не разобрался - какая то котовасия, поэтому пока отвечу на остальное.

Цитата

Сделал, к сожалению вылезла ошибка чтения MFT, но в самом конце проверки, на 99%. Скрин тоже прикрепил.

Если нажал Ок и больше не было ошибок, то это означает что нет всего одной записи.

Цитата

К примеру есть файлы с ID 707485 но если файл подкачки будет ID 807485 (все значения чисто условно), то данные будет не восстановить?

Немного не так. Не очень точная аналогия.

СПОЙЛЕР »

Есть склад с картотекой на 905528 предметов. Это не означает что есть всё это количество - в части карточек указано что место на полках свободно, или что там раньше лежал какой то предмет (аналог удалённых файлов).
Теперь потребовалось уменьшить размер склада и надо всё имеющееся вместить на меньшем числе полок (стеллажей) Вполне естественно что те предметы, которые лежат на "отнимаем" месте нужно перенести в оставшееся. И, в любом случае надо перезаписать все карточки с учётом новой нумерации полок (стеллажей).
И вот тут важно как поступит кладовщик и завскладом.
Они могут:
- постепенно, начиная с 0-вой карточки всё переписывать и перекладывать. Но тут происходит ситуация что на при снятии с полки предмета с ID 807485 этот предмет падает и убивает обоих.
Ведь логично что все предыдущие предметы уже переложены, а оставшиеся нет.
Так понятнее?
И да, исходя из того что имеется сейчас - "картотека находится в "отнимаемом" пространстве и предполагалось что её перенесут в последний момент.

[Barakurt]

Цитата

Если нажал Ок и больше не было ошибок, то это означает что нет всего одной записи.

Да была одна ошибка

[9285]

Что касательно 2-го вопроса и про LUA.
Сигнатурный поиск работает по двум основным принципам.
1. Есть сигнатура начал и есть сигнатура конца. (*.jpg, *.zip) . В этом случае восстанавливается всё что в этом диапазоне.
2. Есть сигнатура начало и размер файла (*.bmp, *.1cd). Восстанавливает от в указанном обьёме.
Соответственно, если ты хочешь в дальнейшем использовать такой поиск, то надо или иметь обе сигнатуры или одну + размер.
И, конечно же, это актуально для дефрагментированных файлов. В противном случае восстановится лишь какая то часть файла, хотя может и очень огромный.

[Barakurt]

Цитата

Но тут происходит ситуация что при снятии с полки предмета с ID 807485 этот предмет падает и убивает обоих.

Хорошая аналогия. Более-менее понял.

На счет сигнатур и прочего. Лучше буду делать бекапы на другие носители и архивировать на основном диске еще на всякий)

[9285]

Что касается лога сканирования.
Если можешь, сделай актуальный - достаточно в переделах проблемного раздела и можно в опциях скана оставить только NTFS.
По этому логу ситуация достаточно (не знаю как бы правильней выразиться) удручающая. Фрагментов не так уж то и много, хотя в случае убирания смещения это только увеличивает обьём работ.
Печальнее то, что записи начинаются в нечётных секторах, при том что начало тома чётное - а это уже означает что делались ещё какие то подвижки (что не удивительно для акрониса).
И да, я забыл показать тебе где можно увидеть ID файла.

[Barakurt]

Ок сейчас просканю только NTFS.
Печально конечно все это читать. Ладно, пока буду сканировать, дальше будет видно.

P. S на счет ID я в курсе, знал где посмотреть

[9285]

Цитата

на счет ID я в курсе, знал где посмотреть

А это кто писал?

Цитата

Своп-файл (он же файл подкачки), как узнать у него ID?

Цитата

Печально конечно все это читать.

Пока ещё не надо паниковать и становиться пессимистом, но я не сторонник писать лживую (приятную) "правду". Что есть то есть - и вот это нечётное смещение как бы намекает на то, что могли быть и более серьёзные перемещение и не факт что было бы всё как сейчас.
И давай смотреть правде в глаза - печально то, что люди пользуются этим дерьмом, а некоторые ещё и утверждают что оно очень хорошее.
Опять же - спросил бы ты как сделать расширение С в такой ситуации (естественно у понимающих, а не тех что отвечали тебе на кибере (там всё таки есть и толковые но их ну ооооочень мало)) и всё можно было бы сделать по высшему разряду.

Добавлено через 18 минут

Тут мне поступила "подсказка друга", ака автора DMDE - попробовать открыть в результатах полного сканирования оба тома NTFS и из них повосстанавливать и проверить файлы. Один из них это то, что было, а второй - то, куда переносилось.

[Barakurt]

Цитата

А это кто писал?

Я имел ввиду, узнать ID этого своп-файла. У простых файлов я могу посмотреть.

P. S Примерно после 40 минут как написал, дошло. Нужно же просто посмотреть айдишник у pagefile.
По ходу уже переизбыток информации у меня, в простых вещах путаюсь. Везде пытаюсь вникнуть, как и что работает, думал и с файлом подкачки не так все просто и узнавать инфу нужно где-то в другом месте DMDE.

Цитата

И давай смотреть правде в глаза - печально то, что люди пользуются этим дерьмом

Да, раньше даже не знал что с этой 'чудо' програмулиной могут быть такие проблемы.
А на счет расширения диска C. Уже делал это раз или два раза. Было удачно. С другой стороны, я уже не помню удавалось ли мне это сделать акронисом. Помню что после попыток с акронисом, увеличивал через Gparted в линухе, вроде было все хорошо.
В общем думал что это вполне стандартная процедура и что все должно быть отлично.

Цитата

Тут мне поступила "подсказка друга", ака автора DMDE - попробовать открыть в результатах полного сканирования оба тома NTFS и из них повосстанавливать и проверить файлы. Один из них это то, что было, а второй - то, куда переносилось.

О как, хорошо, завершу сканирование и попробую. Как раз при сканировании находил 2 NTFS разных размеров.

[9285]

Цитата (Barakurt) »

Как раз при сканировании находил 2 NTFS разных размеров.

Это не разные размеры а алгоритмы программы по куче данных относят часть данных к прежней "прописке", а другую часть к новой. Вот в части этого существует такая инвариантность что и у меня мозги сворачиваются набекрень и я не представляю как всё это реализовано в программе - знаю только что работает.

[Barakurt]

Это просто фантастика. Я не знаю как передать это словами. Восстановил нужные файлы через этот способ!
Чудо!

Сначала перешел в NTFS1 пробежася по файлам, сразу смотрел в редактор, если увижу текст, то профит, если кракозябры, то плохо. В общем ничего не нашел на нем, даже для достоверности восстановил парочку файликов - ничего.
Ну думаю все, шансов нет. Открываю NTFS3, захожу в папку, тыкаю на файл и чудо! Вижу знакомый текст, сразу восстановил пару файов. Работает!
На радостях побежал покупать экспресс версию DMDE. Восстановил самое необходимое, сразу закинул на облако и на другой носитель.
Завтра думаю буду другие файлы восстанавливать.

Как я понимаю лог скана уже не нужен)

[9285]

Ну вот и ладушки!
Но лог скана всё таки выложи - я понимаю что номерация может отличаться, но в прежнем логе нет NTFS3, поэтому хотелось бы взглянуть на актуальный.
И спасибо за лишнее подтверждение того что программа отличная, а в чём то уникальная. Хотя, по хорошему было бы интересно что в этой ситуации смогли бы другие известные программы.
Ну и собственно, если всё нужное восстановлено, то можно продолжить ... пооффтопить на тему как перенести служебный раздел винды и всё таки расширить С.

[Barakurt]

Завтра выложу лог.

Цитата

Ну и собственно, если всё нужное восстановлено, то можно продолжить ... пооффтопить

Впринципе да, можно)
Но я еще кое какие файлы восстановлю. Они конечно не так важны, но как приятный бонус.

Да, программа просто замечательная. Большое спасибо автору за это. Ну и тебе конечно отдельное спасибо.

[Barakurt]

P.S Вот ссылка на скан с NTFS
https://drive.google.com/open?id=1V9...vEb2j66la9YJb9
И размеры у разделов при поиске одинаковые, что-то я напутал

[9285]

Цитата (Barakurt) »

И размеры у разделов при поиске одинаковые

На днях, в какой то теме писал - это не размер раздела, а размер участка, в котором находятся данные предполагаемого тома, и границей этого "участка является самый дальний кластер с данными.

PS. Лог тот же и ничего не изменилось.
Часть записей MFT в нечётных секторах, часть в чётных. Начальные записи MFT лежат не там где указано в бутсекторе (*) и данные ранлиста не соответствуют реальным размерам. В общем, хороший такой "взрыв на помойке"
Тем более поразительно что программа все эти сдвиги и несоответствия учла и дала возможность восстановить файлы.
(*) Мне вообще непонятно как винда могла открывать такой покоцанный том.

[Barakurt]

Да, непонятно как вообще удалось восстановить данные. Автор программы постарался на славу. Причем способ восстановления был одним из самых простых)

Как действовать дальше? Форматировать раздел F?
Будет же достаточно средств допустим стандартной винды или линукса?
И еще, если можно. Как все таки правильно увеличить размер раздела C?
Планирую все таки откусить гигов 40,чтоб с запасом и больше не лезть в эту тему какое-то время)

P.S на C у меня довольно мало места (ненавижу винду 10), может 1гб максимум свободно. Читал что могут быть проблемы с увеличением при такой ситуации.

[9285]

что касается дальнейших действий, то лично я бы в такой ситуации поступил следующим образом.
1. Определиться для чего существует служебный раздел между нынешними двумя. В той же DMDE можно посмотреть что там внутри него. Скорей всего, в строках загрузчика винды тоже можно определить его назначение.
Если он нужен для каких то целей то перенести его в конец диска и потом прописать в загрузчике с новыми координатами.
2. Удалить бывший F.
3. Всё свободное пространство между С и перемещённым служебным занулить.
4. Расширить С на нужный размер средствами винды.
5. Создать новый том на свободном месте. Чтобы том был основным - создавать через diskpart.
PS. На NTFS томах крайне желательно чтобы было какое то количество свободного места (обычно упоминается цифра 12%). Если диск занят сильно, то начинается сильная фрагментация, в том числе и метаданных. И в особо запущенных случаях от её последствий бывает невозможно избавится. Но, в части увеличения обьёма диска (расширения тома) именно средствами винды, это никак не сказывается.
PPS. Служебные разделы винды можно создать и прописать с нуля - почитай http://www.outsidethebox.ms/16075/

[Barakurt]

Цитата

Определиться для чего существует служебный раздел между нынешними двумя

Там две папки, это recovery и system volume information. В первой еще две папки, которые изменялись в 2017 году, а во второй файл tracking. Log изменялся в 16 году. Как я понимаю, это системный раздел прошлой винды или может после неудачной установки создался.
Его же можно просто форматнуть и перенести в раздел C?

P.S 'занулить' это форматировать?

[garniv]

Цитата (Barakurt) »

P.S 'занулить' это форматировать?

не, 'занулить' - это "заполнить нулями", "заэрейзить"
https://dmde.ru/manual/fillsectors.html