Если ничего не помогло...
Снова прочтите SCSI-HOWTO. Проверьте кабели и терминаторы. Попробуйте на другом компьютере, если это возможно. Основная причина проблем со SCSI-устройствами - неправильно настроенное оборудование. В конце концов, вы можете обратиться в различные группы новостей или написать мне, и я постараюсь вам помочь.
Fdisk, mke2fs, mount, и т.п.
После всех вышеописанных процедур можно воспринимать RAID как обычный диск. Сначала разбейте диск на разделы (используя команду fdisk). Затем отформатируйте диск, создав на нем файловую систему ext2. Это можно сделать следующей командой:
Горячая замена
Мы сначала намеревались проверить горячую замену, просто достав диск, а затем вернуть его в стойку фирмы DPT (которую необходимо покупать отдельно). Но, еще до начала наших экспериментов, у нас прошел сбой диска (пока я это пишу, писк от массива сводит меня с ума). Несмотря на то, что один диск сломался, все данные на RAID были доступны.
Вместо замены диска, мы просто подождали немного и поставили этот диск обратно. Диск был восстановлен и все вроде бы нормально. Пока диск был нерабочим, а также в процессе восстановления данных, все данные были доступны. Правда, надо заметить, что если бы сломался еще один диск, то у нас были бы серьезные проблемы.
Контроллер
Имея настолько богатый выбор, вам, при необходимости установить RAID, придется серьезно и аккуратно решить, что же вам надо. В зависимости от ваших потребностей и уровня RAID, который вы собираетесь использовать, некоторые контроллеры могут быть лучше, некоторые хуже. Адаптеры SCSI-SCSI может быть не настолько хороши, как хост-контроллеры (смотрите Сравнение хост- и SCSI-SCSI адаптеров фирмы DPT). Michael Neuffer (neuffer@kralle.zdv.uni-mainz.de), автор драйвера EATA-DMA, прекрасно описал эту разницу на странице Высокопроизводительные SCSI и RAID в Linux.
Контроллеры DPT
Этот документ ориентирован исключительно на контроллеры фирмы DPT. Описана поддержка, практически, всех контроллеров серии SmartRAID IV.
Контроллеры Vortex фирмы ICP
Серия Vortex фирмы ICP представляет из себя полный набор всевозможных контроллеров, поддерживающих Linux. Драйвер ICP встроен в ядро Linux, начиная с версии 2.0.31. Все основные дистрибутивы Linux содержат этот драйвер; S.u.S.e., LST Power Linux, Caldera и Red Hat поддерживают контроллеры фирмы ICP в процессе загрузки и установки. RAID-система легко настраивается при помощи ROMSETUP (для настройки не надо загружать MS-DOS!).
Утилита мониторинга GDTMON позволяет управлять всей системой ICP RAID (узнать скорость передачи, настроить параметры контроллера и жестких дисков, менять сломавшиеся диски и т.п.). На текущий момент существуют следующие модели: одно- и двухканальные Wide- и Ultra-SCSI контроллеры для RAID 0 и RAID 1; одно-, двух-, трех- и пятиканальные Wide- и Ultra-SCSI контроллеры для RAID 0, 1, 4, 5 и 10; одно- и двухканальные Wide- и Ultra2-LVDS SCSI контроллеры для RAID 0 и RAID 1; одно-, двух-, трех- и пятиканальные Wide- и Ultra2-LVDS SCSI контроллеры для RAID 0, 1, 4, 5 и 10; одно- и двухпортовые оптоволоконные контроллеры для RAID 0, 1, 4, 5 и 10; скоро должны появиться 64-битные UW-SCSI контроллеры.
Машина/контроллер выключился в середине процесса форматирования
Как сказано в "Руководстве пользователя контроллера DPT", это очень большая проблема и, возможно, потребуется возвратить диск производителю, потому что менеджер контроллера DPT скорее всего не сможет его отформатировать. Однако, вам, возможно, удастся отформатировать его на низком уровне, при помощи программы фирмы DPT, которая называется clfmt; ее можно найти на их сайте в разделе утилит (http://www.dpt.com/techsup/sr4utils.htm). Прочтите инструкции к программе после разархивирования файла clfmt.zip (используйте эту программу очень аккуратно). После низкоуровневого форматирования диск можно воспринимать как новый. Еще раз, используйте эту программу с опаской!
Мини-HOWTO: Аппаратный RAID DPT в Linux
Ram Samudrala
me@ram.org
Перевод: Станислав Рогин, ASPLinux
Процесс настройки аппаратного RAID под Linux.
Настройка ядра
Вам надо будет встроить в ядро поддержку SCSI и соответствующий драйвер низкого уровня. Читайте "HOWTO: Ядро", чтобы узнать, как собрать ядро. После того, как вы включите поддержку SCSI (SCSI support), в разделе драйверов низкого уровня, выберите соответствующий драйвер (EATA DMA или EATA ISA/EISA/PCI для большинства EATA DMA-совместимых карт (DPT), EATA PIO для очень старых карт моделей PM2001 и PM2012A фирмы DPT). Многие драйверы, включая EATA DMA и EATA ISA/EISA/PCI, должны быть в новых версиях ядер.
После сборки ядра перезагрузите систему, затем проверьте, все ли правильно настроено. Вы должны увидеть драйвер, распознающий RAID, как один SCSI-диск. Если у вас RAID-5, то размер этого диска будет равен 2/3 суммарного объема дисков, входящих в массив.
Поддерживаемые контроллеры
На настоящий момент существует только один хорошо поддерживаемый Linux хост-контроллер RAID (т.е. контроллер, для которого есть драйвер для Linux) - это контроллер фирмы DPT. Однако, существуют другие хост-контроллеры и контроллеры SCSI-SCSI, которые могут работать под Linux. Их производят фирмы Syred, ICP-Vortex, а также BusLogic. К тому же, существуют различные SCSI-SCSI контроллеры. Смотрите страницу "RAID в Linux".
Если в будущем будет реализована поддержка других контроллеров, я приложу все усилия, чтобы внести информацию об этих контроллерах в этот документ. Пожалуйста, посылайте мне любую информацию, которая, как вы считаете, имеет отношение к этому HOWTO.
SCSI-хосты не находятся при загрузке системы
Это может происходить по ряду различных причин, но, скорее всего, в ядро не встроен соответствующий драйвер. Проверьте и убедитесь в том, что нужный драйвер встроен в ядро (EATA-DMA или EATA ISA/EISA/PCI для большинства карт фирмы DPT).
Сконфигурированный RAID виден как N различных дисков
RAID не настроен должным образом. Если у вас стойка фирмы DPT, то вам надо настроить один логический RAID-массив. Michael Neuffer (neuffer@kralle.zdv.uni-mainz.de) пишет: "При настройке контроллера с SM запустите его с ключом /FW0 и/или выберите Solaris в качестве ОС. В результате этого, массив будет управляться напрямую контроллером."
Сообщения при загрузке
Ниже приведены примерные сообщения, выдаваемые драйвером EATA DMA при загрузке:
| EATA (Extended Attachment) driver version: 2.59b developed in co-operation with DPT (c) 1993-96 Michael Neuffer, mike@i-Connect.Net Registered HBAs: HBA no. Boardtype Revis EATA Bus BaseIO IRQ DMA Ch ID Pr QS S/G IS scsi0 : PM2144UW v07L.Y 2.0c PCI 0xef90 11 BMST 1 7 N 64 252 Y scsi0 : EATA (Extended Attachment) HBA driver scsi : 1 host. Vendor: DPT Model: RAID-5 Rev: 07LY Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 8, lun 0 scsi0: queue depth for target 8 on channel 0 set to 64 scsi : detected 1 SCSI disk total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 35591040 [17378 MB] [17.4 GB] |
(Приведенный выше пример выдается ядром при загрузке системы с одним SCSI-контроллером фирмы DPT, настроенным в режиме RAID-5, с тремя дискам, по 9 Гб каждый.)
Ниже приведены примерные сообщения, выдаваемые драйвером EATA ISA/EISA/PCI при загрузке:
| aic7xxx: at PCI 15 aic7xxx: BIOS enabled, IO Port 0x7000, IO Mem 0x3100000, IRQ 15, Revision B aic7xxx: Single Channel, SCSI ID 7, 16/16 SCBs, QFull 16, QMask 0x1f EATA0: address 0x7010 in use, skipping probe. EATA0: 2.0C, PCI 0x7410, IRQ 11, BMST, SG 252, MB 64, tc:y, lc:y, mq:62. EATA0: wide SCSI support enabled, max_id 16, max_lun 8. EATA0: SCSI channel 0 enabled, host target ID 6. EATA/DMA 2.0x: Copyright (C) 1994-1997 Dario Ballabio. scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 4.1.1/3.2.1 scsi1 : EATA/DMA 2.0x rev. 3.11.00 scsi : 2 hosts. scsi0: Scanning channel A for devices. Vendor: IBM OEM Model: DFHSS2F Rev: 1818 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 Vendor: SEAGATE Model: ST41650 TX Rev: DG01 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi1, channel 0, id 0, lun 0 Vendor: TEAC Model: FC-1 GF 00 Rev: RV L Type: Direct-Access ANSI SCSI revision: 01 CCS Detected scsi removable disk sdc at scsi1, channel 0, id 3, lun 0 Vendor: SONY Model: CD-ROM CDU-541 Rev: 2.6a Type: CD-ROM ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi1, channel 0, id 5, lun 0 EATA0: scsi1, channel 0, id 0, lun 0, cmds/lun 21, sorted, tagged. EATA0: scsi1, channel 0, id 3, lun 0, cmds/lun 21, sorted. EATA0: scsi1, channel 0, id 5, lun 0, cmds/lun 21, sorted. scsi : detected 1 SCSI cdrom 3 SCSI disks total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 4404489 [2150 MB] [2.2 GB] SCSI device sdb: hdwr sector= 512 bytes. Sectors= 2779518 [1357 MB] [1.4 GB] SCSI device sdc: hdwr sector= 256 bytes. Sectors= 4160 [1 MB] [0.0 GB] |
(Приведенный выше пример выдается ядром при загрузке системы с двумя SCSI-контроллерами, DPT PM3224W и Adaptec AHA2940.)
Ссылки
Эти документы могут вам пригодиться в процессе настройки RAID:
Технологическая библиотека DPT
HOWTO: Настройка мультидисковых систем
Стойки
От типа стойки зависит возможность горячей замены винчестеров, системы предупреждения (т.е. существует ли система индикации сбоев, и отображается ли повреждение конкретного носителя), и дополнения к самим носителям (например, система воздушного охлаждения или система дополнительного питания). Сначала мы использовали стойки фирмы DPT - RAID-5 на 18 Гб, но они достаточно дороги. Теперь у нас установлена стойка фирмы Wetex (http://www.wetex.com/), имеющая такие же возможности, но стоящая почти вчетверо дешевле. Теперь у нас установлена стойка Wetex на 14 слотов, из которых мы сделали 2 RAID-5, размерами 45 Гб и 63 Гб соответственно.
Установка и настройка оборудования
Внимательно прочтите инструкции по установке карты контроллера и винчестеров. В случае с контроллерами фирмы DPT, менеджер контроллера для Linux для них до сих пор не написан. Вам понадобится системная MS-DOS дискета (обычно ее можно сделать командой format /s из приглашения MS-DOS. Затем вы можете использовать менеджер контроллера фирмы DPT для MS-DOS (сделайте на всякий случай его резервную копию).
После установки контроллера, загрузите DOS при помощи этого диска. Далее вставьте дискету с менеджером контроллера и запустите его командой:
Возможности драйвера EATA DMA
В этом разделе описаны некоторые команды, которые можно использовать в Linux, для проверки конфигурации вашего RAID-массива. В примерах мы опять ссылаемся на драйвер EATA DMA, но действия для других драйверов будут аналогичны.
Чтобы просмотреть настройку вашего драйвера, наберите:
| % cat /proc/scsi/eata_dma/N |
где N - это идентификатор хоста контроллера (host id). Вы увидите примерно следующее:
| EATA (Extended Attachment) driver version: 2.59b queued commands: 353969 processed interrupts: 353969
scsi0 : HBA PM2144UW Firmware revision: v07L.Y Hardware Configuration: IRQ: 11, level triggered DMA: BUSMASTER CPU: MC68020 20MHz Base IO : 0xef90 Host Bus: PCI SCSI Bus: WIDE Speed: 10MB/sec. SCSI channel expansion Module: not present SmartRAID hardware: present. Type: integrated Max array groups: 7 Max drives per RAID 0 array: 7 Max drives per RAID 3/5 array: 7 Cache Module: present. |
| Type: 0 Bank0: 16MB without ECC Bank1: 0MB without ECC Bank2: 0MB without ECC Bank3: 0MB without ECC Timer Mod.: present NVRAM : present SmartROM : enabled Alarm : on HostDisk command statistics: Reads: Writes: 1k: 0 0 2k: 0 0 4k: 0 0 8k: 0 0 16k: 0 0 32k: 0 0 64k: 0 0 128k: 0 0 256k: 0 0 512k: 0 0 1024k: 0 0 >1024k: 0 0 Sum : 0 0 |
Чтобы увидеть более подробную статистику, наберите:
| % echo "eata_dma latency" > /proc/scsi/eata_dma/N |
А затем снова:
| % cat /proc/scsi/eata_dma/N |
и увидите более подробную статистику.
Чтобы выключить этот режим, наберите:
| % echo "eata_dma nolatency" > /proc/scsi/eata_dma/N |
Длинные файлы
Сложнее обстоит дело с файлами длиной более 12 блоков. Необходимо пояснить, как устроена файловая система UNIX. Данные файла хранятся в так называемых "блоках". Эти блоки пронумерованы. Для каждого файла также имеется "inode" (от английского information node), где хранится информация о владельце, правах, типе файла и т. п. Также как и блоки, inode пронумерованы (хотя нумерация ведется независимо от блоков). Каталоги файловой системы содержат имя файла и номер inode.
Кроме того, для того, чтобы ядро знало, где искать данные, соответствующие элементу каталога (файлу), в inode следующим образом размещается информация о блоках с данными файла:
Номера первых 12 блоков хранятся непосредственно в inode; их еще иногда называют блоками с прямой адресацией (direct blocks).
В inode хранится номер блока, в котором хранятся номера еще 256 блоков данных. Иногда его называют блок косвенной адресации (indirect block).
В inode хранится номер блока, в котором хранятся 256 номеров блоков косвенной адресации. Иногда этот блок называют блоком двойной косвенной адресации (doubly indirect block).
В inode хранится номер блока, в котором хранятся 256 номеров блоков двойной косвенной адресации. Его называют блоком тройной косвенной адресации (triply indirect block).
Прочтите еще раз: я знаю, что это непросто, но также и очень важно.
Версии ядра до 2.0.36 включительно при удалении файла обнуляют блоки косвенной адресации (а также блоки двойной косвенной адресации и т. д.). Так что если ваш файл был длинной более 12 блоков, нет никакой гарантии, что вы сможете выявить даже номера блоков с данными, не говоря уже о самих данных.
Единственный способ, который я нашел - это предположить, что файл не был фрагментирован; если был, то у вас проблемы. Если же предполагать, что файл не был фрагментирован, то, в зависимости от количества блоков с данными файла, возможно следующее расположение блоков, описывающих местоположение файла:
0 - 12
Номера блоков хранятся в inode, как описано выше.
13 - 268
После блоков с прямой адресацией идет блок косвенной адресации и далее 256 блоков с данными.
269 - 65804
Как и в прошлом случае, в начале 12 блоков с прямой адресацией, блок косвенной адресации и 256 блоков данных. Далее блок двойной косвенной адресации, за ним 256 групп блоков, состоящих из одного блока косвенной адресации и 256 блоков данных.
65805 и более
Расположение первых 65804 блоков указано выше. Далее один блок тройной косвенной адресации и 256 повторений групп "двойной косвенной адресации". Каждая такая группа состоит из блока двойной косвенной адресации, за которым идет 256 групп из одного блока косвенной адресации и 256 блоков данных.
Даже если номера блоков данных правильны, нет никакой гарантии, что данные в них не перезаписывались. К тому же, чем больше файл, тем меньше шансов, что он был записан без фрагментации (кроме некоторых особых случаев).
Заметьте, что я предполагал, что размер вашего блока 1024 байта, так как это стандартное значение. Если ваши блоки больше, некоторые числа, указанные выше, изменятся. В частности: так как номер блока занимает 4 байта, то количество номеров блоков, которые могут быть размещены в блоке косвенной адресации равно размер_блока/4. Так что везде, где выше встречается число 256, меняйте его на размер_блока/4. Количество требуемых для размещения файла блоков также нужно изменить.
Пример восстановления длинного файла:
| debugfs: stat Inode: 148004 Type: regular Mode: 0644 Flags: 0x0 Version: 1 User: 503 Group: 100 Size: 1851347 File ACL: 0 Directory ACL: 0 Links: 0 Blockcount: 3616 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996 atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996 mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996 dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996 BLOCKS: 8314 8315 8316 8317 8318 8319 8320 8321 8322 8323 8324 8325 8326 8583 TOTAL: 14 |
В данном случае шансы того, что файл не фрагментирован, довольно велики: первые 12 блоков, перечисленные в inode, (блоки с данными) идут подряд. Начнем с того, что восстановим их:
| # fsgrab -c 12 -s 8314 /dev/hda5 > /mnt/recovered.001 |
Следующий блок указанный в inode (8326) - блок косвенной адресации, который мы можем игнорировать, так как предполагаем, что за ним идут блоки данных (с 8327 по 8582).
| # fsgrab -c 256 -s 8327 /dev/hda5 >> /mnt/recovered.001 |
Последний блок, указанный в inode имеет номер 8583. Заметьте, если предположить, что файл не фрагментирован, то пока все нормально: последний блок данных, записанный нами имеет номер 8582, то есть 8327 + 255. Блок 8583 - блок двойной косвенной адресации, его можно игнорировать. За ним идут до 256 групп состоящих из блока косвенной адресации (который мы также игнорируем), и 256 блоков данных. Быстренько выполнив несложные арифметические подсчеты, выполняем следующие команды (заметьте, что мы пропускаем блок двойной косвенной адресации 8583 и следующий за ним (как мы надеемся) блок косвенной адресации 8584 и начинаем с блока 8525):
| # fsgrab -c 256 -s 8585 /dev/hda5 >> /mnt/recovered.001 # fsgrab -c 256 -s 8842 /dev/hda5 >> /mnt/recovered.001 # fsgrab -c 256 -s 9099 /dev/hda5 >> /mnt/recovered.001 # fsgrab -c 256 -s 9356 /dev/hda5 >> /mnt/recovered.001 # fsgrab -c 256 -s 9613 /dev/hda5 >> /mnt/recovered.001 # fsgrab -c 256 -s 9870 /dev/hda5 >> /mnt/recovered.001 |
Итого мы записали 12 + (7 * 256) блоков, то есть 1804. В соответствие с результатом команды "stat" число блоков в файле было равно 3616; считается, что это блоки длиной 512 байт (пережиток с UNIX), поэтому, в действительности, нам надо 3616/2 = 1808 блоков длиной 1024 байт. То есть, нам нужно записать еще четыре блока. Последний записанный блок имел номер 10125. Также, как и раньше, пропускаем блок косвенной адресации (номер 10126) и записываем последние четыре блока:
| # fsgrab -c 4 -s 10127 /dev/hda5 >> /mnt/recovered.001 |
В результате, если нам повезло, то файл полностью восстановлен.
Есть ли какие-нибудь утилиты для автоматизации процесса?
Есть. К сожалению, при работе с ними проблема с восстановлением блоков косвенной адресации (также, как и при восстановлении файлов вручную) остается. Впрочем, если учесть, что эта проблема вскоре перестанет быть таковой, можно начинать искать такие утилиты.
Я написал на Perl утилиту для упрощения работы с fsgrab и назвал ее e2recover. Она выполняет большую часть работы по восстановлению файлов с блоками косвенной адресации и, вроде бы, нормально работает, если файлы не были фрагментированы. Кроме того, она корректно выставляет права (если это возможно, то и владельца) и длину восстановленных файлов.
Изначально, я написал e2recover для будущего полного Howto, поэтому документация по ней появится лишь в нем. Впрочем, если желаете, можете скачать ее с моей странички, а также вскоре с Metalab.
Scott D. Heavner - автор lde, редактора дисков Linux (Linux Disk Editor). Эта утилита может быть использована и как редактор диска, и как замена debugfs для файловых систем ext2 и minix, и даже для xia (хотя поддержка xia убрана из ядер версий 2.1.х и 2.2.х ). Она имеет некоторые полезные возможности для облегчения восстановления, например, просмотр списка блоков файла и поиск по диску. Кроме того, в нее включена полезная документация по основам файловых систем, руководство по восстановлению файлов. lde версии 2.4 можно найти на Metalab и зеркалах или на страничке автора.
Еще один вариант предлагается GNU Midnight Commander, mc. Это полноэкранный менеджер файлов, основанный AFAIK (насколько я знаю) на программе под MS-DOS, известной как "NC". mc поддерживает мышь для консоли и xterm, и доступ к виртуальным файловым системам, что позволяет, например, войти в tar архив, как в обычный каталог. Среди прочих виртуальных файловых систем есть и одна для восстановления файлов с ext2. Звучит удобно, но должен признаться, что сам я эту программу не использовал - я предпочитаю старый добрый sh.
Для использования возможности восстановления файлов нужно при настройке программы перед сборкой указать опцию --with-ext2undel. Кроме того, понадобятся библиотеки из пакета e2fsprogs. Версия программы, включаемая в Debian GNU/Linux, собрана с поддержкой восстановления, это же относится и к другим дистрибутивам. После сборки программы наберите cd undel:/dev/hda5, и вы получите "каталог" с удаленными файлами. Как и большинство других утилит восстановления файлов, mc плохо обрабатывает файлы, содержавшие блоки косвенной адресации - обычно просто восстанавливаются первые 12 блоков.
Очередная версия может быть найдена на ftp сайте Midnight Commander.
Итак, как мне восстановить файл?
Для восстановления данных нужно найти их на устройстве с разделом (raw partition device) и сделать так, чтобы они снова были видны операционной системе. Для этого есть два способа: первый - изменить существующую файловую систему так, что в удаленных inode был снят флаг удаления, после чего надеяться, что данные волшебным образом окажутся на месте. Другой способ, намного более безопасный, но медленный - выяснить, где именно в разделе лежат данные, после чего записать их в новый файл на другой файловой системе.
До начала восстановления файлов нужно кое-что сделать; смотрите разделы Разд. Отключение файловой системы, Разд. Подготовка к непосредственному изменению inode и Разд. Подготовка к записи данных в другое место. Чтобы узнать, как восстановить файлы, смотрите разделы Разд. Поиск удаленных inodes, Разд. Получение подробной информации об удаленных inode, Разд. Восстановление блоков данных и Разд. Прямое редактирование inodes.
Короткие файлы
Если файл занимал не больше 12 блоков, то все их номера хранятся непосредственно в inode. Вы можете просмотреть их командой stat. Более того, debugfs имеет команду, позволяющую восстановить файл автоматически. Например:
Мини-HOWTO: Восстановление удаленных файлов с файловой системы Ext2fs в Linux
Aaron Crane
aaronc@pobox.com
Перевод: Денис Дементьев, ASPLinux
Представьте себе следующую картину. Последние три дня вы не ели, не спали, даже не принимали душ. И, наконец, ваши усилия вознаграждены: вы закончили программу, которая принесет вам всемирную известность и славу. Все, что вам осталось сделать - это запаковать ее архиватором tar и поместить на Metalab. Да... и удалить все копии старых файлов, созданные Emacs. Итак, вы набиваете на клавиатуре rm * ~. Лишний пробел в вашей команде вы замечаете слишком поздно. Вы только что удалили вашу супер программу! Но помощь у вас под рукой. Этот документ рассказывает, как можно восстановить удаленные файлы с файловой системы ext2 (Second Extended File System). Может быть, несмотря ни на что, вам удастся выпустить вашу программу...
Несколько советов
Жизненно необходимо помнить, что при восстановлении удаленных файлов Linux не похож на MS-DOS. В MS-DOS (и его внебрачном потомке Window 95) в большинстве случаев довольно легко восстановить файл, так как в комплект поставки "операционной системы" (я употребляю этот термин в широком смысле) входит утилита, автоматизирующая значительную часть процесса. Linux - совсем другой случай.
Итак, правило N 1 (главная заповедь, если хотите):
"ХРАНИТЕ КОПИИ"
неважно чего. Позаботьтесь об имеющейся у вас информации. Возможно, вы храните переписку, адреса, программы, документы за несколько лет на вашем компьютере. Подумайте о том, как перевернется ваша жизнь, если произойдет непоправимый сбой диска или, не дай бог, к вам в систему проникнет злоумышленник и повредит диски. И это не так уж невероятно - я общался с людьми, оказавшимися в такой ситуации. Я призываю здравомыслящих пользователей Linux пойти и купить устройство резервного копирования, составить приличное расписание копирования данных на него и строго придерживаться этого. Я, например, использую запасной диск на второй машине и периодически сбрасываю на него по сети мой домашний каталог. Для дополнительной информации, по составлению расписания резервного копирования, читайте Frisch (1995) (см. раздел Разд. Ссылки и благодарности).
Что делать, если у вас нет возможности копировать данные?
Попробуйте запретить запись в важные файлы: запрет доступа на запись заставит rm запрашивать подтверждение перед удалением. (Впрочем, я заметил, что если я удаляю каталог со всеми его подкаталогами командой rm -r, то на первом или втором запросе подтверждения я прерываю команду и запускаю ее снова уже как rm -rf.)
Хорошим способом для некоторых файлов может послужить создание ссылки (hard link) на них в скрытом каталоге. Я слышал однажды историю о системном администраторе, который имел привычку случайно затирать /etc/passwd (что соответственно приводило систему в нерабочее состояние). Возможный способ исправить это - сделать (пользователем root) что-то типа:
| # mkdir /.backup # ln /etc/passwd /.backup |
Теперь, чтобы удалить полностью содержимое файла, требуются некоторые дополнительные усилия: если вы наберете
| # rm /etc/passwd |
тогда
| # ln /.backup/passwd /etc |
восстановит его. Конечно, это не спасет в случае перезаписи файла, так что все равно делайте копии.
На файловой системе ext2 можно для защиты использовать атрибуты ext2. Эти атрибуты устанавливаются командой chattr. Есть атрибут `append-only' (только добавление): в файл - с этим атрибутом можно добавлять данные, но он не может быть удален, и его содержимое не может быть перезаписано. Если этот атрибут установить на каталог, то файлы можно изменять, как обычно, но они не могут быть удалены. Атрибут `append-only' устанавливается командой
| $ chattr +a FILE... |
Есть также атрибут `immutable' - устанавливать или снимать его может только root. Файл или каталог с этим атрибутом не может быть изменен, удален, переименован, на него нельзя создать ссылку (hard link). Он устанавливается следующим образом:
| # chattr +i FILE... |
Кроме того, ext2fs поддерживает атрибут `undeletable' (неудаляемый) (+u в chattr). При удалении файла с этим атрибутом, он реально не удаляется, а перемещается в "безопасное место", откуда его можно позже удалить. К сожалению, эта возможность пока еще не реализована; хотя интерес к ее реализации проявлялся, пока (насколько я знаю) она отсутствует во всех доступных ядрах.
Есть сторонники того, чтобы сделать rm
псевдонимом (alias) или функцией для rm -i
(с этим ключом rm запрашивает подтверждение для каждого удаляемого файла). В дистрибутиве Red Hat это сделано для всех пользователей, включая root. Лично я не делаю этого, так как не выношу программы, не работающие без дополнительной поддержки. Кроме того, тут кроется еще одна проблема - рано или поздно вам придется работать в однопользовательском режиме, использовать другой shell или даже другой компьютер, где отсутствует ваша функция rm -i. Если вы привыкли к подтверждениям, то легко можете забыть, где вы находитесь, и указать слишком много файлов для удаления. Таким образом, различные скрипты и программы, заменяющие rm, по моему мнению, очень опасны.
Несколько лучшим решением может быть использование пакета, удаляющего файлы с возможностью восстановления другой командой (не rm). Для более подробной информации смотрите Peek, et al (1993) (см. раздел Разд. Ссылки и благодарности). Минусом этого решения является то, что пользователи могут привыкнуть беззаботно удалять файлы, вместо внимательного подхода к удалению, часто требуемого на большинстве систем Unix.
Отключение файловой системы
Независимо от того, какой способ вы выберете, первое, что нужно сделать - отключить файловую систему, содержащую удаленные файлы. Я настоятельно рекомендую вам не пытаться работать с подключенной файловой системой. Отключение файловой системы должно быть произведено, как можно скорее, после того, как вы удалили файлы; чем скорее вы это сделаете, тем меньше шансов, что данные будут перезаписаны.
Простейший способ сделать это (предполагаем, что удаленные файлы находились в файловой системе /usr) - дать команду
| # umount /usr |
Если вы хотите оставить доступ к файловой системе /usr, перемонтируйте ее только для чтения:
| # mount -o ro,remount /usr |
Если удаленные файлы находились в корневой файловой системе, то вам понадобится ключ -n для предотвращения попытки mount записать информацию в файл /etc/mtab:
| # mount -n -o ro,remount / |
Возможно, какой-то процесс использует эту файловую систему (что вызовет, при попытке отключения, ошибку `Resource busy' (ресурс занят)). Есть программа, посылающая сигналы любому процессу, использующему указанный файл или точку монтирования - это: fuser. Для раздела /usr
попробуйте следующую команду:
| # fuser -v -m /usr |
Она выведет список процессов. Предполагая, что ни один из них не является жизненно необходимым, дайте команду
| # fuser -k -v -m /usr |
которая пошлет сигнал SIGKILL (что гарантировано завершит процесс), или команду
| # fuser -k -TERM -v -m /usr |
которая пошлет сигнал SIGTERM (что обычно приводит к нормальному (чистому) завершению работы процесса).
Отзывы и предложения
Я планирую обновлять этот документ, если появится что-то интересное, и найдется свободное время. Это означает, что я совсем не против каких-либо комментариев от читателей. Можно ли написать понятней? Может быть что-то как-то можно сделать проще? Или появилась новая утилита, позволяющая автоматизировать процесс? Ну и все такое. Если у вас есть, что сказать про этот документ или про fsgrab, или e2recover, черкните мне пару строчек на адрес aaronc@pobox.com.
Подготовка к непосредственному изменению inode
Хотите мой совет? Не делайте так. Не думаю, что мудро играть с файловой системой на достаточно низком уровне. Недостатком этого способа является и то, что вы гарантировано восстановите лишь первые 12 блоков каждого файла. Поэтому, если ваш файл был длиннее, воспользуйтесь другим способом. (Впрочем, посмотрите раздел Разд. Станет ли легче в будущем? для дополнительной информации.)
Если вы считаете, что для вас этот способ подходит, то я советую скопировать данные этого раздела в файл на другом разделе, используя обратную петлю:
| # cp /dev/hda5 /root/working # mount -t ext2 -o loop /root/working /mnt |
(Примечание. Устаревшие версии mount могут не работать с файлами. Если ваш mount не работает, я настоятельно рекомендую поставить последнюю версию, по крайней мере 2.7, так как очень старые версии имеют серьезные ошибки, связанные с правами доступа).
Использование обратной петли означает, что, даже если вы полностью уничтожите файловую систему, то вам достаточно заново скопировать раздел в файл и начать сначала.
Подготовка к записи данных в другое место
Если вы решили воспользоваться этим способом, убедитесь, что у вас имеется раздел, куда вы можете записать новые копии восстанавливаемых файлов. Надеюсь, ваша система имеет несколько разделов: возможно это корневой, /usr и /home. Если у вас есть такой выбор, проблем не должно возникнуть: просто создайте на одном из них новый каталог.
Если у вас только один (корневой) раздел, и вы все держите на нем, то дела обстоят хуже. Может быть у вас найдется раздел MS-DOS или Windows, который можно использовать? Или в вашем ядре (или в модуле) есть поддержка RAM-диска (диска в памяти)? Чтобы использовать RAM-диск (ядро должно быть версии старше 1.3.48), дайте команды:
| # dd if=/dev/zero of=/dev/ram0 bs=1k count=2048 # mke2fs -v -m 0 /dev/ram0 2048 # mount -t ext2 /dev/ram0 /mnt |
Они создадут 2МБ RAM-диск и подключат его к /mnt.
Небольшое предупреждение: если вы используете kerneld (или его замену kmod в ядрах версии 2.2.x и в поздних 2.1.x) для автоматической загрузки и выгрузки модулей ядра, то не отключайте RAM-диск, пока не скопируете все файлы на постоянный носитель. Иначе, при отключении диска, kerneld предполагает, что он может выгрузить модуль, а если это происходит, то освободившаяся память может быть использована другими частями ядра, и вы потеряете все результаты нескольких часов нудной работы по восстановлению своих данных.
Если у вас есть дисковод Zip, Jazz, LS-120 или что-нибудь подобное, то возможно он будет хорошим выбором для раздела с восстановленными данными. В противном случае, вам не останется ничего, кроме флоппи-дисков.
Еще одна вещь, которая вам понадобиться - программа, которая может читать данные из середины раздела устройства. В крайнем случае, для этого подойдет dd, но если вам нужно будет прочитать, скажем, область с 600МБ по 800МБ, то первые 600МБ все равно будут прочитаны dd, хотя и проигнорированы. Это займет довольно много времени, даже на быстрых дисках. В моем случае, для работы с разделом была написана специальная программа. Она называется fsgrab; исходный текст вы можете найти на моем сайте
или на Metalab (и зеркалах). Далее в этом документе предполагается наличие fsgrab.
Если размер файлов, подлежащих восстановлению, не превышал 12 блоков (один блок обычно равен одному килобайту), то fsgrab вам не понадобится.
Если у вас нет fsgrab, и вы не хотите скачивать и собирать его, то можете просто переводить команды для fsgrab в команды для dd. Если команда для fsgrab выглядит так:
| fsgrab -c count -s skip device |
то соответствующая команда для dd будет выглядеть так:
| dd bs=1k if=device count=count skip=skip |
Я должен предупредить, что хотя fsgrab
нормально работал у меня, я не даю никаких гарантий его нормального функционирования. Он был написан очень быстро и не очень аккуратно - лишь бы работало. Для дополнительной информации см раздел `No Warranty' (без гарантии) в файле COPYING (GNU General Public Licence).
Поиск удаленных inodes
Следующий шаг - выяснить, какие именно inode были удалены. Это можно сделать с помощью debugfs. Запустите debugfs, указав имя устройства с удаленными файлами:
| # debugfs /dev/hda5 |
Если хотите непосредственно изменять inode, то укажите ключ -w для разрешения записи в файловую систему:
| # debugfs -w /dev/hda5 |
Команда lsdel программы debugfs предназначена для поиска удаленных inode. При появлении приглашения, введите ее:
| debugfs: lsdel |
После долгого скрипения диском, вашей любимой программе просмотра текста (переменная $PAGER) будет передан длинный список, который нужно сохранить. Если вы используете less, наберите -o с именем файла. В противном случае, вам придется перенаправлять вывод. Можно сделать так:
| debugfs: quit # echo lsdel | debugfs /dev/hda5 > lsdel.out |
Теперь вам предстоит, основываясь на времени удаления, размере, типе, числовых значениях прав доступа и владельца, определить, какие из удаленных inode вам нужны. Если вам повезет, то вы сможете быстро найти их по времени удаления. Иначе придется очень тщательно копаться в этом списке.
Советую, если есть такая возможность, распечатать список indode, которые вы хотите восстановить. Это сильно упрощает жизнь.
Получение подробной информации об удаленных inode
debugfs имеет команду stat, выводящую подробную информацию об inode. Выполните ее для всех inode, подлежащих восстановлению. Например, если вам нужно восстановить inode 148003, наберите:
| debugfs: stat Inode: 148003 Type: regular Mode: 0644 Flags: 0x0 Version: 1 User: 503 Group: 100 Size: 6065 File ACL: 0 Directory ACL: 0 Links: 0 Blockcount: 12 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996 atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996 mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996 dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996 BLOCKS: 594810 594811 594814 594815 594816 594817 TOTAL: 6 |
Если восстанавливать нужно много, можно автоматизировать эту работу. Предполагая, что список удаленных inode, сформированный командой lsdel, находится в файле lsdel.out, можно сделать так:
| # cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " > inodes |
Новый файл inodes содержит номера inode, подлежащих восстановлению, по одной в строке. Он нам пригодится для следующей команды:
| # sed 's/^.*$/stat /' inodes | debugfs /dev/hda5 > stats |
и файл stats содержит данные всех команд stat.
Права
Все торговые марки - собственность их уважаемых владельцев. В частности:
MS-DOS и Windows - торговые марки Microsoft.
UNIX - торговая марка Open Group.
Linux - торговая марка Linus Torvalds в США и некоторых других странах.
This document is Copyright й 1997, 1999 Aaron Crane aaronc@pobox.com. It may be freely redistributed in its entirety, including the whole of this copyright notice, but may not be changed without permission from either the author or the Linux Documentation Project HOWTO Coordinator. Dispensation is granted for copying small verbatim portions for the purposes of reviews or for quoting; in these circumstances, sections may be reproduced in the presence of an appropriate citation but without this copyright notice.
The author requests but does not require that parties intending to sell copies of this document, whether on computer-readable or human-readable media, inform either him or the Linux HOWTO Coordinator of their intentions.
The Linux HOWTO Coordinator is currently Tim Bynum linux-howto@metalab.unc.edu.
Прямое редактирование inodes
Этот способ, на первый взгляд, намного проще. Однако, как уже говорилось, он подходит только для файлов длиной менее 12 блоков.
Для всех inode, подлежащих восстановлению, нужно установить счетчик ссылок в 1 и обнулить время удаления. Это можно сделать командой mi (modify inode - изменить inode) утилиты debugfs. Пример изменения inode 148003:
| debugfs: mi Mode [0100644] User ID [503] Group ID [100] Size [6065] Creation time [833201524] Modification time [832708049] Access time [826012887] Deletion time [833201524] 0 Link count [0] 1 Block count [12] File flags [0x0] Reserved1 [0] File acl [0] Directory acl [0] Fragment address [0] Fragment number [0] Fragment size [0] Direct Block #0 [594810] Direct Block #1 [594811] Direct Block #2 [594814] Direct Block #3 [594815] Direct Block #4 [594816] Direct Block #5 [594817] Direct Block #6 [0] Direct Block #7 [0] Direct Block #8 [0] Direct Block #9 [0] Direct Block #10 [0] Direct Block #11 [0] Indirect Block [0] Double Indirect Block [0] Triple Indirect Block [0] |
То есть, я обнулил время удаления (deletion time) и увеличил счетчик ссылок (link count). Для остальных полей я просто нажимал Enter. Довольно нудная работа, если нужно восстановить много файлов, но, я думаю, что вы справитесь. Если бы вы хотели чего попроще, то наверное поставили бы графическую "операционную систему" с ее хорошенькой "Корзиной".
Кстати, в предыдущем примере mi запрашивает значение поля "время создания" (`Creation time'). Обманывает вас! На самом деле вы не можете указать в файловой системе UNIX время создания файла. Поле st_ctime структуры struct stat описывает "время изменения inode", то есть время последней модификации содержимого inode. Все, пожалуй, хватит на сегодня уроков.
Более поздние версии debugfs, чем та, которую я использую, не включают некоторые поля из вышеуказанного примера ( Reserved1 и (некоторые?) поля fragment).
После окончания модификации всех inode можно выйти из debugfs и дать команду:
| # e2fsck -f /dev/hda5 |
Смысл в том, что хотя мы и восстановили файлы, но ни в одном каталоге нет на них ссылок. Утилита e2fsck определяет это и для каждого файла создает ссылку в каталоге файловой системы /lost+found. (То есть, если файловая система обычно монтируется в /usr, то при следующем монтировании восстановленные файлы будут лежать в /usr/lost+found.) Остается лишь определить, какое имя имел тот или иной файл, и поместить его туда, где он находился до удаления.
Во время работы e2fsck будет задавать вам различные вопросы, касающиеся ремонта файловой системы. Отвечайте "да" (yes) на все вопросы, связанные с "итоговой информацией" (summary information) и с исправленными вами inode. Остальное на ваше усмотрение, хотя, в общем случае, лучше отвечать "да" на все вопросы. По окончании работы e2fsck можно смонтировать файловую систему.
Вообще говоря, есть альтернатива помещению утилитой e2fsck файлов в каталог /lost+found: вы можете использовать debugfs для создания ссылки на inode. Для этого, после изменения inode, дайте команду link:
| debugfs: link foo.txt |
Она создаст файл foo.txt в каталоге, который debugfs считает текущим. foo.txt - это ваш файл. Независимо от этого e2fsck нужно запустить для исправления итоговой информации и т. п.
Сколько процентов данных я смогу восстановить?
Это зависит от многих обстоятельств. Одной из трудностей с восстановлением файлов, на такой высококачественной многозадачной многопользовательской операционной системе, как Linux, является то, что вы никогда не знаете, что кто-то хочет записать что-нибудь на диск. Когда операционной системе дается команда удалить файл, она предполагает, что блоки этого файла могут быть использованы, если нужно место для нового файла. (Это конкретный пример общего принципа для Unix-подобных систем: ядро и связанные с ним инструменты предполагают, что пользователи не идиоты.) В общем случае, чем более загружена ваша машина, тем меньше у вас шансов восстановить файлы.
На сложность восстановления файлов также может влиять фрагментация диска. Если раздел, содержащий удаленные файлы, сильно фрагментирован, то вам сложно будет восстановить файл целиком.
Если ваша машина, подобно моей, фактически является однопользовательской рабочей станцией, и в момент удаления файлов вы не использовали интенсивно диск, то можете ожидать примерно указанный мною ранее процент. Я восстановил около 94% данных (не текстовых, заметьте). Если вы получите 80 или более процентов, то можете быть вполне довольны собой.
Ссылки и благодарности
""Если я видел дальше других, то потому, что стоял на плечах гигантов." (Исаак Ньютон)"
Этот Мини-Howto был изначально основан на статье Robin Glover swrglovr@met.rdg.ac.uk из конференции comp.os.linux.misc. Хотелось бы поблагодарить его за милостивое разрешение использовать его идеи в этом Мини-Howto.
Хотелось бы также воспользоваться возможностью и еще раз поблагодарить всех, кто написал мне по поводу этого документа.
Кое-какая литература:
Frisch, фleen (1995), Essential System Administration, second edition, O'Reilly and Associates, Inc., ISBN: 1-56592-127-5.
Garfinkel, Simson, Daniel Weise and Steven Strassmann
(1994), The Unix-Haters Handbook, IDG Books, ISBN: 1-56884-203-1. Большая часть этой книги - это дикие визги тех, кто считает, что их ОС лучше, чем Unix. Остальное практически не представляет интереса, так как в GNU все значительно подробнее и проще. Однако, среди всего этого мусора есть и хорошие вещи: например, рассуждения о том, как проще удалить файл в Unix.
Glover, Robin (31 Jan 1996), HOW-TO : undelete linux files (ext2fs/debugfs), comp.os.linux.misc Usenet posting.
Peek, Jerry, Tim O'Reilly, Mike Loukides et al (1993), UNIX Power Tools, O'Reilly and Associates, Inc./Random House, Inc., ISBN: 0-679-79073-X. Second edition, 1998.
Станет ли легче в будущем?
Да. Уже сейчас стало проще. Ядра версий 2.0.х обнуляют блоки косвенной адресации, но к ядрам более поздних версий (2.1.х и 2.2.х) это не относится. Я пишу это 2 февраля 1999 г., буквально через несколько дней после выхода в свет ядра версии 2.2.1. Думаю, что через месяц - другой появятся дистрибутивы Linux с этим ядром.
После того, как ограничение, связанное с обнулением блоков косвенной адресации, будет снято, большинство моих указаний по технике изменения inode отпадут за ненадобностью. Кроме того, можно будет как использовать команду dump утилиты debugfs для длинных файлов, так и с успехом пользоваться другими утилитами для восстановления файлов.
Восстановление блоков данных
Эта часть может быть очень легкой и довольно сложной, в зависимости от того, занимал ли удаленный файл больше 12 блоков или нет.
Активизируем inode
Теперь пришло время изменить некоторые флаги удаленных inode.
Скопируйте следующие 6 строк в файл, назвав его "make-debugfs-input".
| #!/bin/sh awk '{ print "mi \n"\ "\n\n\n\n\n\n\n"\ "0\n"\ "1\n"\ "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" }' |
Этим мы имитируем ручное исправление inode. Мы устанавливаем время удаления в 0 и количество ссылок в 1.
 | Я использую debugfs версии 1.18, и, если у вас другая версия, то вам, возможно, придется изменить количество "нажатий" клавиши Enter в вышеприведенном скрипте. |
Теперь изменяем inode:
| # ./make-debugfs-input < inodes | debugfs -w /dev/hdy1 | tail -c 40 |
Если все пройдет хорошо, то последнее сообщение должно быть таким: "Triple Indirect Block [0] debugfs:".
Анализируем содержимое каталога
Просмотрите выгруженное содержимое каталога в читаемом формате:
| # xxd debugfs-dump | less |
Каждая запись состоит из пяти полей. Байты первых двух полей представлены в обратном порядке. Это значит, что первый байт - самый младший.
Описание полей:
4 байта - номер inode.
2 байта - длина этой записи.
1 байт - длина имени файла (1-255).
1 байт - тип файла (0-7).
0 = Неизвестный
1 = Обычный файл
2 = Каталог
3 = Символьное устройство
4 = Блочное устройство
5 = Поток FIFO
6 = Поток SOCK
7 = Символьная ссылка
Имя файла (1-255 символов).
Если запись удаляется из каталога, то размер предыдущей записи увеличивается на размер удаляемой записи (предыдущая запись как бы "съедает" следующую).
Если файл переименовывается в более короткое имя, то уменьшается значение третьего поля.
Первая запись, которую вы увидите - это сам каталог, представляемый одной точкой.
Предположим, что у нас есть следующая запись в каталоге:
| c1 02 0e 00 40 00 05 01 'u' 't' 'i' 'l' 's' |
В ней номер inode будет "e02c1" (в шестнадцатиричной форме) или 918209 (в десятичной). Следующая запись находится через 64 байте (шестнадцатиричное 40). Мы также видим, что имя файла состоит из 5 байт ("utils") и что тип файла (01) соответствует обычному файлу.
Теперь пересчитаем номера inode подкаталогов в десятичную форму.
Если вы не любите производить такие операции вручную, то я для вас написал небольшую программу на C. Программа берет содержимое каталога (созданное debugfs, как описано ранее в разделе Разд. Находим номера inode удаленных каталогов). На стандартном выводе вы получаете список имен файлов и номеров inode.
Перед запуском этой программы вам надо загрузить записанное содержимое каталога в двоичный редактор и изменить поле "длина записи каталога"
в записи, предшествующей восстанавливаемой. Это просто: если мы обозначим длину предшествующей записи как x, а длину записи, которую вы хотите восстановить как y, то вам надо заменить поле, содержащее x на x-y.
Программа называется e2dirana (ext2fs directory analyse), и ее можно найти по адресу http://www.matematik.su.se/~tomase/ext2fs-undeletion/
Добавляем записи в каталоги
Запустите debugfs в режиме чтения-записи.
| # debugfs -w /dev/hdy1 |
Теперь вым надо добавить удаленные каталоги в каталог, где они ранее находились:
| debugfs: link directoryname |
Здесь inode - это номер inode, а directoryname - это номер каталога.
После того, как вы добавите ссылки, вы заметите, что удаленные каталоги появились в текущем каталоге. Вы можете теперь просмотреть его содержимое (при помощи debugfs).
Правда, размер каждого каталога равен 0, и это надо исправить, иначе они будут выглядеть пустыми в команде ls.
Выйдите из debugfs:
| debugfs: quit |
Если каталог /lost+found не пуст
Некоторые из ваших каталогов или файлов могут не появиться в обычных местах. Вместо этого они могут появиться в каталоге /lost+found под именами, состоящими из их номеров inode и старых имен.
В этом случае указатель в элементе ".." каталога скорее всего изменился, и указывает на один из последних файлов каталога (я не знаю, почему это происходит - возможно, это ошибка в драйвере файловой системы).
Изучите 3-ю фазу файла "e2fsck.out" (в ней проверяется связность каталогов). Там вы увидите названия каталогов, которые были затронуты e2fsck. Запишите их на диск (как было описано в главе Разд. Находим номера inode удаленных каталогов).
Запустите e2dirana как с флагом p, так и без него (так вы измените указатель на ".."). Здесь и ниже dump - это записанное на диск содержимое каталога.
| # ext2fs-directory-analyse dump > dump1 # ext2fs-directory-analyse -p dump > dump2 |
Сравните результат работы программ
| # diff dump1 dump2 |
Если эти файлы не равны, значит в этом каталоге есть пропавшие файлы. Переместите данные файлы из каталога /lost+found в правильное место. Здесь dest - это симвользная ссылка на каталог-приемник. Поместите результат работы этого мини-скрипта в файл, и запустите его, если там все правильно.
| # diff dump1 dump2 |\ tail -n $[`diff dump1 dump2 | wc -l`-1] | cut -b 3- |\ sed -e 's/^\([^ ]*\) \(.*\)$/mv lost+found\/#\1 dest\/"\2"/' |\ sed -e 's/!/"\\\!"/g' |
Повторяйте эти действия до тех пор, пока каталог /lost+found не будет пуст.
Мини-HOWTO: Восстановление структуры каталогов файловой системы Ext2fs
Tomas Ericsson
tomase@matematik.su.se
Перевод: Станислав Рогин, ASPLinux
Этот документ является дополнением к Мини-HOWTO: Восстановление файлов в Ext2fs автора Aaron Crane. Я настоятельно рекомендую вам изучить его перед прочтением этого документа.
Ниже я опишу простой способ восстановления целых стуктур каталогов, случайно удаленных командой rm -rf.
Находим номера inode удаленных каталогов
Мы попытаемся выяснить номера inode удаленных каталогов:
| # debugfs /dev/hdy1 |
Перейдите к тому месту, где были удаленные каталоги. Внутри debugfs вы можете обычным образом использовать команды ls и cd:
| debugfs: ls -l |
Эта команда выдаст на экран примерно следующее:
| 179289 20600 0 0 0 17-Feb-100 18:26 file-1 918209 40700 500 500 4096 16-Jan-100 15:18 file-2 160321 41777 0 0 4096 3-Jun-100 06:13 file-3 177275 60660 0 6 0 5-May-98 22:32 file-4 229380 100600 500 500 89891 19-Dec-99 15:40 file-5 213379 120777 0 0 17 16-Jan-100 14:24 file-6 |
Описание полей:
Номер inode.
Первые две (или одна) цифры означают вид inode:
2 = Символьное устройство
4 = Каталог
6 = Блочное устройство
10 = Обычный файл
12 = Символьная ссылка
Следующие четыре цифры - это обычные права доступа к файлу в формате Unix.
Владелец файла (в числовой форме).
Группа файла (в числовой форме).
Размер в байтах.
Дата (Вы наверно уже заметили здесь "Проблему-2000" в действии =)).
Время.
Имя файла.
Теперь выгрузим родительский каталог на диск. Здесь и ниже inode - это соответствующий номер inode (не забудьте символы '').
| debugfs: dump debugfs-dump |
Выйдите из debugfs:
| debugfs: quit |
Находим удаленные inode
Получаем список всех удаленных inode.
| # echo lsdel | debugfs /dev/hdy1 > lsdel.out |
Одна проблема состоит в том, что debugfs не выдаст номера inode файлов, у которых была нулевая длина (у вас могли быть такие файлы, например, в каталоге /etc). Я опишу решение этой проблемы в разделах Разд. Пересчет и Разд. Последние коррективы.
Загрузите "lsdel.out" в текстовый редактор. Список inode должен быть отсортирован по времени удаления. Попробуйте точно вспомнить время, когда вы дали команду rm -rf. Скорее всего, это была последняя команда, и удаленные inode будут находиться в конце списка. Удалите все не интересующие вас строки. Запишите этот файл как "lsdel.out-selected".
Теперь мы удалим из этого файла все, кроме номеров inode:
| # cut -b 1-8 lsdel.out-selected | tr -d " " > inodes |
Для полной уверенности проверьте, что удаленные каталоги, номера которых мы нашли ранее, находятся в этом списке.
| # grep ^inode$ inodes |
, где inode - это соответствующий номер inode.
Обязательные условия
Очень важно, чтобы вы сразу отключили необходимый раздел командой umount, не производя с ним больше никаких операций. Если вы после удаления необходимых файлов запишите на этот раздел что-нибудь, то ваши шансы на успешное восстановление файлов резко уменьшаются.
Также вам понадобится достаточно новая версия ядра, потому что ядра 2.0.x и ниже очищают блоки косвенной адресации, что не позволит вам восстановить файлы длиной больше 12 блоков.
Я опишу лишь один метод восстановления, и не уделю большого внимания ошибкам, которые могут возникнуть в процессе восстановления. Если вы решите, что какой-то из нижеописанных шагов привел к ошибке, то я не рекомендую вам продолжать следовать этим советам.
Пересчет
Теперь наступило время вызвать e2fsck для пересчета размеров и контрольных сумм.
| Я использую e2fsck версии 1.18. Если у вас другая версия, то, возможно, ее параметры или сама работа с программой могли измениться. |
Если вы точно знаете, что у вас НЕ было файлов с нулевой длиной, то вы можете сделать следующее: (см. ниже); и пропустить все остальное (Вы, конечно, можете не использовать параметр y, но вам придется вручную отвечать на все вопросы - это может занять длительное время.).
| # e2fsck -f -y /dev/hdy1 > e2fsck.out 2>&1 |
Если же вы хотите восстановить файлы с нулевой длиной, то вам надо ответить n на все вопросы об удалении записей и y на все остальные.
Скопируйте следующие 7 строк в файл "e2fsck-wrapper".
| #!/usr/bin/expect -f set timeout -1 spawn /sbin/e2fsck -f $argv expect { "Clear? " { send "n" ; exp_continue } "? " { send "y" ; exp_continue } } |
Запустите скрипт.
| # ./e2fsck-wrapper /dev/hdy1 > e2fsck.out 2>&1 |
Просмотрите файл "e2fsck.out", чтобы узнать, что сообщил e2fsck
о вашем разделе.
Последние коррективы
Если в разделе Разд. Пересчет вы решили, что хотите восстановить файлы с нулевой длиной, то тут у вас возникла проблема - дело в том, что у этих файлов не очищено время удаления, а количество ссылок установлено в 0. Это означает, что e2fsck при каждом запуске будет предлагать удалить (очистить) данные файлы.
Самое простое - скопировать всю структуру каталогов в другое место (возможно, и на этот же раздел), и затем удалить старую структуру каталогов. В противном случае вам придется отыскать эти inode и исправить их при помощи debugfs.
Теперь, если все прошло хорошо, все должно было прийти в исходное состояние (которое было до удаления файлов). Так, по-крайней мере, случилось у меня, и подтвердилось в процессе испытания этих советов при написании данного документа. Убедитесь в том, что вы полностью выполнили все условия, описанные в разделе Разд. Обязательные условия.
Приготовления
Отключите раздел, на котором находились удаленные файлы. Назовем этот раздел /dev/hdx1:
| # umount /dev/hdx1 |
Узнайте размер /dev/hdx1 в блоках командой:
| # fdisk -l /dev/hdx |
Теперь для дальнейшей работы вам понадобится дополнительный раздел того же размера, что и /dev/hdx1. Предположим, что у вас есть пустой жесткий диск /dev/hdy:
| # fdisk /dev/hdy |
Создайте на нем раздел того же размера, что и /dev/hdx1. Здесь и ниже размер - это размер раздела /dev/hdx1 в блоках (каждый блок - это 1024 байта), который вы узнали ранее.
| Я использую fdisk версии 2.10f. Если вы используете другую версию fdisk, то работа с ней может различаться. |
| fdisk: n |
Теперь скопируем содержимое исходного раздела на новый диск:
| # dd if=/dev/hdx1 of=/dev/hdy1 bs=1k |
Это может занять дительное время, в зависимости от размера раздела. Вы можете ускорить процесс, увеличив размер блока bs, но вам придется сделать его таким, чтобы раздел состоял из целого количества этих блоков.
С этого момента мы будем работать только с этой копией исходного раздела, чтобы мы всегда могли откатиться назад, если что-то пойдет не так.
Ссылки
Мини-HOWTO: Восстановление файлов в Ext2fs, версия 1.3
Aaron Crane
Дизайн и Реализация файловой системы Second Extended, http://e2fsprogs.sourceforge.net/ext2intro.html
RИmy Card, Laboratoire MASI--Institut Blaise Pascal
Theodore Ts'o, Massachussets Institute of Technology
Stephen Tweedie, University of Edinburgh
Исходные тексты ядра версии 2.2.16
linux/include/linux/ext2_fs.h
linux/fs/ext2/namei.c
Что такое "сервер факсовой печати"?
Сервер факсовой печати - это набор нескольких программ: efax и сервер печати, объединенные таким образом, что посылка факса с компьютера превращается в посылку распечатки на принтер.
Как его установить?
Установка efax в качестве сервера факсовой печати включает в себя несколько задач. Я решал их несколько раз и собрал весь опыт в этом mini-HOWTO, так что комментарии только приветствуются (). Я описываю здесь задачи и их решения. Вот все инструкции в двух словах:
Проверьте, что у вас установлен пакет efax.
На системах, основанных на RPM, это будет команда 'rpm -qv efax'.
Вы можете взять исходные тексты efax с серверов sunsite и redhat: ftp://sunsite.unc.edu/pub/Linux/apps/serialcomm/fax/efax08a.tar.gz или пакет rpm: ftp://ftp.redhat.com/pub/redhat/redhat-4.2/i386/RedHat/RPMS/efax-0.8a-3.i386.rpm
В документации efax отсутствует двоеточие в конце записи printcap.
Решение: Добавьте следующую запись в /etc/printcap:
Как послать факс с сервера?
Вам нужно указать опции -Pfax и -J
Используйте одну из команд:
Linux simple fax printer server mini-HOWTO (faxsrv-mini-HOWTO)
Erez Strauss
erez@newplaces.com
Перевод: Павел Гашев, ASPLinux
Этот документ в деталях описывает быстрый способ установки факс-сервера в системе Linux. Возможности факса становятся доступны для пользователей сервера и сети.
Пользователям Caldera и LPRng
LPRng - это программное обеспечение, управляющее печатью, но использующее другой способ поддержки управляющего файла.
Luca Montecchiani обнаружил и исправил эту проблему. В файле /usr/bin/fax
нужно изменить две строки cfile=... (с номерами 586,587)
| # Исправлено для работы с пакетом LPRng # Luca Montecchiani (08/11/97 m.luca@usa.net) if [ !-z "$CONTROL_FILE" ] then cfile=`cat tail -1 lock` cfile=`cat $cfile` else cfile=$CONTROL_FILE fi |
Последняя версия и как связаться с автором
Последняя версия этого файла находится по адресам:
| http://www.newplaces.com/linux/faxsrv/faxsrv-mini-HOWTO.sgml http://www.newplaces.com/linux/faxsrv/faxsrv-mini-HOWTO.html http://www.newplaces.com/linux/faxsrv/faxsrv-mini-HOWTO.txt http://www.newplaces.com/linux/faxsrv/faxsrv-mini-HOWTO.info |
Вы можете связаться со мной:
| Erez Strauss erez@newplaces.com http://www.newplaces.com/linux/ http://www.newplaces.com/ Phone: +972 52 739737 Fax: +972 9 954 3034 |
