Знайомі незнайомці: file, ln та lost+found

Досі мені ні разу не доводилося відновлювати файлову систему після краху або неправильних дій користувачів, проте одного дня я сам «прострелив собі ногу» в стилі UNIX: вилучив половину файлів двотерабайтного сховища на сервері. В цю особливо похмуру ніч я запустив перебудову файлової системи з метою знаходження старих невилучених файлів, і вже на ранок я отримав більш-менш відновлену файлову систему, а в її корені з’явилась вищеозначена директорія lost+found.

Відкривши директорію я побачив 180 гігабайт файлів з дивними назвами без жодного натяку хоча б на приналежність до типу файлу. Так, це і були відновлені файли. На фоні цього хаосу так само дивно названі директорії виглядали ледве не оазисами в пустелі: адже в них вціліли справжні імена файлів. Проте 180 гектар вручну не просієш, і я вирішив для початку оцінити масштаби трагедії і знайти більш-менш адекватний спосіб витягти з того хаосу частинки необхідних мені даних. І ось тут почалось найцікавіше.

Інтернет просто кишить сторінками виду «ааа, я завалив свою файлову систему, як мені звідти щось дістати?» і подібних. Проте всі поради зводяться лиш до одного — відновити файлову систему. Про збереження самих даних мова зазвичай не йдеться, адже найбільш імовірно відновити з хоч якою-небудь гарантією цілісності дуже складно. Щойно мова заходить про директорію lost+found, як більшість просто натякає в бік використання утиліти file або засобів відновлення фотографій з жорсткого диску, і на цьому все закінчується. Проте сама утиліта file, хоч і дає детальну інформацію, сама по собі несе мало користі, коли необхідно прошерстити значний об’єм даних, а спеціалізовані утиліти відновлять відповідні файли, і не більше. А все інше так і лишиться мотлохом, який лиш дарма займає місце на дискові.

Подібна ситуація мене не надто порадувала і тому сьогодні Вашій увазі пропонується два скрипти, які набагато спрощують процес ручного відновлення файлів з директорії lost+found.

Перед тим, як представити їх, слід розглянути, яким чином виконується іменування файлів в даній директорії. Як неважко помітити, всі імена мають вигляд “«число»_«число»”. Друге число — це т.з. inode файлу — номер файлу у внутрішній структурі ФС, а перше — батьківський inode. Саме він представляє для нас цікавість, адже відновлені файли можна скласти по директоріям, що спростить їх подальшу класифікацію. Розсортувати файли і директорії відповідно до їх батьківських inode-ів можна, скориставшись таким простим сценарієм:

Розклавши всі файли по відповідним папкам, набагато простіше зрозуміти, що саме в них знаходиться і що з ними далі робити. Проте не слід на цьому зупинятись, адже після того, як всі впізнавані файли будуть врешті покладені на свої місця, лишиться купа даних, яка знову не може викликати ясних спогадів про саму себе. І тут на допомогу прийде утиліта file. Не сама по собі, звичайно,а в складі написаного скрипта.

Утиліта file — евристичний аналізатор вмісту файлів на базі шаблонів, яких у нього досить багато. Зазвичай в результаті його роботи ми отримуємо детальну інформацію про тип файлу, і майже зі стовідсотковою впевненістю можемо дописати розширення файлу. Значно рідше використовується можливість утиліти виводити MIME-тип файлу, хоча й тут існують свої переваги.

Утиліту ln дуже часто розглядають виключно з позиції створення символьних посилань(symlinks), проте не слід забувати таку зручну річ, як і жосткі посилання: набагато зручніше скопіювати файл перед тобою, а не шукати файл, на який посилаються. Звісно, слід не забувати обмеження жорстких посилань: вони діють лише в межах однієї файлової системи.

Зібравши всі ці знання докупи, я написав Його. Сценарій з самого початку задумувався лише для підрахування статистики по типам файлів певної директорії, виводячи таблицю, відсортовану по типу файлів, загальному розміру або їх кількості, проте згодом у мене промайнула думка: «А чому б не розкидати файли по відповідним директоріям, виходячи з їх типу?». Як виявилося, думка була досить хорошою, і реалізація не змусила себе чекати.

Оскільки сам сценарій досить великий в порівнянні з цією статтею, всі бажаючі зможуть стягнути його з gist.github.com, а я лиш наведу приклади його роботи. Ось так виглядає статистика по типам (відсортувати можна по будь-якому з полів):

