Теоретично ви можете скасувати ( ctrl+ C) ddrescueта запустити його пізніше тим самим лог-файлом, щоб продовжувати його, а не починати заново. Я бачив деякі повідомлення, які стверджують, що цей метод не завжди працює - у цих випадках ddrescueігнорували колишню роботу і починали спочатку з невідомої причини.
Спробуйте встановити цільовий розділ лише для читання:
sudo mount -o ro /dev/sdc2 /mnt/foo
Як тільки для читання, він не повинен псуватися з ddrescueроботою. Існує ризик, що дані, важливі для файлової системи, ще не будуть відновлені, в цьому випадку mountвийдуть з ладу. З деякою удачею ви зможете змонтувати, а потім прочитайте потрібні файли, але файли можуть бути пошкоджені, навіть якщо ви не отримаєте помилок mountі (наприклад) cp. Огляньте їх або їх копії. Не припиняйте, ddrescueякщо ви не переконайтеся, що файли є дійсними та не мають відновлених / заплутаних фрагментів всередині.
У разі виникнення проблем ви можете дочекатися ddrescueвідновлення більшої кількості даних (якщо такі є). Я б не чекав, коли непошкоджені файли з’являться під точкою монтажу, тому що система може кешувати метадані або самі файли тощо. Зробіть umount, зачекайте, коли відновиться більше даних, mountще раз і перевірте файли.
Редагувати: відповідати на додаткові запитання.
Чи є спосіб сказати ddrescue, щоб вказати певну папку?
Ні. Інструмент працює на рівні блоку. Він нічого не знає про файлову систему та файли. У вашій заяві "ddrescuelog йдеться про відновлення 99,73% моїх файлів", слід сказати "99,73% блоків".
Крім того, чи можливо, що дані були відновлені, оскільки це говорить, що 99,73% врятовано, але це занадто пошкоджено, щоб визнати їх файлами? У такому випадку є якась програма для перегляду пошкоджених файлів, можливо, я можу відновити деякі з них вручну.
Можливий сценарій: вміст файлів відновлюється, але відповідна запис файлової системи не є (зауважте: загалом також можливе навпаки, але очевидно, це не ваш випадок). Ви сказали, що вся папка пішла. Я думаю, що деякі файли можуть з’являтися lost+foundпісля fsck(або подібним чином залежно від вашої файлової системи - я не знаю, що це таке).
Більше інформації тут: Яка мета папки «загублені + знайдені» в Linux та Unix?
Ця fsckоперація не є лише для читання, її не слід виконувати під час ddrescueроботи. Скасування ddrescue, запуск fsckта відновлення ddrescueтакож погано робити. Краще дочекатися ddrescueзакінчення. Це може зайняти деякий час - прочитайте це та це .
Загалом, вам слід працювати з fsckкопією відновлених даних (або будь-яким іншим інструментом, який не читається лише). Хороший шлях для подальшої довідки:
- Запишіть у файл, а не на пристрій. Використовуйте файлову систему з функцією копіювання при записі (COW) .
- Зробіть копію COW за допомогою
cp --reflink=always. Це можна зробити під час ddrescueроботи. Ця копія схожа на знімок вашого цільового файлу.
- Використовуйте будь-який інструмент (и) на копії, включаючи не лише для читання.
- У разі невдачі у вас все ще є оригінальний цільовий файл (можливо, із відновленням більшої кількості даних, якщо
ddrescueвін все ще запущений), щоб почати з іншої копії COW (а може бути, з іншими інструментами).
Ви також можете спробувати знайти видалені файли та відновити їх. Вибір інструменту залежить від файлової системи.
Ще одна підказка: можливо, ваше програмне забезпечення використовувало тимчасові файли десь ще в ієрархії файлової системи. Перевірте /tmp/, /var/tmp/.
Редагуйте, відповідаючи на додаткове запитання.
Коли ddrescuelog каже, що 99,73% блоків було врятовано, що це означає саме? Здається, я повинен очікувати певних результатів, а не порожній домашній привід.
Примітка: приклад нижче не має на меті охоплювати всі проблеми та сценарії файлової системи, а також не відрізняти дискові сектори від одиниць розподілу файлової системи; це відповісти лише на запитання.
Уявіть, що ваш розділ - це книга - енциклопедія, а не роман із сюжетом. Файли - це статті всередині. Дисковий блок (або сектор) - це подібно до сторінки в книзі. Файлова система - це загальний спосіб розміщення статей на сторінках. На деяких сторінках міститься Зміст (ToC), який є проблемою файлової системи на нашому зображенні, і може виглядати приблизно так:
стаття № 289: сторінки 2076, 2077, 2078, 402, 403.
Зауважте, що ця стаття є фрагментарною, оскільки файл може бути. На іншій сторінці, але все ще всередині ToC, у нас є щось на зразок структури папок:
…
people/: Див. ToC на сторінці 43.
…
(стор. 43)
mathematicians/: див. ToC на сторінці 80
famous Poles/.: див. ToC на сторінці 82
Adam and Eve.: див. Статтю №14.
…
(Стор. 80)
Euclid: див. Статтю №289.
Banach Stefan: див. статтю № 4380.
…
(Стор. 82)
Banach Stefan: див. Статтю № 4380.
Kościuszko Tadeusz: див. статтю № 2208.
…
Ця структура є прикладом файлів з твердим посиланням. Існують щонайменше два шляхи, які вказують на одну статтю: ./people/mathematicians/Banach Stefanі ./people/famous Poles/Banach Stefan. Тут я розмістив крапку на початку кожного шляху, тому що мій приклад навмисно приховує інформацію: до якого people/розділу належить розділ? (це може бути /people/або /full articles/people/або /stubs/people/або /foo/bar/people/).
ToC може також мати розділ , який говорить:
"порожні" сторінки: 567, 568, 569, 2070, 2071 ...
Дана сторінка містить текст на ній (тобто дані), навіть якщо вона не належить до жодної статті, що існує в даний час. Це тому, що процес видалення статті впливає лише на зміст . ToC єдиний вірний спосіб сказати , чи належить дана сторінка на статтю, в якій статтю, або його можна розглядати як порожні і перезаписані. Більше того: без ToC немає способу помітити "порожню сторінку" . Енциклопедія дивно відчувати, що пуста сторінка є частиною статті, але сектор, повний 0s або пробілів, або що-небудь інше, може бути частиною файлу. Вся справа в ToC .
Деякі ваші сторінки (блоки) ще не врятовані. Будь-яка з них може бути сторінкою зі статтями-даними або мета -даними Toc . Можливості:
- Блок відсутній - це блок даних (скажімо, стор. 2078). Ви знаєте шлях до статті про Евкліда та на яких сторінках він знаходиться, але одна із сторінок порожня, тоді як вона не повинна. Стаття недійсна.
- Блок відсутній - це блок метаданих. Деякі сценарії:
- Ви втратили слід про вільний простір.
- Ви знаєте, що існує
./people/mathematicians/Euclidшлях, але вам не вистачає інформації, на яких сторінках знаходиться стаття. Статтю знайти неможливо, якщо ви вже щось не знаєте про неї (наприклад, запис про людину, швидше за все, в ній є слово "народжений"; PDF-файли починаються з "% PDF").
- Ви знаєте, що є одна стаття на таких і таких сторінках, але немає повного шляху до неї. У такому випадку ви можете помістити його
lost+foundі саме це fsckбуде робити. На нашому малюнку є можливості (серед інших):
- Відсутня сторінка 80: ви знаєте (зі сторінки 43) є
mathematiciansрозділ (папка), але ви не знаєте, що стаття №289 повинна містити її під назвою "Евклід".
- Сторінка 43 відсутня: ви не знаєте, що має бути стаття №14 про Адама та Єву, а також розділи з математиками та відомими поляками; але ви бачите (на стор. 80), що є якийсь розділ зі статтями про Евкліда та Банаха, а є ще якийсь розділ (стор. 82) зі статтями про Банах та Костюшко. Це те, що може статися з вашими
/home. Статті (файли) є і можуть бути дійсними. Вони не можуть бути досягнуті шляхом , тому що у вас немає Toc з ваших /home.
- Будь-яка комбінація вищезазначених проблем може виникнути, якщо кілька блоків не відновлено.
- (EDIT) Відсутній блок може бути позначений як порожній. У цьому випадку ви нічого не втрачаєте.