LINUX.ORG.RU
ФорумAdmin

Восстановление ФС на mdadm с RAID5

 , ,


0

1

Всем привет! Долго и успешно крутился NAS на OMV с RAID5 из 5 дисков по 3 Тб, где-то лет 6-7. Массив собран на mdadm, ФС была EXT4. Диски WD RED по 3 Тб (один Purple), парковка была отключена сразу. Вышел из строя один Red, причем неожиданно, по SMART все ок. Раскручивается, распарковывает головы, паркует назад, дораскручивается, снова выводит головы, на парковку и отключается. Но это не суть. Тратить бабки на БУ Red не хотелось, решил уменьшить массив на 1 диск. Занято было около 60% доступного места. Собственно почитав, сделал это через mdadm –attach. По итогу один диск был выведен из массива, стал как spare и заменил собой вышедший из строя. Массив собрался нормально, состояние clean из 4 дисков. Но что-то произошло с ФС на массиве, хотя такие танцы вроде можно проворачивать с EXT4, в отличии от XFS. Причем отпала она, как мне кажется, еще до всех этих фокусов.

По итогу имеется массив /dev/md127, тут все ровно, в интерфейсе OMV ФС значится, но тоже как /dev/md127, что вроде неправильно. По идее она должна быть md0 или md1. К сожалению я с никсами больше на ВЫ, так что не совсем понимаю, как это восстановить.

Инфа:

root@nas:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [r
aid0] [raid1] [raid10]
md127 : active raid5 sdd[4] sda[0] sdb[2] sdc[3]
      8790795264 blocks super 1.2 level 5, 512k chunk, algorith
m 2 [4/4] [UUUU]

root@nas:~# blkid
/dev/sda: UUID="8370f378-941e-4e75-7506-41bbe5ab6163" UUID_SUB=
"0b07c019-3782-39ac-d40f-88a82aed28a2" LABEL="NAS:RAID5" TYPE="
linux_raid_member"
/dev/sdd: UUID="8370f378-941e-4e75-7506-41bbe5ab6163" UUID_SUB=
"9ca68a5a-c78f-4190-c9cd-f0f6cb4499f8" LABEL="NAS:RAID5" TYPE="
linux_raid_member"
/dev/sdc: UUID="8370f378-941e-4e75-7506-41bbe5ab6163" UUID_SUB=
"358b1bf8-e191-224a-a3ab-fffe605f094c" LABEL="NAS:RAID5" TYPE="
linux_raid_member"
/dev/sdb: UUID="8370f378-941e-4e75-7506-41bbe5ab6163" UUID_SUB=
"abb15971-0fe3-7a5e-f208-698465a99954" LABEL="NAS:RAID5" TYPE="
linux_raid_member"
/dev/md127: LABEL="VOLUME" UUID="822dfe6d-2624-4d70-ac1c-be8aca
7c28fe" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sde1: UUID="9681-9555" BLOCK_SIZE="512" TYPE="vfat" PARTUU
ID="1aa5f2fa-eec7-410b-9487-f6217fa4989b"
/dev/sde2: UUID="6eb17f20-186f-4132-b981-75eca81abf0e" BLOCK_SI
ZE="4096" TYPE="ext4" PARTUUID="3360523e-4190-4bb8-bff5-5013663
b8c48"
/dev/sde3: UUID="877624e6-00f9-4873-9bc7-07b8abe24aa1" TYPE="sw
ap" PARTUUID="4804021f-b1d0-41b1-99e0-a2ee76c20db7"
 
Version : 1.2
     Creation Time : Wed Jan  1 22:59:33 2014
        Raid Level : raid5
        Array Size : 8790795264 (8383.56 GiB 9001.77 GB)
     Used Dev Size : 2930265088 (2794.52 GiB 3000.59 GB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Sat Jun 29 11:53:43 2024
             State : clean
    Active Devices : 4
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 512K

Consistency Policy : resync

              Name : NAS:RAID5
              UUID : 8370f378:941e4e75:750641bb:e5ab6163
            Events : 35969

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       4       8       48        1      active sync   /dev/sdd
       2       8       16        2      active sync   /dev/sdb
       3       8       32        3      active sync   /dev/sdc

Прошу помочь и сильно не ругать ))

