Восстановление упавшей ФС

  Так сложились звезды, что стал зависать у меня домашний сервачок. Да зависать намертво. Ну я его ресет, да ресет.. Вариантов то больше нет. Но после очередного ресета он перестал появляться в сети. Подключив монитор, я узрел его жалостливые крики о том что не откуда грузиться и мне бы хорошо INSERT SYSTEM DISK AND PRESS ENTER. Времени разбираться не было, поэтому я наскоро собрал замену, а вот руки посмотреть тот хард дошли только сейчас:

testbed# mount /dev/ad1s1a /mnt/
mount: /dev/ad1s1a : Operation not permitted
testbed# fsck /dev/ad1s1a
fsck: Could not determine filesystem type

Как же быть, что же делать?!



На самом деле тот факт, что на диске присутствуют слайсы и партиции уже обнадеживает. Для самоуспокоения можно посмотреть мнение fdisk и bsdlabel:

testbed# fdisk /dev/ad1
******* Working on device /dev/ad1 *******
parameters extracted from in-core disklabel are:
cylinders=77542 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=77542 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 36852417 (17994 Meg), flag 80 (active)
        beg: cyl 256/ head 0/ sector 0;
        end: cyl 1023/ head 7/ sector 7
The data for partition 2 is:
sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX)
    start 36853110, size 41287050 (20159 Meg), flag 0
        beg: cyl 1023/ head 255/ sector 63;
        end: cyl 1023/ head 15/ sector 63
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
testbed# bsdlabel /dev/ad1s1
# /dev/ad1s1:
8 partitions:
#          size     offset    fstype   [fsize bsize bps/cpg]
  a:    1048576          0    4.2BSD     2048 16384     8
  b:    4126352    1048576      swap
  c:   36852417          0    unused        0     0     # "raw" \
\ part, don't edit
  d:    4159488    5174928    4.2BSD     2048 16384 28552
  e:    1048576    9334416    4.2BSD     2048 16384     8
  f:   26469425   10382992    4.2BSD     2048 16384 28552

Для начала надо сделать рабочую и резервную копии раздела.

Попутно проверим, остались ли на партиции данные об ФС и подготовим рабочий образ для дальнейших операций.

testbed# dd if=/dev/ad1s1a of=/usr/ad1s1a.img
testbed# cp /usr/ad1s1a.img /usr/ad1s1a.img.orig
testbed# file /usr/ad1s1a.img
/usr/ad1s1a.img: Unix Fast File system [v2] (little-endian) last mounted on /, 
last written at Tue May 31 17:37:51 2011, clean flag 0, readonly flag 0, 
number of blocks 262144, number of data blocks 253815, number of cylinder 
groups 4, block size 16384, fragment size 2048, average file size 16384, 
averagenumber of files in dir 64, pending blocks to free 0, pending inodes 
to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME 
optimization
testbed# mdconfig -a -t vnode -f /usr/ad1s1a.img
md0
testbed# mount /dev/md0 /mnt/
mount: /dev/md0 : Operation not permitted

123456789_123456789_123456789_123456789-123456789-12465789-123456789-123456789-

Как видно, партиция не убита, на ней действительно есть UFS2 (aka FFS), но она 

почему то не хочет монтироваться.

Если же у вас ситуация более запущена, возможно придется выковыривать останки 

ФС с диска, в чем поможет sysutils/scan_ffs.

Одна из вероятных причин(с которой столкнулся я) - повреждение суперблока 

(160-го блока для UFS2). для таких случаем предусмотрены резервные копии 

суперблока, расположение которых выводится при создании файловой системы и 

должно быть записано в надежном месте. Если вы не знаете что такое суперблок 

и как устроена файловая система, то эту информацию стоит найти в Сети и 

ознакомиться с ней

Если же у вас такой информации нет - посыпьте голову пеплом и воспользуйтесь newfs(8)

testbed# man newfs
NEWFS(8)                FreeBSD System Manager's Manual               NEWFS(8)

NAME
     newfs -- construct a new UFS1/UFS2 file system

