Linux как восстановить superblock

Восстановление программного RAID в Linux

Просто способ восстановления программного RAID в случае сбоя одного из дисков.

Проверим состояние RAID

Personalities : [raid10] [raid1]
md2 : active raid10 sdc4[2](F) sdd4[3] sdb4[1] sda4[0]
5242795008 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
bitmap: 0/40 pages [0KB], 65536KB chunk

md0 : active raid1 sdd2[3] sdc2[2] sdb2[1] sda2[0]
511936 blocks super 1.0 [4/4] [UUUU]

md1 : active raid10 sdd1[3] sda1[0] sdb1[1] sdc1[2]
614136832 blocks super 1.1 512K chunks 2 near-copies [4/4] [UUUU]
bitmap: 3/5 pages [12KB], 65536KB chunk

unused devices:

В данном примере видим, что диск /dev/sdc4 помечен как сбойный (F) (Failed)

Удаляем диск из RAID

mdadm /dev/md2 —remove /dev/sdc4

Сбрасываем Superblock:

mdadm —zero-superblock /dev/sdc4

Добавляем обратно:

mdadm /dev/md2 —add /dev/sdc4

Удалил суперблок. Всё?

К ПК под Debian 10 подключен SATAIII HDD, извлеченный из NAS Synology. Видится как:

blkid /dev/sdd1: UUID=". " TYPE="linux_raid_member" PARTUUID=". " /dev/sdd2: UUID=". " TYPE="linux_raid_member" PARTUUID=". " /dev/sdd3: UUID=". " UUID_SUB=". " LABEL="NAME:3" TYPE="linux_raid_member" PARTUUID=". " /dev/md127: LABEL=". " UUID=". " TYPE="ext4"

Всё отлично работало и т.п. Но затем, в суете ошибся буквой и удалил: mdadm —zero-superblock /dev/sdd3

Теперь диск не собирается:

blkid /dev/sdd1: UUID=". " TYPE="linux_raid_member" PARTUUID=". " /dev/sdd2: UUID=". " TYPE="linux_raid_member" PARTUUID=". " /dev/sdd3: PTTYPE="dos" PARTUUID=". "

Посмотрел копии суперблока:

mkfs -t ext4 -n /dev/sdd3 mke2fs 1.44.5 (15-Dec-2018) Found a dos partition table in /dev/sde3 Proceed anyway? (y,N) y Creating filesystem with 487173396 4k blocks and 121798656 inodes Filesystem UUID: . Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848

fsck -b 32768 /dev/sdd3 fsck from util-linux 2.33.1 e2fsck 1.44.5 (15-Dec-2018) fsck.ext2: Bad magic number in super-block while trying to open /dev/sdd3 The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 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 or e2fsck -b 32768 Found a dos partition table in /dev/sdd3

Подскажите, что ещё попробовать? Или всё? Данные в целом то скопировал (до ошибки с удалением), но там настройки кое-какие остались. Не критично, но вдруг какой-то простой путь есть?

mexx ★
26.06.21 22:33:48 MSK

Как ты с таким радиусом кривизны рук вообще функционируешь? Пользуйся /dev/disk/by-id/ вместо /dev/sd? , накосячить будет несколько труднее.

anonymous
( 26.06.21 22:54:29 MSK )
Ответ на: комментарий от anonymous 26.06.21 22:54:29 MSK

Функционирую с трудом, жара.

Поправил, я ж сюда не онлайн из консоли копирую.

mexx ★
( 26.06.21 23:03:50 MSK ) автор топика
Ответ на: комментарий от anonymous 26.06.21 22:54:29 MSK

Он не спрашивает твое мнение про его руки, он спрашивает чому бекапные суперблоки не работают.

Мне тоже интересно, т.к. опыта нет.

anonymous
( 26.06.21 23:03:51 MSK )

e2fsck -b номер_бэкапного_суперблока

тебе же белым по чёрному написано что делать, прям в выхлопе fsck. Перебери все что видишь, может какой сработает.