Перемещено hobbit из general



Последнее исправление: SysF (всего исправлений: 1)

А как ты уменьшал RAID массив?

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

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

Если что - бэкап тебе в помощь.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

Уменьшал через mdadm –assemble и указав диски /dev/sd[a,b,c,d].

А как проверить? Я даже не понимаю, как она и куда подключена… /dev/md127 вроде сам массив… Как посмотреть?

уменьшить ext4 до минимального размера, который поместится на новое блочное устройство, после уменьшения массива;

Как? 😅

Проверять FS с помощью fsck?

уменьшить число дисков в массиве;

Так он пересобрался с 5 до 4 дисков.

увеличить размер файловой системы.

Опять же как )))

SysF
() автор топика

Собственно почитав, сделал это через mdadm –attach. По итогу один диск был выведен из массива, стал как spare и заменил собой вышедший из строя.

Как именно?

Сдаётся мне, либо ты пролюбил все данные, либо одно из двух.

intelfx ★★★★★
()
Ответ на: комментарий от Dimez

Это сборка массива, а не уменьшение. Естественно, что ты затёр все метаданные прошлого массива.

Не уверен. Тогда бы просто создало новый массив из 4 дисков. Однако оно 2 суток мучалось (скорость была около 18 мб/с), получился массив из 4 дисков в состоянии degraded (2 диска не было, того, что умер). Пятый диск вывело из массива, сделало spare и заменило им отсутствующий 2 диск на скорости уже ~85 мб/с примерно за 12-15 часов. Это совершенно не похоже на создание чистого нового массива.

SysF
() автор топика

В настоящий момент с данными ничего сделать нельзя поскольку ты разобрал раид. Гарантированных рецептов тут нет, метаданные уничтожены (если только ты их в /etc/mdadm.conf не оставил)

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

anonymous
()
Ответ на: комментарий от targitaj

mdadm не работает с ФС. Ты как ФС уменьшил ПЕРЕД уменьшением блочного устройства, на котором была эта ФС?

Так, попутал… Вот так я делал, заскринил. Не знаю как тут крепить фото, так что внешней ссылкой. https://ibb.co/qmXFycf

SysF
() автор топика
Ответ на: комментарий от anonymous

если только ты их в /etc/mdadm.conf не оставил

Он у OMV какой-то дефолтный. Настройки откуда то из другого места подтягивает, насколько я понимаю.

Вот внутри:

# This file is auto-generated by openmediavault (https://www.openmediavault.org)
# WARNING: Do not edit this file, your changes will get lost.
 
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file
.
#
 
# by default, scan all partitions (/proc/partitions) for MD sup
erblocks.
# alternatively, specify devices to scan, using wildcards if de
sired.
# Note, if no DEVICE line is present, then "DEVICE partitions"
is assumed.
# To avoid the auto-assembly of RAID devices a pattern that CAN
'T match is
# used if no RAID devices are configured.
DEVICE partitions
 
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
 
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
 
# definitions of existing MD arrays
ARRAY /dev/md/NAS:RAID5 metadata=1.2 name=NAS:RAID5 UUID=8370f3
78:941e4e75:750641bb:e5ab6163
SysF
() автор топика
Ответ на: комментарий от anonymous

Как и какой командой можно посмотреть присутствие файловых систем на блочном устройстве? А то так какое-то гадание получается… )) Массив получается /dev/md127

SysF
() автор топика
Ответ на: комментарий от SysF

Уменьшал через mdadm –assemble и указав диски /dev/sd[a,b,c,d].

А должен был через

mdadm --grow --raid-devices=4 /dev/md0

А как проверить?

Что? Размер файловой системы? Это уже не важно, если ты не сделал её уменьшение, то по сути просто отрезал кусок файловой системы. Почти как в случае, если бы ты с помощью утилиты fdisk удалил раздел и на его месте создал новый, только меньшего размера. Только в случае mdadm assembly ты ещё перетасовал куски файловой системы.

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

