Как я восстанавливал данные с диска, созданного в QNAP QTS

в 13:00, , рубрики: qnap, домашний сервер, настройка, сервер
Как я восстанавливал данные с диска, созданного в QNAP QTS - 1

Всем привет! Это Кирилл, руководитель команды спецпроектов МТС Диджитал. Каждому хочется надежно хранить свои данные, чтобы даже в случае чрезвычайной ситуации с ними ничего не случилось. Облака — это, конечно, хорошо, но иметь дома свой небольшой файловый сервер уже давно стало обыденностью для многих.

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

Как я решил масштабировать хранилище

Как я восстанавливал данные с диска, созданного в QNAP QTS - 2

Все началось с того, что я задумался о масштабировании хранилища. Достаточно долго мне хватало скромной конфигурации:

  1. Диск 1 (объем 1 Тб) использовался для операционной системы QNAP и приложений хранилища. А еще выполнял роль файлопомойки, куда записывались все скачиваемые файлы: от торрентов до обычных загрузок.

  2. Диск 2 (объем 2 Тб) играл роль долговременного хранилища документов, фотографий и виртуальных машин. Туда же сливались бэкапы c Apple Mac M2 через штатную утилиту Time Machine и снимки и видео с iPhone.

Данные на втором диске понемногу накапливались, и стало ясно, что пора обзавестись более емкими накопителями. Даже после основательной чистки он оставался забитым, и вот что я решил. Данные, к которым я часто обращаюсь, будут скопированы на внешний жесткий диск. Сам второй диск будет проверен на bad-блоки, извлечен из NAS и отправлен в сейф. Файлопомойка на первом диске будет проверена, все лишнее удалено. После этого NAS отправится с первым диском на полную инициализацию. В процессе подготовки все данные на первом диске окажутся стерты, а на место второго диска будет установлен новый, более емкий накопитель. 

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

Диск опознаётся, но в систему не монтируется

Диск опознаётся, но в систему не монтируется

Тут, как назло, я вспомнил, что забыл перенести архив с драйверами одного из своих устройств. Так что решил снова подключить второй диск на его старое место. Внезапно выяснилось, что диск опознается в системе как Free. А вместо того, чтобы смонтировать его, QTS предлагает только опцию очистки в виде форматирования. По спине побежал вполне ощутимый холодок.

Попытка номер 1

Пробую подключить диск как внешний USB-накопитель

Пробую подключить диск как внешний USB-накопитель

Первое, что я сделал — снял диск со штатной салазки и попробовал воспользоваться внешним USB-кейсом, воткнув его в QNAP. Дело в том, что QTS обычно сама прекрасно справляется с монтированием внешних жестких дисков, как отформатированных в EXT4, так и в NTFS. 

Все подключил, в строке состояния отображается, что все ок, диск приконнектчен. Открываю штатное приложение File Station, а диска там нет. Заглянул в Storage & Snapshots: диск отображается, а вот вместо одного раздела обнаружил там сразу целую пачку, причем у всех файловая система была Undefined. Ну, думаю, приплыли.

Переключил внешний кейс к компьютеру — так уж вышло, что на нем установлена Windows 11. Разумеется, разделы операционная система увидела, но вот поддержки файловых систем Linux у Windows пока что не появилось. Пошел в Гугл, а там умные люди и инструкции советуют поставить триал-версию Linux File Systems for Windows от Paragon Software. Дескать, это добавит поддержку файловой системы ext4 и диск можно будет спокойно добавить в Windows. 

После добавления поддержки файловой системы ext4

После добавления поддержки файловой системы ext4

Скачал, установил, проверил. Вижу содержимое диска, выдыхаю. Открываю нужную мне директорию, пробую скопировать оттуда архив, за которым изначально диск доставал. Ошибка: файл был перемещен или удален. Выдыхать, судя по всему, было рано.

Что-то явно пошло не так

Что-то явно пошло не так

Начинаю открывать рандомные файлы из разных директорий: примерно половина открывается, со второй та же самая ошибка. Подумав, что произошел какой-то сбой, перезагружаюсь, делаю все то же самое — опять ошибка. Понемногу начинаю осознавать, что нужно действовать иначе. А так как это Ext4, пришла пора достать старый ноутбук на Linux и посмотреть, а не сможет ли Ubuntu сходу смонтировать этот диск и дать доступ к данным.

Попытка номер 2

Загрузился в Ubuntu 22.04 LTS, но после подключения харда автоматически ничего не смонтировалось. Причем ОС диск видела, но файловую систему определяла неправильно. fdisk показал следующую картину:

Disk /dev/sdb: 1,82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20EZAZ-00G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E9E4EBFD-D325-43C2-A2C9-EE2CC7CE76D3