Stanson ★★★★★
( 26.06.21 23:06:59 MSK )
Последнее исправление: Stanson 26.06.21 23:08:38 MSK (всего исправлений: 2)

Ответ на: комментарий от Stanson 26.06.21 23:06:59 MSK

Перебором? Ладно, попробую.

mexx ★
( 26.06.21 23:11:08 MSK ) автор топика
Ответ на: комментарий от mexx 26.06.21 23:11:08 MSK

Ну да. Если повезёт, то сработает. Бывало почти все перебирать приходилось. Если не повезёт — значит ты затёр не только суперблок, или затёр все суперблоки.

Stanson ★★★★★
( 26.06.21 23:13:39 MSK )
Последнее исправление: Stanson 26.06.21 23:15:28 MSK (всего исправлений: 1)

Ответ на: комментарий от Stanson 26.06.21 23:13:39 MSK

Была выполнена 1 ошибочная команда: mdadm —zero-superblock /dev/sdd3

mexx ★
( 26.06.21 23:21:57 MSK ) автор топика

Ты понимаешь разницу между суперблоком mdadm и суперблоком файловой системы на RAID массиве?

anonymous
( 26.06.21 23:23:19 MSK )
Ответ на: комментарий от anonymous 26.06.21 23:23:19 MSK

Ты понимаешь разницу между суперблоком mdadm и суперблоком файловой системы на RAID массиве?

Здесь соглашусь — не совсем понимаю. Подскажешь?

mexx ★
( 26.06.21 23:28:52 MSK ) автор топика
Ответ на: комментарий от mexx 26.06.21 23:28:52 MSK

Суперблок — это служебная область, в которой расположена информация о параметрах контейнера (структуры) которую описывает суперблок.

Ты выполнил команду

--zero-superblock If the device contains a valid md superblock, the block is over-written with zeros. With --force the block where the superblock would be is over-written even if it doesn't appear to be valid.

Которая стирает служебную информацию mdadm с параметрами принадлежности диска к RAID массиву.

RAID массив — это контейнер на котором ты уже создаёшь другой контейнер — файловую систему.

Т.е. в начале на основе суперблоков MDADM на диске ты собираешь контейнер RAID массива, а потом в RAID массиве создаёшь новый контейнер — файловую систему.

Суперблок файловой системы ты не трогал.

А лишь удалил информацию с диска о том как его подключать к RAID массиву, точнее какой частью RAID массива он является.

mkfs -n тебе не поможет.

Точнее поможет только в случае, если диск с которого ты стёр суперблок mdadm являлся частью RAID 1.

Тогда можно поискать начало файловой системы и попытаться её смонтировать,

anonymous
( 26.06.21 23:34:24 MSK )
Ответ на: комментарий от mexx 26.06.21 23:28:52 MSK

В RAID массиве какого уровня состоял /dev/sdd3?

Если это не RAID0 и остальные диски массива целы, то ты можешь попробовать собрать RAID массив принудительно:

mdadm --verbose --assemble --force /dev/mdX .

С указанием далее оставшихся дисков RAID массива.

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

Но я тебе не гарантирую, что этим ты не повредишь данные RAID массива на оставшихся дисках.

Но попробовать собрать RAID массив из оставшихся дисков тебе видимо всё же придётся.

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

Если файловая система будет монтировать — сделай так же на твоих реальных дисках.

anonymous
( 26.06.21 23:43:33 MSK )
Ответ на: комментарий от anonymous 26.06.21 23:43:33 MSK

В RAID массиве какого уровня состоял /dev/sdd3?

Сам диск в NAS ни в каком RAID не состоял. Но synology каждый отдельный (basic) диск пилят на 3 раздела и объединяют их в RAID linear, насколько я понимаю. Система, подкачка, данные.

mexx ★
( 27.06.21 00:28:14 MSK ) автор топика
Последнее исправление: mexx 27.06.21 00:28:26 MSK (всего исправлений: 1)