В случае RAID5 у тебя stripped массив. Это значит, что при 5 дисках на первый диск у тебя данные записываются так:

|   disk0  |   disk0  |   disk0  |   disk0  |   disk0  |
|----------|----------|----------|----------|----------|
| block_a0 | block_b0 | block_c0 | block_d0 | summ_00  |
| block_a1 | block_b1 | block_c1 | summ_01  | block_e1 |
| block_a2 | block_a2 | summ_02  | block_d2 | block_e2 |
| block_a3 | summ_03  | block_c3 | block_d3 | block_e3 |
| summ_04  | block_a4 | block_c4 | block_d4 | block_e4 |

Т.е. записываемые данные разбиваются на блоки (чанки) и каждый последующий блок записывается на следующий диск, по очерёдности на один из дисков в массиве записывается контрольная сумма группы чанков одной порции записи. И если ты просто собрал новый raid5 из меньшего числа дисков, то теперь у тебя вместо записи с контрольной суммой драйвер mdadm будет считать, что у тебя там данные. А не информация для восстановления.

|   disk0  |   disk0  |   disk0  |   disk0  |
|----------|----------|----------|----------|
| block_a0 | block_b0 | block_c0 | summ_00  |
| block_a1 | block_b1 | summ_01  | block_d1 |
| block_a2 | summ_02  | block_c2 | block_d2 |
| summ_03  | block_b3 | block_c3 | block_d3 |
| block_a4 | block_a4 | block_c4 | summ_04  |

Как?

resize2fs 

С соответствующим параметром, в котором ты указываешь новый размер файловой системы, меньший.

Проверять FS с помощью fsck?

Да, но если ты хочешь окончательно потерять данные - можешь сделать.

Так он пересобрался с 5 до 4 дисков.

Он у тебя не пересобрался. А ты ему сказал собери мне из 4 дисков массив. При правильной пересборке, команду я тебе привёл как ты должен был сказать mdadm, что уменьши число дисков в массиве 5 до 4. И при этом действии он бы у тебя перераспределил данные, т.е. чанки (chunks) по дискам и в правильные места положил контрольные суммы для восстановления, а сейчас у тебя каша. Из чанков и контрольных сумм.

И то, что blkid показывает, что у тебя там есть ext4 - это потому, что первые 3 чанка целые и интерпретируются как данные. А 4-чанк, который до этого был чанком (блоком) с данными сейчас интерпретируется драйвером mdadm как чанк с контрольными суммами.

Сейчас по хорошему тебе надо сходить купить новые 4 диска, склонировать посекторно на них данные и далее пробовать собирать RAID массив заново с 5-ю дисками.

Если у тебя один из дисков отсутствует, то ты должен был собрать RAID массив с указанием правильной последовательности дисков, написав вместо отсутствующего диска слово missing.

kostik87 ★★★★★
()
Ответ на: комментарий от SysF

Ну тут, уже, скорее всего, данные тютю.

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

kostik87 ★★★★★
()
Ответ на: комментарий от SysF

grow это правильно. Только если ты не удалил вышедший диск из строя из массива соответствующими командами, а просто отключил его, то тут ХЗ вообще что получилось.

И команды на уменьшение размера файловой системы не видно.

Ты просто отрезал часть файловой системы и всё.

Поздравляю, у тебя теперь есть 9 Тб свободного пространства, как только пересоздашь файловую систему.

kostik87 ★★★★★
()
Ответ на: комментарий от SysF

На этом скрине показывается, что RAID массив онлайн и далее с /dev/md1 (/dev/md127) считывается суперблок файловой системы.

В ext4 есть несколько копий суперблоков и первая копия супеблока находится с начала блочного устройства.

Стандартный размер чанка (блока) RAID массива 64 Кб.

При массиве RAID5 из 5-ти дисков на первых 4-х дисках находятся чанки (блоки) с данными, на 5-ом диске чанк (блок) с контрольной суммой.

Сейчас у тебя сохранились 3 чанка из 4-х. Т.е. от начала файловой системы у тебя остались доступны 192Кб данных. В эти 192Кб влезает первая копия суперблока. И поэтому у тебя отображается, что когда-то в твоём RAID массиве у тебя была Ext4.