Device          Start        End    Sectors   Size Type
/dev/sdb1          40    1060289    1060250 517,7M Microsoft basic data
/dev/sdb2     1060296    2120579    1060284 517,7M Microsoft basic data
/dev/sdb3     2120584 3889240109 3887119526   1,8T Microsoft basic data
/dev/sdb4  3889240112 3890300399    1060288 517,7M Microsoft basic data
/dev/sdb5  3890300408 3907007999   16707592     8G Microsoft basic data

Сразу видно, что данные лежат на /dev/sdb3, который, по идее, отформатирован в Ext4. Но fdisk в упор этого не видит. Создаю временный каталог /mnt/tmp как точку монтирования и пробую принудительно указать ext4 в качестве файловой системы. На всякий случай прописываю ключ -r (смонтировать только для чтения):

$ sudo mount -r -t ext4 /dev/sdb3 /mnt/tmp/

Получаю ошибку:

mount: /mnt/tmp: wrong fs type, bad option, bad superblock on /dev/sdb3, missing codepage or helper program, or other error.

Окей, а что, если ОС сама попытается определить файловую систему:

$ sudo mount -r /dev/sdb3 /mnt/tmp/         

Вывод:

mount: /mnt/tmp: unknown filesystem type 'linux_raid_member'

Уже теплее. Получается, QNAP даже при создании обычного Static volume все равно делает из этого RAID. Окей, накатываю поддержку программных RAID-массивов:

$ sudo apt install mdadm

Теперь пробую собрать и запустить массив:

$ sudo mdadm --assemble --run /dev/md0 /dev/sdb3
mdadm: /dev/md0 has been started with 1 drive.

Сдается мне, что я на верном пути. Раз уж массив запущен, то можно попробовать смонтировать его:

$ sudo mount /dev/md0 /mnt/tmp/
mount: /mnt/tmp: unknown filesystem type 'LVM2_member'.

Вот оно чо, Михалыч. Тут еще и логический менеджер томов запихнули. Ну раз так, ставлю нужные пакеты для поддержки LVM:

$ sudo apt install lvm2

И пробую посмотреть на доступные группы томов:

$ sudo vgs
WARNING: PV /dev/md0 in VG vg289 is using an old PV header, modify the VG to update.
VG    #PV #LV #SN Attr   VSize VFree
vg289   1   2   0 wz--n- 1,81t    0

Стало ясно, что группа томов создавалась в более старой версии LVM — об этом и предупреждает утилита. Ну раз так, давайте обновим метаданные, PV header обновится автоматом:

$ sudo vgck --updatemetadata vg289
WARNING: PV /dev/md0 in VG vg289 is using an old PV header, modify the VG to update.
WARNING: updating PV header on /dev/md0 for VG vg289.

Таки да, заголовок обновился, и в /dev/mapper появилась наша группа томов vg289-lv. Момент истины:

$ sudo mount -a

Проверяем:

$ df -
/dev/mapper/vg289-lv2  1,7T  1,2T  573G  67% /media/user/WD2TB

Оно наконец-то смонтировалось, и я пошел проверять, все ли файлы доступны. Рандомно потыкал в то, что не открывалось с помощью Linux File Systems for Windows. Все доступно, все копируется. Бобер — выдыхай! Теперь можно спокойно идти пить кофе, пока данные с этого диска переносятся на резервный носитель.

Что удивило

Самым неочевидным моментом во всей этой истории было вот что. Даже когда я специально создавал обычный Single static volume без поддержки снапшотов и прочих плюшек, система все равно делала два слоя абстракции: программный RAID-массив и LVM. Если бы я знал об этом заранее, вопросов с правильным порядком действий возникло бы меньше. 

С одной стороны, я понимаю желание разработчиков QNAP сделать управление данными как можно более простым и понятным для рядового пользователя. Но с другой — я реально не понимаю, почему в QTS такой том не подцеплялся автоматом? Ну это же логично: если вы уже навесили абстракций, то будьте так добры поддерживать их для рядового юзера. Мне в этом плане повезло: я умею со всем обращаться. Но представьте ужас обычного пользователя Windows, который, например, купил себе новый QNAP и пытается переставить диск из старого хранилища в новое. Как вообще такое возможно?

Напоследок непрошенный совет: не забывайте почаще делать бэкапы. В моем случае он был. Так что даже потеряв полностью все данные с диска, я смогу их легко восстановить. Если бы 15 лет назад я думал об этом почаще, то сейчас в моем архиве была бы куча крутых фотографий, которые навсегда пропали после неудачного падения жесткого диска со стола.

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

Автор: radostnuy_glaz

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js