> Данные еще можно спасти

Восстановить из бэкапов.

Как-то маловероятно выглядит отказ пяти разных hdd одновременно. Начни с поиска отказа по общей причине.

>>211711
Сложно сказать.
Вообще подозрительно, что все пять дисков показывают одинаковый результат. В нормальных условиях такого быть не должно.
Я бы прежде всего посмотрел dmesg, lsblk, file -s /dev/sd[a-e]. Может даже strings и vbindiff бы попробовал, чтобы убедиться что диски выдают хоть какие-то данные, одновременно наблюдая dmesg -w за ошибками чтения или еще какими подозрительностями.
И подозревал бы контроллер, а значит попробовал бы еще прочитать на другом компьютере, если возможно.

Как могла слететь только таблица разделов на сразу пяти дисках, конечно, очень сложно представить, но тем не менее можно попробовать testdisk, особенно если видно, что данные все еще на дисках.
Ну, и конечно не помешает вспомнить вообще как данные были структурированы, какие разделы, шифрование, типы таблиц, файловые системы и так далее. Да и что делалось перед завершением работы надо вспомнить.

>>211712
Бекапы есть, но самый свежий из них сделан около 20 дней назад.
>>211713
Спасибо!

> dmesg, lsblk

Извиняюсь за глупый вопрос, но на что там надо обратить внимание?

> file -s /dev/sda

Выдет это:
/dev/sda: dBase III DBT, version number 0, next free block index 210, 1st item "EFI PART"
Другие диски я пока отключил.

> strings

Выдает кучу всего. Отрывки названий папок и т.п.

vbindiff не трогал

> И подозревал бы контроллер, а значит попробовал бы еще прочитать на другом компьютере, если возможно.

На другом компьютере пока нет возможности проверить. Пробовал подключить один из хардов к другому разъему, который работает на контроллере marvell, вместо интеловского, но там диск все так же нормально не читался.

> testdisk

В Advanced нормально показывает разделы и дает скопировать файлы. Ты мой спаситель.
Не совсем правда понял, как с помощью нее восстановить таблицу разделов.

> как данные были структурированы, какие разделы, шифрование, типы таблиц, файловые системы и так далее

Разделы и прочее я помню. Диски все были без шифрования, с GPT и NTFS.

А вот что было перед завершением работы - это загадка. Я отходил на пару часов и оставлял компьютер с заблокированным экраном и выключенным монитором. Когда пришел и включил монитор, он отказался выводить картинку с видеокарты. Я выключил/включил его несколько раз, переткнул вместо DP кабеля HDMI, а когда ничего из этого не помогло, перезагрузил компьютер. Но даже после этого картинки не было. Изображение появилось только после того, как я на несколько минут оставил пк без питания.

>>211714

>на что там надо обратить внимание?

В dmesg обратить внимание на возможные ошибки связанные с дисками и предупреждения, когда ядро пытается таблицу обнаружить, если пытается. Может есть предупреждения о ошибках контрольной суммы таблицы, например.
В lsblk просто посмотреть как список блочных устройств, их размеров и возможных разделов выглядит.

>/dev/sda: dBase III DBT, version number 0, next free block index 210, 1st item "EFI PART"

Защитную MBR не обнаруживает, но по крайней мере есть признаки остатков GPT.

>GPT

Давай вывод sgdisk -p /dev/sda и sgdisk -v /dev/sda.

У меня еще есть подозрение, что твоя проблема может быть вызвана некоторыми противными биосами, которые на диск бэкапятся через создание HPA. В биосе может быть опция вроде "Save a copy of BIOS to HDD", которая откусывает часть жесткого диска. В этом случае восстанавливать таблицу разделов нужно очень аккуратно, ибо можно затереть хвост файловой системы на последнем разделе.
И покажи вывод hdparm -N /dev/sda. По нему будет ясно включено ли HPA.

>>211716
В dmesg нашел только это - https://pastebin.com/QFK86BTx
lsblk - https://pastebin.com/jYZEBMGv
Или его с какими-то опциями нужно запускать?

> sgdisk -p /dev/sda

Found valid GPT with corrupt MBR; using GPT and will write new
protective MBR on save.
Disk /dev/sda: 488397168 sectors, 232.9 GiB
Model: Samsung SSD 860
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): B670DDA7-8B2D-4F30-A9E0-D6585BEC7C10
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 2-sector boundaries
Total free space is 2349 sectors (1.1 MiB)

Number Start (sector) End (sector) Size Code Name
1 34 262177 128.0 MiB 0C01
2 264192 468991 100.0 MiB EF00
3 468992 488396799 232.7 GiB 0700

> sgdisk -v /dev/sda

Found valid GPT with corrupt MBR; using GPT and will write new
protective MBR on save.

No problems found. 2349 free sectors (1.1 MiB) available in 2
segments, the largest of which is 2014 (1007.0 KiB) in size.

> hdparm -N /dev/sda

/dev/sda:
max sectors = 488397168/488397168, HPA is disabled

>>211717
Теория с HPA не подтвердилась, обе GPT живы, но защитная MBR однозначно повреждена.
В отрывке dmesg вроде ничего криминального нет.

В общем чтобы исправить MBR нужно сделать gdisk /dev/sda и там подать команду x появится приглашение "Expert command:", в ответ на которое нужно подать команду n для создания новой защитной MBR и потом w для записи изменений на диск. Должно помочь.

>>211718
Заработало! Спасибо большое еще раз.

SSD восстановил, теперь собирался восстанавливать харды.
Но, кажется, что-то с ними не так.

lsblk - https://pastebin.com/n2uYy6kA

dmesg -w при работе strings ошибок не пишет.

Но вот что пишет

> file -s /dev/sdc

/dev/sdс: data

> sgdisk -p /dev/sdc

Creating new GPT entries.
Disk /dev/sdc: 3907029168 sectors, 1.8 TiB
Model: WDC WD2000FYYZ-0
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 77D0F0BE-0B79-4E91-84E7-D4EE6103FE31
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3907029101 sectors (1.8 TiB)

Number Start (sector) End (sector) Size Code Name

> sgdisk -v /dev/sdc:

Creating new GPT entries.

No problems found. 3907029101 free sectors (1.8 TiB) available in 1
segments, the largest of which is 3907029101 (1.8 TiB) in size.

Сейчас жду окончания анализа testdisk.

Может быть, я что-то напутал, и на них не GPT? Или дело в чем-то другом?

>>211711
Как-то умер МБР на 2тб диске (комп работает 24/7, так что надо покупать спецдиск "для систем видеонаблюдения" с нормальным подшипником на 500 рублей дороже).

Восстановил как-то через командную строку, не помню уже, буквально первая страница гугла (что-то кореллирующее с fs data mbr recovery linux comand line bez registratsiyi ilham zulkorneev morkiye pisechki). Какая-то побайтовая копия через ff кажется через другую утилиту. Не восстановилась дюжина файлов там и сям и пропала самая большая папка - с торрентами.

Больше суток копировало.

Так что

> Данные еще можно спасти

Частично скорее всего можно.

Вопрос в том, что у тебя случилось. Полудохлый подшипник, запоровший первые сектора диска (видимо запарковав на них голову) - это одно.
Если у тебя сдохли сразу все диски - возможно это коронавирус, который например всё зашифровал или всё потёр.

Может у тебя БП просто не тянет 5 дисков и поэтому что-то произошло.

В принципе если основной раздел не тронут, то даже с мёртвой фс-таблицей многое можно восстановить.

Начни с втыкания какого-нибудь диска в другой (рабочий) комп.