Посмотрел, у тебя размер чанка 512 Кб. Так что можешь радоваться, у тебя сохранилось 1.5 Мб прежних данных.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

grow это правильно. Только если ты не удалил вышедший диск из строя из массива соответствующими командами, а просто отключил его, то тут ХЗ вообще что получилось.

Ну тот вышедший из строя диск уже был в статусе removed, так что хз.

SysF
() автор топика
Ответ на: комментарий от kostik87

На этом скрине показывается, что RAID массив онлайн и далее с /dev/md1 (/dev/md127) считывается суперблок файловой системы.

ФС там пишет md127, просто подрезает в интерфейсе. Но md127 же сам массив, так быть не должно…

SysF
() автор топика
Ответ на: комментарий от anonymous

Плату снимал? Контакты протирал?

Да, все почистил, промыл, толку ноль. Пробовал к терминалу диска подцепиться через USB-TTL (ch341a) переходник, на любых скоростях, ничего не выдает. Один раз при передергивании питания он вышел на готовность и всё. 🤷‍♂️

SysF
() автор топика

Раскручивается, распарковывает головы, паркует назад, дораскручивается, снова выводит головы, на парковку и отключается. Но это не суть.

У нас такое было один в один, когда один из блоков питания накрылся (их было два) и питания одного блока не хватало и один из дисков в момент раскрутки отключался и признавался failed. Так шо вы диск то проверте, может не в нём дело.

vtVitus ★★★★★
()
Ответ на: комментарий от vtVitus

когда один из блоков питания накрылся

К сожалению нет, тестил уже отдельно и на другом БП. Напряжения у БП в норме. Сам контроллер тоже потыкал, конденсаторы все ок, диоды и защитные диоды тоже, предохи целые, резисторы все вроде живы. Скорей всего что-то с БМГ или транслятором. При этом SMART харда до смерти был абсолютно в норме, ничем не отличается от остальных. После выхода из строя время раскрутки упало с ~5500 мс до ~800. Потом уже понял, что он этот параметр берет именно по последнему разу. С учетом, что он «дораскручивает» блины после первой парковки, вот и получается ~800 мс.

Вот похожий пример: https://www.hardmaster.info/articles/25-12-2020.html?amp

SysF
() автор топика
Ответ на: комментарий от kostik87

Учись разбираться сам.

Ну… Какая-то математическая функция… К чему она, мне так и непонятно.🤷‍♂️

Априори на форум приходят за помощью, а не чтобы пойти изучать никсы с азов и до гуру. Для этого форум не нужен. Ставь никсы, открывай книжки, гугл и вперёд. Поясни к чему это и буду знать/понимать. )) Тем более я с никсами работаю мало, только когда есть такая необходимость.

SysF
() автор топика
Ответ на: комментарий от SysF

Посмотри свой скриншот. Разу уж ты его выложил, а не нормальный текстовый файл.

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

Прочти свой вопрос и подумай какой ответ и зачем я дал.

Между прочим выводы команд прикладывать в виде фото - моветон.

kostik87 ★★★★★
()
Ответ на: комментарий от kostik87

21976988164096 + 549429248256

Это где там такие цифры?

Прочти свой вопрос и подумай какой ответ и зачем я дал.

А для чего эти «гадалки»?

Между прочим выводы команд прикладывать в виде фото - моветон.

Я же пояснил, что с моба работал и там терминал не дает полностью вывод почему-то скопировать…

SysF
() автор топика
Ответ на: комментарий от SysF

Твоих данных скорее больше нет, поскольку первое правило в оперировании дисками и стораджами - не предпринимать действий на дегрейднутых сущностях. Так что:

  1. Прогони fsck в режиме теста (без внесения изменений) с опцией -N например

  2. Бери диски и иди в контору по восстановлению данных. Может чего и помогут.

У тебя просто нет достаточной экспертизы чтобы разрулить ситуацию сейчас.

P.S.:

Априори на форум приходят за помощью

Тем более я с никсами работаю мало, только когда есть такая необходимость

Неплохая заявка на победу в специальной олимпиаде в дисциплине «вы тут все мне должны».