Ответ на: комментарий от mexx 26.06.21 23:21:57 MSK

Эта команда, как уже объяснил другой пассажир, ничего с самой ФС не делает.

Stanson ★★★★★
( 27.06.21 00:34:33 MSK )
Ответ на: комментарий от Stanson 27.06.21 00:34:33 MSK

Отлично. Есть предложения? )

mexx ★
( 27.06.21 00:37:08 MSK ) автор топика
Ответ на: комментарий от mexx 27.06.21 00:37:08 MSK

Суперблок нашёлся? Если нет — то разве что тяжёлой артиллерией типа binwalk пройтись.

Stanson ★★★★★
( 27.06.21 00:40:04 MSK )
Ответ на: комментарий от mexx 27.06.21 00:28:14 MSK

Сам диск в NAS ни в каком RAID не состоял. Но synology каждый отдельный (basic) диск пилят на 3 раздела и объединяют их в RAID linear, насколько я понимаю.

Ты хоть сам понимаешь что сейчас казал?

… ни в каком RAID не состоял … пилят на 3 раздела … объединяют их в RAID linear …

Так всё же сам диск был разбит на разделы и потом эти разделы были частью RAID linear, что является RAID0 походу.

В общем, сколько дисков, именно устройств жёстких дисков в NAS и какая из них собрана конфигурация?

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

Если там всего один диск, то делить его на разделы допустим можно, но зачем из разделов одного диска создавать RAID Linear (RAID 0) не понятно.

Если там два и более жёстких диска и на каждом создано 3 раздела, а потом эти разделы объединены в RAID Lenear (RAID0) — это уже другое.

disk0 partition 1 и disk1 partition 1 — это один RAID массив
disk0 partition 2 и disk1 partition 2 — это другой RAID массив
disk0 partition 3 и disk3 partition 1 — это третий RAID массив

Так какая у тебя исходная ситуация.

Пока ты это не напишешь что делать — не понятно.

anonymous
( 27.06.21 00:44:01 MSK )
Ответ на: комментарий от mexx 27.06.21 00:37:08 MSK

Если у тебя на дисках в NAS были созданы разделы и попарно разделы на дисках объединены в RAID 0, то дело труба.

Тебе нужно пробовать собирать RAID руками через команду force.

anonymous
( 27.06.21 00:46:54 MSK )
Ответ на: комментарий от anonymous 27.06.21 00:44:01 MSK

Ты хоть сам понимаешь что сейчас казал?

В целом да. Что смущает? В NAS несколько дисков (физических устройств). DSM (ОС) допускает создание нескольких типов RAID для этих устройств. Или использование каждого устройства отдельно как basic. И на NAS RAID из устройств пользователь НЕ создавал. Что, однако, совершенно не мешает системе самостоятельно разбить каждое basic-устройство на 3 раздела и создать RAID в системных целях. Почитал — там зеркало для всех системных разделов КАЖДОГО диска и, насколько я понимаю, аналогично для разделов подкачки. А вот разделы с данными (если ты сам не создавал какой-то RAID) живут каждый сам по себе. Там своя synology-схема, смесь RAID и LVM, похоже. Правильная схема или нет — смысл с ней спорить?

Закончилось чем. Добрался до NAS, вставил проблемный диск, система его нашла, но сказала, что он не инициализирован. От инициализации я конечно отказался и диск вытащил. Но, очевидно, система с ним что-то сделала, так как после повторного подключения к ПК (хотел попробовать совет с force) диск внезапно определился как:

blkid /dev/sdd1: UUID=". " TYPE="LVM2_member" PARTUUID=". "

И стал доступен для монтирования )

За подсказку о разнице между суперблоком mdadm и суперблоком файловой системы на RAID массиве — спасибо.

mexx ★
( 27.06.21 23:21:02 MSK ) автор топика

To repair the filesystem using alternate superblock, run