...

     -N      Cause the file system parameters to be printed out without really
             creating the file system.
^C
testbed# newfs -N /dev/md0
/dev/md0: 512.0MB (1048576 sectors) block size 16384, fragment size 2048
        using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes.
super-block backups (for fsck -b #) at:
 160, 262336, 524512, 786688

Какмы видим, партиция разделена на 4 "группы цилиндров" в каждой из которых 

есть копия суперблока. 



Пробуем проверить диск, принудительно используя альтернативный суперблок

testbed# man fsck_ffs
FSCK_FFS(8)             FreeBSD System Manager's Manual            FSCK_FFS(8)

NAME
     fsck_ffs, fsck_ufs -- file system consistency check and interactive
     repair

SYNOPSIS
     fsck_ffs [-BFprfny] [-b block] [-c level] [-m mode] filesystem ...

...

     -b      Use the block specified immediately after the flag as the super
             block for the file system.  An alternate super block is usually
             located at block 32 for UFS1, and block 160 for UFS2.
^C
testbed# fsck_ffs -b 262336 /dev/md0
Alternate super block location: 262336
** /dev/md0
** Last Mounted on
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
SUMMARY BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? [yn] y

3430 files, 117564 used, 136251 free (771 frags, 16935 blocks, 
0.3% fragmentation)

UPDATE STANDARD SUPERBLOCK? [yn] y


***** FILE SYSTEM IS CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****
testbed# mount /dev/md0 /mnt/
testbed#

Ура! =) Починили!

Теперь у нас в наличии корректный ОБРАЗ файловой системы -  /usr/ad1s1a.img 

при необходимости производим аналогичные действия с другими партициями, очень подозрительно проверяем диск на наличие ошибок. При необходимости заменяем диск и разбиваем его так, чтобы каждая новая партиция смогла вместить в себя содержимое старой партиции, после чего переносим содержимое старых партиций на новый диск через tar, pax или dump/restore, кому как больше нравится.



О переносе данных на новый диск и работе с md-устройствами  можно почитать 

тут http://www.lissyara.su/articles/freebsd/trivia/mount_iso_images/

и тут http://www.lissyara.su/articles/freebsd/trivia/move_system_between_hard_drives/

размещено: 2011-09-14,

				последнее обновление: 2012-04-12,

				автор: FreeBSP

Alex Keda, 2012-08-25 в 18:50:34

А у Васи-то никогда в никуда не улатала какаянить табличка на сервере, или файл - раз он так смело советует не читая статьи...

Гость, 2013-04-28 в 23:22:27

У тебя видимо всё слетело,причём вместе с головой раз такой бред постоянно строчишь.

Vasya, 2014-03-15 в 5:12:23

Alex Keda, ты конченный ЕБЛАН!!!!!!!!!1111111111111

ivaniy, 2014-09-10 в 4:28:26

У меня все было похоже, но после fsck много каталогов поудаляло и файлы перенесло в лост+фаунд. А именно весь bin, etc. Поскольку ето был сервер со своими настройками и перекомпилированым ядром, а времени небыло все наново делать, то тогда использовал md для оригинального образа mdconfig -a -t vnode -f /usr/ad1s1a.img.orig, и примаунтил его таким образом: mount -t ufs -o ro,noexec /dev/md0 /mnt/[i] После етого мне удалось восстановить систему в исходное состояние

Алексей, 2015-01-16 в 23:21:42

Раздел на gmirror вылетел в аналогичную ситуацию после gpart resize и перезагрузки. Оба диска в зеркале оказались живы и здоровы, проблема в логической части. Решилось так: dd в файл, затем монтирование файла через md0 newfs на "поврежденном" разделе, его монтирование и копирование файлов со смонтированного файла. В причинах нарушения зеркала разбираться не стал, наверное resize порушил какую-то логику

Alex, 2016-06-16 в 11:57:57

Нормально, но порой теряется часть логики принятия решения. Например в команде fsck_ffs -b 262336 /dev/md0 не плохо было-бы разъяснить почему используется блок 262336, а не скажем 524512 или 786688 (или они равнозначны?)