no-dashi-v2 ★★★
()
Последнее исправление: no-dashi-v2 (всего исправлений: 1)
Ответ на: комментарий от no-dashi-v2

Прогони fsck в режиме теста (без внесения изменений) с опцией -N например

А fsck чего? md127 сам массив… Я не понимаю, где ФС…

Бери диски и иди в контору по восстановлению данных. Может чего и помогут

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

«вы тут все мне должны»

Даже не намекал на это. Просто сразу написал, что с никсами на ВЫ и попросил помощи. А отсылать «иди учись» - в чем тогда смысл форума?

SysF
() автор топика
Ответ на: комментарий от no-dashi-v2

Хорошо, вопросы в лоб…

  1. Как посмотреть наличие ФС в массиве? /dev/md127 Через mdadm или как-то еще?
  2. Если она есть, как она монтируется? Прописывается в fstab или как? И как ей задается название? Плюс как соотносится uuid (по которым по ходу работает OMV) c устройством или ФС?

И сторонний вопрос: Может быть просто каша в конфигах в OMV? Есть смысл попробовать ее переустановить и поробовать заново зацепить массив и ФС(если она есть). К слову, OMV я около полугода назад перкустанавливал, т.к. там древняя версия 0.4 была. В новой легко зацепил массив, а потом подключил ФС, просто через её интерфейс.

SysF
() автор топика
Ответ на: комментарий от SysF

“Сам массив” это прям заклинание какое-то. Успокойся, файловая система как была на «сам массиве», так и осталась на нем. На /dev/md127. Просто его размер уменьшился с 12 ТБ до 9 ТБ. Выполни resize2fs /dev/md127. Потом fsck /dev/md127.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap
root@nas:~# resize2fs /dev/md127esize2fs 1.46.6 (1-Feb-2023)
lease run 'e2fsck -f /dev/md127' first.
 
root@nas:~# e2fsck -f /dev/md127
e2fsck 1.46.6 (1-Feb-2023)
ext2fs_check_desc: Corrupt group descriptor: bad block for inod
e bitmap
e2fsck: Group descriptors look bad... trying backup blocks...
VOLUME: recovering journal
e2fsck: unable to set superblock flags on VOLUME
 
 
VOLUME: ***** FILE SYSTEM WAS MODIFIED *****
 
VOLUME: ********** WARNING: Filesystem still has errors *******
***

root@nas:~# fsck /dev/md127
fsck from util-linux 2.36.1
e2fsck 1.46.6 (1-Feb-2023)
ext2fs_check_desc: Corrupt group descriptor: bad block for inod
e bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks..
.
VOLUME: recovering journal
fsck.ext4: unable to set superblock flags on VOLUME
 
 
VOLUME: ***** FILE SYSTEM WAS MODIFIED *****
 
VOLUME: ********** WARNING: Filesystem still has errors *******
***

Что-то не выходит…

SysF
() автор топика
Ответ на: комментарий от SysF

Ты не понимаешь ответов и не думаешь, что тебе написано.

Как посмотреть наличие ФС в массиве?

В начале определись что значит наличие фс в массиве.

Тебе уже дан комментарий, что у тебя в интерфейсе ома отображается, что на /dev/md127 есть ext4, потому, что на блочном устройстве /dev/md127 в самом начале присутствует superblock файловой системы ext4. Superblock - структура данных, которую считывает драйвер файловой системы и понимает её параметры. Либо прочие утилиты просто по типу superblock`а могут сказать к какой файловой системе он относится.

Как ты понимаешь, хотя я в этом сомневаюсь, но все же, наличие супероблока не гарантирует, что файловая система целая и даже ее наличие. Это как на темной бутылке с надписью «квас» ты не поймёшь что в ней, пока не откроешь, отольёшь содержимое, понюхаешь,может попробуешь. Может там вообще вода, пиво, что-то противное.

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

Raid массив представляет из себя блочное устройство, это значит, что данные считываются и записываются с него порциями, блоками.

В raid5 массиве есть понятие chunk`а (блока). И когда на него записываются данные то на некоторые диски записываются сами данные, а на один в группе суммарным объемом число дисков*размер блока (чанка) записывается контрольная сумма. В первой порции данных равных размеру группы контрольная сумма записывается на один диск, во-второй на третий, в третьей - на второй и так далее, это условно.

