Bad magic number in super block linux

[fail][срочно] Bad magic number in super-block while trying to open /dev/sdb1

Собственно на сервере произашла СЛУЧАЙНАЯ перезагрузка(не в той консоле ребут написал).

после этого второй раздел сервера не может подцепиться.
пишет

Bad magic number in super-block while trying to open /dev/sdb1

раздел 1 /dev/sdb1 на 500гб

testdisk показывает нормально, и файлы показывает и все остальное.
как примантировать ?
ext4 *

fsck -p /dev/sdb1
fsck from util-linux-ng 2.16.2
fsck.ext3: Bad magic number in super-block while trying to open /dev/sdb1
/dev/sdb1:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193

[/code]
дела как предлагает
[code]
e2fsck -b 8193 /dev/sdb1
e2fsck 1.41.9 (22-Aug-2009)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193

ладно, решил не мучаться, через testdisk слить нужные файлы
и переразбить хард.

Источник

How to fix bad magic number — Superblock on Linux

I’m running a dual boot system with Windows 7 and Puppy Linux Ubuntu based «Bionic» installed on a separate partition of my main drive.

Completely separate from that I have a 1TB Western Digital external USB HDD plugged in. This has errors. It’s a friends drive and has 150 movies or more on it. Windows and Linux both see the drive and the files, but they won’t open. Well a couple of the videos do load, but only play for about 10 seconds, then they stutter and stop.

I ran, under Windows, Crystal Disk Info to see if there were any bad sectors. I have attached the screenshot. I was tempted to run either Victoria, a Russian disk scanner and bad sector repair utility, or Minitool pro or HDD Regenerator. I did try a file recovery program, but abandoned that idea as it was going to take at least a full day to recover one movie. So back to square one: how to fix the drive?

Originally the drive would not read on Windows, but it would open on Linux. So I poked around to see what else I could do. I found the instruction e2fsk to test the disk under Linux. It gave me the response you see in the screenshot: that there was an error in the superblock. Hmm never heard of superblocks before. Anyways further research into the error message took me to this page.

This describes a very simple, compared to other explanations, way to repair or replace the «Superblock» thus fixing the drive problem. However, the instructions are not detailed enough for me to follow. Would you please take a look and explain in newbie-speak how can I reinstall the backup of a Superblock? My file system is NTFS and the drive does not have any OS, its simply for saving data.

1 Answer 1

The Linux e2fsck is only for checking and fixing errors in filesystem types ext2 , ext3 and ext4 . It can do nothing at all for NTFS. The Bad magic number in super-block error message basically means «I cannot find anything at all that would indicate this is an ext2/3/4 type filesystem. If you are sure this is in fact one of those filesystem types, then you should probably try one of other superblocks as an alternate starting point.»

But since you know this is a NTFS filesystem, e2fsck cannot fix it.

Your CrystalDiskInfo results indicate the disk is in bad shape: 2829 disk blocks have already been replaced by a spare location because the original block no longer works, and there seems to be 65533 more disk blocks waiting for reallocation.

The 2829 reallocated sectors are already bad enough that the «enough reallocated sectors to declare this disk as failed» limit has already been crossed, and the Current Pending Sector Count value indicates that the number of reallocated sectors is likely to increase by 65533 as soon as those failed blocks are either overwritten by the computer, or the disk itself manages to successfully read them even once.

If 2829 reallocated sectors is enough for the manufacturer to declare the disk as bad, then it is likely that 65533 more would completely overwhelm the reallocation mechanism, and the NTFS filesystem itself would have to begin tracking and avoiding the failing sectors, using its «bad clusters» mechanism. But the fact that there are already 2829 successfully reallocated sectors and 65533 more already identified as in need of reallocation indicates the failure within the disk is probably spreading, possibly quite fast.

Maybe one of the read/write heads has hit the disk surface, chipped away a bit of the magnetic material, and the resulting tiny chips are now bouncing around in the airflow inside the hard disk and occasionally getting jammed in between the read/write heads and the spinning disk, causing further damage and more loose chips. Maybe it’s something else.

The bottom line is: this disk is not likely to be fixable. Some of the data in it might yet be recoverable, but any recovered data should be stored to a different disk. Any attempts to use the failed disk may make the disk worse as a side effect, so you should not power up the disk unless you’re actually trying to recover data from it.

You should now make a honest evaluation for yourself: how much, measured in time, effort and money, are the contents of the disk worth to you? If there is something really valuable on the disk, you should consider contacting data recovery professionals instead of trying to do the recovery yourself.

Since you already know trying to access the filesystem in normal way is not going to work, you’ll need something like PhotoRec: it will read the disk from the beginning to the end, attempt to recognize anything that looks like a valid video file, and copy that to a new disk. Yes, it is going to take a long time, but you should be able to let it run on its own.

I also note that CrystalDiskInfo reports your system disk is also in a «Caution» state. I’d recommend that you get two new disks, then clone your system disk to the new disk and replace it before it gets as bad as your current problem disk now is. Then use the other new disk for recovering data from the failed disk. Depending on what exactly CrystalDiskInfo says about your old system disk, you might still be able to use it for non-critical purposes, but you should not consider it reliable any more.