В якості післямови, хочу лиш порадити робити резервні копії навіть найменш важливих файлів, а якщо лиха доля привела Вас сюди, сподіваюсь, що ця публікація допомогла відновити втрачені файли.

  • сильно!
    я ніколи щоправда не доводив файлову систему до такого стану
    завжди намагався витягнути інформацію тим же віндузявним r-studio чи getdataback і їм подібними.

  • сильно!
    я ніколи щоправда не доводив файлову систему до такого стану
    завжди намагався витягнути інформацію тим же віндузявним r-studio чи getdataback і їм подібними.

  • На жаль, дані програми мають ряд недоліків, зокрема:
    * написані для ОС Windows. Я вже три роки як її в себе не тримаю
    * платні
    * (і найголовніше) не підтримують XFS та ReiserFS, не кажучи вже про інші екзотичні файлові системи.

    До того ж, для файлових систем в Linux існує fsck. На жаль, не можу порівняти функціональність вказаних утиліт, проте здогадуюсь напевне, що початкового дерева директорій воно не відновить, і все знову скине в одну купу. Тут же ми маємо хоча б групування файлів в батьківську директорію (а отже маємо перевагу від використання першого скрипта).

    Можливо, вони мають і евристичний аналізатор, подібний до file. Проте я сумніваюся в повноті їх бази, так що file зберігає свою важливість в цьому питанні. Проте все це лиш мої здогади.

    У моєму випадку з ReiserFS я можу твердо сказати, що ніхто, окрім Ганса і його співавторів, цю файлову систему краще не знає, отже й відновити файли краще за fsck не зміг би.

  • На жаль, дані програми мають ряд недоліків, зокрема:

    * написані для ОС Windows. Я вже три роки як її в себе не тримаю
    * платні
    * (і найголовніше) не підтримують XFS та ReiserFS, не кажучи вже про інші екзотичні файлові системи

    До того ж, для файлових систем в Linux існує fsck. На жаль, не можу порівняти функціональність вказаних утиліт, проте здогадуюсь напевне, що початкового дерева директорій воно не відновить, і все знову скине в одну купу. Тут же ми маємо хоча б групування файлів в батьківську директорію (а отже маємо перевагу від використання першого скрипта).

    Можливо, вони мають і евристичний аналізатор, подібний до file. Проте я сумніваюся в повноті їх бази, так що file зберігає свою важливість в цьому питанні. Проте все це лиш мої здогади.

    У моєму випадку з ReiserFS я можу твердо сказати, що ніхто, окрім Ганса і його співавторів, цю файлову систему краще не знає, отже й відновити файли краще за fsck не зміг би.

  • На жаль, дані програми мають ряд недоліків, зокрема:

    * написані для ОС Windows. Я вже три роки як її в себе не тримаю
    * платні
    * (і найголовніше) не підтримують XFS та ReiserFS, не кажучи вже про інші екзотичні файлові системи

    До того ж, для файлових систем в Linux існує fsck. На жаль, не можу порівняти функціональність вказаних утиліт, проте здогадуюсь напевне, що початкового дерева директорій воно не відновить, і все знову скине в одну купу. Тут же ми маємо хоча б групування файлів в батьківську директорію (а отже маємо перевагу від використання першого скрипта).

    Можливо, вони мають і евристичний аналізатор, подібний до file. Проте я сумніваюся в повноті їх бази, так що file зберігає свою важливість в цьому питанні. Проте все це лиш мої здогади.

    У моєму випадку з ReiserFS я можу твердо сказати, що ніхто, окрім Ганса і його співавторів, цю файлову систему краще не знає, отже й відновити файли краще за fsck не зміг би.

  • Ти недооцінюєш r-sutdio 😉 структуру каталогів вона якраз чудово відновлює, але лише тому, що видалення у віндах насправді не таке вже безповоротне (на відміну від…).

  • Все, звісно, залежить від особливостей побудови файлової системи, а не від операційної системи, чи софту загалом. Я не сумніваюсь, що для FAT можливо абсолютно повне відновлення дерева директорій з файлами, тобто, фактично, повний відкат однієї операції зміни структури ФС, проте для хитрих ФС результат точно не буде стовідсотковим. Я порівнював кількість і розмір відновлених і знайдених в директорії lost+found файлів — приблизно було повністю відновлено 80% файлового архіву, інші ж 20 знайшлися в lost+found. Як на мене — не надто поганий результат. Хоча так, до ідеалу далеко.

  • Я говорив про NTFS. У мене R-Studio по песимістичних підрахунках відновив приблизно 90-95% втрачених даних (лише 30% одного каталогу з фотками за один день та частково в інших, де втрати на рівні від 0 до 5% на каталог в кожному з яких по декілька сотень фоток було) після того як я після хібернейту переплутав USB-шнурки від двох зовнішніх хардів (я колись розповідав). І це при тому, що я вже встиг на той вінт і писати, а перед тим його пошматував і віндовий scandisk. Без скандиску і записів, я впевнений, відновив би 99% як не все.

  • Vika

    http://doubleint.ru/ Видео уроки по программированию и системному администрированию

  • Цікава картинка)))