Т.е. если у тебя было 5 дисков и размер блока 512кб, то при записи на диск 512*4=2048кб данных, на первые 4 диска записались эти данные, на 5-й - контрольная сумма.

При записи следующих 2048кб (2мб) данных - на 4-й диск записалась контрольная сумма.

Если ты просто уменьшил число дисков в raid5 массиве, не уменьшив перед этим размер файловой системы, а это делается с помощью утилиты resize2fs, то у тебя просто отрезало 1/4 блочного устройства raid5.

А потом драйвер mdad для работы с raid массивами пересчитал контрольные суммы.

Он ничего не знает про файловую систему, он оперирует просто сырыми данными.

И тут две ситуации, либо у тебя от 12Тб файловой системы осталось 9Тб, а остальное отрезало.

Либо у тебя на первых трёх дисках в первых 2048кб данных от начала устройства 1536 КБ - прежние данные, а далее 512 КБ перезаписаны контрольной суммой. Далее в последующих 2048 КБ, с 2049 по 3584кб опять данные, а следующие 512 КБ перезаписаны контрольной суммой.

Если ты уменьшал raid5 до 3-х дисков, чтобы получить spare, то ситуация ещё хуже.

Контрольная сумма считается не для всей группы, а для одного из блоков (chunks) в группе.

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

Либо у тебя вообще фарш из кусков данные и контрольных сумм raid5.

Если она есть, как она монтируется

Если есть доступ к консоли - попробуй смонтировать, но сомнительно.

mkdir /tmp/md127
mount -t ext4 /dev/md127 /tmp/md127 -o ro
ls /tmp/md127

Про /etc/fstab и прочее нужно думать потом.

И как ей задается название

Точка монтирования (подключения) задаётся в /etc/fstab или прочих скриптах и файлах, используемых в омв.

Плюс как соотносится uuid (по которым по ходу работает OMV

Uuid - это идентификатор файловой системы, он читается из супероблока файловой системы.

Ещё бывают идентификаторы разделов, метки файловой системы и прочее.

В той команде я тебе на основе приведенного тобой вывода команды tune2fs -l /dev/md127 привёл как посчитать размер файловой системы по данным из супероблока.

И числа на твоём скриншоте соответствуют числам в формуле. Просто ты лентяй и не хочешь думать, а может и не можешь. Выводы самостоятельно делать не хочешь или не умеешь.

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

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

Информация тебе вся приведена. Выводы делай сам. Если не умеешь делать выводы - трать время, деньги, теряй данные.

kostik87 ★★★★★
()
Ответ на: комментарий от kostik87

Спасибо за разъеснения, теперь знаю больше! ) Про то, как распределяются данные и контрольные суммы в массивах я знаю. Вот по суперблоку не знал.

ФС уменьшалась. Перед тем, как удалить диск из массива, mdadm сказал сначала сделать уменьшение ФС, потом сделать бэкап чего-то там (сделал). А потом уже пошел процесс вывода диска, и только после его вывода он стал spare и встал вместо того дохлого.

root@nas:~# mkdir /tmp/md127
root@nas:~# mount -t ext4 /dev/md127 /tmp/md127 -o ro
mount: /tmp/md127: mount(2) system call failed: Structure needs
 cleaning.

Не вышло… Жаль.

Гуглил… Поставил TestDisk. В принципе всё видит, но некоторые файлы красные, я так понимаю битые. Есть диск на 6 Тб, подключить и думаю лучший вариант слить на него всё, а там уже разбираться.

Вот то, что увидел testdisk:


TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
 
Disk /dev/md127 - 9001 GB / 8383 GiB - CHS 2197698816 2 4
 
     Partition                  Start        End    Size in sec
>   P ext4                     0   0  1 2197698815   1  4 17581
590528 [VOLUME]
*******************************************
Disk /dev/md127 - 9001 GB / 8383 GiB - CHS 2197698816 2 4
 
     Partition                  Start        End    Size in sec