fsck.ext4 -p -b superblock -B blocksize device

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

 ext4 0 0 1 60801 47 46 976771072 [BpiR1] superblock 32768, blocksize=4096 [BpiR1] superblock 98304, blocksize=4096 [BpiR1] superblock 163840, blocksize=4096 [BpiR1] superblock 229376, blocksize=4096 [BpiR1] superblock 294912, blocksize=4096 [BpiR1] superblock 819200, blocksize=4096 [BpiR1] superblock 884736, blocksize=4096 [BpiR1] superblock 1605632, blocksize=4096 [BpiR1] superblock 2654208, blocksize=4096 [BpiR1] superblock 4096000, blocksize=4096 [BpiR1] >fsck.ext4 -p -b 163840 -B 4096 /dev/sda1

супер блок восстановился правда, автоматом командой
mount /mnt/sda1 /dev/sda1
перестал монтироваться, все равно не мог определить тип файловой системы, хотя GParted и встроенная программа gnome-disks прекрасно определяет файловую систему так работает:
mount /mnt/sda1 /dev/sda1 -t ext4

sap78 ★
( 29.06.21 23:48:32 MSK )
Последнее исправление: sap78 29.06.21 23:53:08 MSK (всего исправлений: 1)

Форум русскоязычного сообщества Ubuntu

Страница сгенерирована за 0.129 секунд. Запросов: 23.

Сайт
Об Ubuntu
Скачать Ubuntu
Семейство Ubuntu
Новости

Форум
Помощь
Правила

Документация
Пользовательская документация
Официальная документация
Семейство Ubuntu
Материалы для загрузки
Совместимость с оборудованием
RSS лента

Сообщество
Наши проекты
Местные сообщества
Перевод Ubuntu
Тестирование
RSS лента

Восстановление Ext4 Superblock linux.

Ваш компьютер не загружается, проверка файловой системы говорит Вам что у Вас имеется bad superblock, и Вы не видите решения проблемы.

В данном руководстве используется файловая система ext4. Простейший путь для решения проблем с загрузкой компьютера, это использовать Parted Magic. Загружаемся в него с загрузочной флешки. Подробнее, как это сделать, ищем в интернете.

1. Для начала, необходимо найти наш сломанный раздел командой:

# fdisk -l

Данная команды выведет список всех разделов на всех дисках вашего компьютера. Для восстановления потерянного раздела можно воспользоваться утилитой Testdisk. Testdisk содержится в дистрибутиве Parted Magic, и на их сайте есть хороший раздел помощи.

2. Получив список разделов ищем проблемный superblock, запустим проверку файловой системы, заменив xxx на номер раздела. Возможно необходимо изменить тип файловой системы ext4 на ext3, или ext2:

# fsck.ext4 -v /dev/xxx

Если ваш superblock поврежден, вывод команды будет примерно следующего содержания:

fsck /dev/sda5 fsck 1.41.4 (27-Jan-2009) e2fsck 1.41.4 (27-Jan-2009) fsck.ext4: Group descriptors look bad. trying backup blocks. fsck.ext4: Bad magic number in super-block while trying to open fsck /dev/sda5 fsck 1.41.4 (27-Jan-2009) e2fsck 1.41.4 (27-Jan-2009) fsck.ext4: Group descriptors look bad. trying backup blocks. fsck.ext4: Bad magic number in super-block while trying to open /dev/sda5 The superblock could not be read or does not describe a correct ext4 filesystem. If the device is valid and it really contains an ext4 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

3. Попробуем найти где находится бекап superblock.

# mke2fs -n /dev/xxx

Вывода данной команды должен показать список бекапов:

Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

4. Наконец восстановим superblock из бекапа, опять же заменив xxx на номер вашего раздела, и block_number на первый superblock в списке бекапов.

# e2fsck -b block_number /dev/xxx

5. Перезагружаем компьютер и ваш superblock должен быть восстановлен. Если этого не произошло, попробуйте повторить шаги, но восстанавливать со следующего бекапа.