Источник

Суперблок в линуксе

Что такое суперблок в Линуксе. Попробуем разобраться на примере файловой системы ext(2|3|4), которая используется в линуксе по-умолчанию. Но для начала рассмотрим несколько простых понятий

Блок файловой системы

После форматирования диска или раздела сектора на диске разделены на небольшие группы. Такая группа секторов называется блоком. Размер блока может быть разным и задается как параметр ключа команды форматирования. Например

ключ -b задает размер блока в байтах, в данном случае размер блока будет 4096 байт

Размер блока может быть разным. Это зависит от типа файловой системы

• Ext2 — 1Кб, 2Кб, 4Кб, 8Кб
• Ext3 — 1Кб, 2Кб, 4Кб, 8Кб
• Ext4 — от 1Кб до 64Кб

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

• Максимальный размер файла
• Максимальный размер файловой системы
• Производительность

Размер блока влияет на скорость чтения/записи с диска. Представим себе файл размеров в несколько сот мегабайт, который считывается с диска блоками по 1Кб. Тот же файл будет считываться быстрее если размер блока файловой системы будет 4Кб или 8Кб. Это ясно. Поэтому при форматировании имеет смысл задать блок большего размера, если планируется использовать файлы большого размера

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

Ядро Linux работает с размером блока файловой системы, а не с размером сектора диска (обычно 512 байт). Важно понимать, что размер блока файловой системы не может быть меньше размера сектора диска и всегда будет кратным ему. Также ядро ожидает, что размер блока файловой системы будет меньше или равно размеру системной страницы

Размер системной страницы можно увидеть выполнив команду

Группы блоков файловой системы

Блоки, о которых мы говорили ранее обьеденяются в группы блоков, что позитивно отражается на операциях чтения/записи так как уменьшается время чтения/записи больших обьемов данных

Файловая система EXT разбивает все доспупное пространство на группы блоков равного размера. Эти группы располагаются последовательно, одна за другой

Количество блоков в группе неизменно и может быть расчитано по формуле

Взглянем на вывод команды mke2fs

Отметим то, о чем говорили выше

• Размер блока 4096 байт
• 800 блоковых групп
• 32768 блоков в группе (8*4096)

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

Так что же такое суперблок?

Самым простым определением суперблока могло бы быть следующее утверждение

Суперблок — это блок в котором хранятся метаданные файловой системы

Аналогично тому, как i-ноды хранят метаданные о файлах, суперблок хранит метаданные о файловой ситеме. Если вдруг суперблок поврежден, то не возможно будет примонтировать файловую систему. Обычно при загрузке система проверяет суперблок и при необходимости исправляет его, что в результате приводит к корректному монтированию файловых систем

Некоторые данные, которые хранятся в суперблоке. Например

• Количество блоков в файловой системе
• Количество свободных блоков в файловой системе
• Количество i-нод в блоковой группе
• Блоки в блоковой группе
• Количество запусков файловой системы со времени последней проверки fsck
• UUID файловой системы
• Состояние файловой системы (была ли корректно размонтирована, обнаруженые ошибки и т.д.)
• Тип файловой системы
• Операционная система в которой была отформатирована данная файловая система
• Время последнего монтирования
• Время последней записи

Основная копия суперблока хранится в самой первой группе блоков. Она названа основной, потому что считывается системой в процессе монтирования файловой системы. Так как отсчет блоковых групп начинается с 0 то можно говорить о том, что суперблок хранится в начале блоковой группы 0

Суперблок весьма критичен для файловой системы. Поэтому в каждой блоковой группе есть копии суперблока. Это дает нам право думать, что поврежденный суперблок будет восстановлен всякий раз, когда это будет необходимо

Может показаться, что наличие в каждой блоковой группе резервных копий суперблока приводит к потреблению большого дискового пространства. Для этого в последних версиях систем была реализована функция «sparse_super» целью которой было создание резервных копий в группе блоков 0, 1, 3, 5, 7

Как увидеть, что хранится в суперблоке?

Для этого воспользуемся командой dumpe2fs

Еще один вывод команды показывает информацию о суперблоке

Как восстановить поврежденный суперблок?

Для начала нужно проверить файловую систему утилитой fsck

В случае если fsck обнаружила ошибку чтения суперблока можно попробовать сделать следующее:

Для начала определим где расположены резервные копии суперблока. Для этого выполняем

ключ -n говорит команде не создавать файловую систему, но показать вывод какой мог бы быть при реальном создании файловой системы

Далее восстановливаем суперблок из бекапа при помощи e2fsck

В данном случае в блоке 819200 хранится резервная копия суперблока. После применения команды пробуем снова монтировать файловую систему. Либо как вариант использовать ключ sb команды mount, который указывает на расположение копии суперблока

В данном случае считываем копию суперблока из блока 819200

Источник