tors
  ext4                     0   0  1 2197698815   1  4 175815905
superblock 0, blocksize=4096 [VOLUME]
superblock 32768, blocksize=4096 [VOLUME]
superblock 98304, blocksize=4096 [VOLUME]
superblock 163840, blocksize=4096 [VOLUME]
superblock 229376, blocksize=4096 [VOLUME]
superblock 294912, blocksize=4096 [VOLUME]
superblock 819200, blocksize=4096 [VOLUME]
superblock 884736, blocksize=4096 [VOLUME]
superblock 1605632, blocksize=4096 [VOLUME]
superblock 2654208, blocksize=4096 [VOLUME]
 
To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device
****************************************
   P ext4                     0   0  1 2197698815   1  4 175815
Directory /
 
 drwxr-xr-x     0     0      4096  2-Sep-2023 20:29 .
 drwxr-xr-x     0     0      4096  2-Sep-2023 20:29 ..
 drwx------     0     0     16384  2-Jan-2014 17:54 lost+found
>drwxrws---     0   100      4096  9-Jun-2024 04:34 SHARE
 drwxrwsr-x     0   100      4096  2-Sep-2023 21:52 Composer
 -rw-------     0     0      7168 26-Jun-2024 01:48 aquota.user
 -rw-------     0     0      6144 26-Jun-2024 01:48 aquota.grou
SysF
() автор топика
Ответ на: комментарий от SysF

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

Что-то очень сомнительно что ты знаешь.

Если бы ты знал - не писал бы про команду mdadm -assembly, если ты её выполнил и в ней указал неправильную очерёдность дисков, с которой массив собирался - всё, часть данных может быть перезаписана, т.к. mdadm частично пересчитывал контрольные суммы.

Вот по суперблоку не знал.

Тебе про него уже написано было выше. Но ты, видимо, не умеешь читать или делать выводы. Раз повторно задаёшь одни и те же вопросы.

ФС уменьшалась.

Почему ты про это не написал тогда? А в ответе на первое же сообщение в теме задал вопрос как уменшать?

Как? 😅

Есть диск на 6 Тб, подключить и думаю лучший вариант слить на него всё, а там уже разбираться.

Как ты на 6 Тб диск сольёшь 9 Тб данных?

Вот то, что увидел testdisk:

Мне без разницы, что у тебя видит тестдиск. Честно, разбираться в твоём бреду и пытаться помочь, когда ты сам путаешься в показаниях, не понимаешь и даже не пытаешься понять не очень-то хочется.

Удачи.

kostik87 ★★★★★
()
Ответ на: комментарий от SysF

Я не понимаю, где ФС…

Где создавали, там и фс. Не?

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

Очень смешно.

anc ★★★★★
()
14 августа 2024 г.
Ответ на: комментарий от anc

Чем закончилось… Отпишусь всё же )) Восстанавливал данные на 6 Тб диск с помощью TestDisk. Восстановлено 99%. TestDisk или ошибки в ФС дали интересный эффект, что в одной из папок нашлась инфа всего диска повторно, что привело к удвоению размера данных в 2 раза. Есть огромный минус у TestDisk - это считать один и тот же файл, который переименовали, двумя файлами. Т.е. скачав, к примеру, фильм с названием файла как попало и потом его переименовав, TestDisk восстановит 2 файла с разными именами. Это занимает уйму времени и кучу места. Сам TestDisk на редкость мощный, потому что находил файлы, которые были удалены лет 5 назад. Нигде так и не смог найти точного описания, почему некоторые файлы он выделяет красным цветом. Даже в офф манах описания нет. По итогу восстанавливал отдельными папками, потом сливал по сети данные на второй NAS, удалял с 6 Тб, восстанавливал следующую папку. Из потерь одна папка с сериалом, причем она полностью оказалось пустой. Это мелочи. Восстановленовление заняло около 3 суток вместе с перегоном данных с 6 Тб на другой NAS. Это примерно 6.5 Тб, вместе с повторными файлами (которые переименовали).

Априори всем спасибо за помощь!

SysF
() автор топика