Знайомі незнайомці: 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, а я лиш наведу приклади його роботи. Ось так виглядає статистика по типам (відсортувати можна по будь-якому з полів):

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