Повернення з безодні, або відновлення файлів в UNIX
div.main Повернення з безодні, або відновлення файлів в UNIXЛайем Уиддоусон, Джон Ферліто
Ситуація, коли випадково видаляється який-небудь важливий файл, несучи з собою в небуття всі свої біти і байти, - справжній кошмар для будь-якого системного адміністратора. У більшості випадків це скоріше незручність, ніж трагедія, оскільки файли можна відновити за допомогою регулярно оновлюваної резервної копії.
Однак якщо системний адміністратор або розробник з часу останнього резервного копіювання файлу встиг-таки внести в нього значні зміни, то чимало даних може виявитися втрачено. Неприємні ситуації цим не обмежуються: невірно сконфігуровані сценарії резервного копіювання, збої в апаратному забезпеченні або, нарешті, просте невезіння. Ніщо не замінить правильної стратегії резервного копіювання. Анітрохи не піддаючи цю тезу під сумнів, в даній статті ми акцентуємо увагу на методах повного або часткового відновлення файлів в файлову систему UNIX.
ФАЙЛОВА СИСТЕМА UNIX
Файли в UNIX є логічні контейнери даних. З кожним файлом пов'язана так звана структура індексного дескриптора (inode, index-node structure), де містяться метадані (дискові блоки, на яких фізично розміщений файл), інформація про власника файлу, права доступу, розмірі і т. Д. При видаленні файлу індексні дескриптори фізично не стираються з диска, а відзначаються як вільні. Дані, що містяться в таких файлах, все ще зберігаються на диску і потенційно можуть бути відновлені, якщо на їх місце ще не встигли записати нову інформацію.
ПОВЕРНЕННЯ З БЕЗОДНІ
$ ./nph-www.pl> nph-www.pl
Ця команда перетворила її файл з кодом Perl в файл розміром в нуль байт. Ситуація погіршувалася ще й тим, що зміни, вироблені протягом тижня, не вносилися співробітницею в базу даних системи контролю версій (Concurrent Versions System, CVS), що означало втрату приблизно близько 600 рядків коду. Коли вона повідомила, що трапилося, її заспокоїли, пояснивши, що насправді великої біди немає, так як цей файл можна витягти з резервної копії, яка була зроблена минулої ночі, і що їй доведеться відновити лише код, написаний сьогодні.
Я подзвонив нашому системному адміністраторові і попросив його відновити цікавий для нас файл. Однак я не отримав відповіді, на який розраховував, - системний адміністратор зізнався, що він ні разу не чув про сервер розробки, і тому даний сервер не резервувався.
Співробітниця, змирившись з тим, що в файлової системі UNIX неможливо відновити віддалений раніше файл, приготувалася витратити всі свої вихідні на повторне написання цього коду. Її запевнили, що відновлення файлу можливо, але для цього буде потрібно кілька годин. Зауважимо, що такі неприємні історії трапляються не тільки з недосвідченими адміністраторами. Кілька років тому, працюючи в Linux, один з нас випадково надрукував crontab -d замість crontab -e. Чи багато серед читачів знайдеться користувачів, які роблять резервні копії / var / spool / cron / crontabs?
ВІДНОВЛЕННЯ Фото UNIX
# Mount -o ro, remount -n / home
Головне - не допустити перезапис іншими процесами дискових блоків або індексних дескрипторів, раніше затребуваних віддаленим файлом. Це особливо актуально, якщо цей розділ майже заповнений, оскільки саме тоді ймовірність повторного використання вилучених індексних дескрипторів істотно зростає. Якщо ступінь заповнення розділу невелика, процедуру відновлення можна здійснити безпосередньо на змонтованому з можливістю читання / запису розділі диска, хоча, як було зазначено вище, шанси на відновлення при цьому неминуче зменшуються.
Далі описуються процедури відновлення файлів в системах UNIX. Перший розділ присвячений способу відновлення файлів з відомим вмістом, який можна застосувати практично для всіх різновидів файлових систем UNIX. Другий розглядає специфіку відновлення файлів в файлову систему Linux ext2.
ПРОЦЕС ВІДНОВЛЕННЯ Фото З ВІДОМИМ ВМІСТОМ
Після того як система переведена в безпечний стан, необхідно за допомогою команди dd (1) зробити копію вихідних даних розділу, що містить віддалений файл. Припустимо, що помилково видалений файл / etc / passwd. Наступний приклад ілюструє процедуру створення копії кореневого розділу з подальшим приміщенням її в файл з розділу / export:
Цільовий розділ повинен бути досить великим, щоб вмістити в себе весь розділ-джерело (в даному випадку близько 128 Мбайт). Якщо в системі немає необхідного місця на диску, потрібно подумати про альтернативні діях, таких, як монтування віддаленого розділу засобами NFS або виконання дій безпосередньо над файлом пристрою розділу.
Після того як копія файлової системи зроблена, систему можна повернути в багатокористувацький режим і продовжити роботу з нею в звичайному режимі. Якщо копію зробити не вдається, систему слід залишити в безпечному стані, а ім'я пристрою замінити на ім'я файлу (в прикладах, наведених нижче, / dev / dsk / c0t3d0s0 заміняться на /export/recover.dsk).
Описувана далі процедура більше схожа на мистецтво, ніж на науку. Нехай видалений файл з ім'ям passwd. У лівій частині наведеної нижче інструкції команда cat (1) відображає всі «рядки» диска (опція -n передбачає виведення номерів рядків). Далі висновок перенаправляється утиліті fgrep (1), а та за вказаною їй регулярному виразу здійснює «швидкий» пошук запису root у файлі passwd:
У нашому прикладі версії файлу / etc / passwd зберігалися на диску в трьох місцях. Версія GNU утиліти grep (1) надає опції -A і -B, що дозволяють виводити на друк декілька рядків, розташованих до і після знайденої за шаблоном рядки. Це полегшує витягання вмісту всього віддаленого файлу. Якщо grep (1) версії GNU не встановлена на вашому комп'ютері, то ви можете скористатися програмою на Сu під назвою seekcat, наведеної в лістингу 1. Вона виводить на друк весь файл, починаючи з певного зміщення в байтах або рядках. У програмі seekcat передбачені два незалежних параметри: перший вказується за допомогою прапора -b або -l, за ним слід ціле число, що означає зміщення в байтах або рядках, з якого повинен починатися лістинг. Другий параметр задається у вигляді прапора -f, а потім вказується ім'я файлу, що представляє собою в даному випадку «образ диска» вихідних даних. наприклад:
Такого ж результату можна досягти і шляхом вказівки утиліті seekcat початкового рядка. Цей номер береться з роздруківки, отриманої в результаті виконання команди cat -n, описаної раніше в поточному розділі. Програма seekcat виведе вміст файлу, починаючи з того місця, де билa знайдена відповідна шаблоном рядок. У наступному прикладі виводяться 10 рядків «образу диска», починаючи з найпершої знайденої рядки (рядок за номером 200 600). При необхідності можна повторити процес, задавши номер наступної знайденої рядки (в нашому прикладі її номер 202 098):
ПРОЦЕС ВІДНОВЛЕННЯ Фото У LINUX
Йтиметься про процес відновлення файлів в системі Linux в разі, якщо вони були видалені командою rm (1). Описувана тут методика, як правило, гарантує відновлення файлів і не спирається на принцип проб і помилок. Додаткове її перевага полягає в тому, що вона дозволяє легко відновлювати виконавчі файли, а також файли з невідомим вмістом.
Засіб, що використовується в процесі відновлення, відомо як відладчик файлової системи debugfs (8), застосовуваний зазвичай для її перевірки і зміни стану. Хоча наведені нижче приклади написані для Linux, теоретично вони повинні бути справедливі для файлової системи будь-якого типу UNIX за умови, що в ній є засіб з функціональністю debugfs (8). Якщо ж такого засобу не буде, то доведеться користуватися методикою відновлення файлів з відомим вмістом.
Тут варто сказати, що debugfs - це потужне, але в той же час надзвичайно небезпечний засіб. Воно надає безпосередній доступ до файлової системи, так що протягом сеансу роботи з ним необхідно дотримуватися обережності.
Утиліта debugfs (8) забезпечує інтерфейс по типу інтерфейсу командного процесора. Нас будуть цікавити три команди: lsdel, cat і dump. Запустити debugfs (8) в необхідному розділі можна наступним чином:
За інформацією з виведення lsdel можна з'ясувати, які з віддалених індексних дескрипторів представляють для нас інтерес. Найбільш важливі колонки з лістингу - Owner (Власник), Size (Розмір), Mode (Стан) і Time deleted (Час видалення). Якщо з моменту вилучення файлу (ів) не було подальших операцій з диском, то цікавлять нас дескриптори виявляться в кінці списку. В поле Owner (Власник) міститься ідентифікатор користувача - власника файлу, значення якого можна знайти в третьому полі файлу / etc / passwd. У нашому прикладі ім'я власника johnf (ідентифікатор 1000) і файл містить єдиний рядок important_data.
У наведеному вище лістингу дескриптор (inode) з номером 32605 знаходиться в кінці списку і, отже, є першим кандидатом на перевірку. Вміст, що відповідає даному дескриптору, можна вивести наступним чином:
debugfs: cat <32605> important_data
Отже, віддалений файл знайдений. Команда dump «воскрешає» файл, записуючи його на диск:
debugfs: dump -p <32605> / Tmp / recovered_file
Ключ -p гарантує, що у файлу залишаться колишніми власник, група і права доступу.
Установка recover досить проста:
# Tar zxf recover-1.3.tar.gz # cd recover-1.3 # make # make install
За замовчуванням утиліта встановлюється в систему каталогів з коренем / usr. Будь ласка, прочитайте файл README з описом того, як встановити її в іншу систему каталогів. Під час сеансу роботи програма recover задає кілька простих запитань, наприклад:
хто є власником файлів? коли ці файли були видалені? який приблизний розмір цих файлів?
Використовуючи отриману інформацію, recover запускає debugfs, відновлює відповідні даним критерієм індексні дескриптори і поміщає їх в каталог, вказаний користувачем.
На жаль, на відміну від вмісту файлів, їх імена відновити не можна. Відновлені файли отримують імена, що складаються з префікса dump і номера подальшого індексного дескриптора. При видаленні такого каталогу, як / etc, можуть бути втрачені сотні файлів. Для сортування відновлених файлів можна використовувати прості утиліти UNIX, серед яких найбільш корисні strings (1) і file (1).
Програма strings (1) відображає послідовність символів ASCII, витягуючи її з зазначеного файлу. Дана утиліта зазвичай застосовується для «витягування» тексту з довічних файлів, які чинять спротив розшифровці іншими способами.
Так виглядає результат роботи програми file (1) для каталогу з відновленими файлами:
Класифікувати файли різних типів, додавши до назви файла відповідні розширення, можна за допомогою простого сценарію командного процесора. наприклад:
В цьому випадку можна застосувати утиліту strings (1), вивівши на екран всі текстові рядки ASCII, що містяться в довічним файлі. наприклад:
З цього тексту можна здогадатися, що даний файл є виконуваним файлом groff (1). Його запуск на виконання з параметром --help підтверджує це. З бібліотеками дещо складніше, оскільки їх не можна запустити. Тут нам на допомогу приходить команда objdump (1). наприклад:
# Objdump -p dump34756.lib | grep SONAME SONAME libmenu.so.4
Ніякі методи відновлення не замінять резервні копії даних, що створюються регулярно і в повному обсязі на надійних носіях. Описані вище, - це допомога системним адміністраторам, які опинилися на краю прірви.