нещодавня спроба реанімації пінгвіна на хромбоксі asus cn60 закінчилася безславно: довелося знайти оригінальний ssd на 16 гб, бо два інших (один зі старих запасів, інший спеціально купований для цієї задачі) просто не підійшли. хромбокс виявився надміру примхливий: і місця мало (лише модулі 42 мм!), і з форматом сама плутанина. на фото — випробувані накопичувачі, зліва направо…
- рідний sandisk 16 гб (sdsa6mm-016G-1002): sata3 m.2 (b+m) — працює
- adata 128 гб (asp600ns34-128gm-c): sata3 m.2 (b+m) — не підходить?!
- hynix 128 гб (hfm128gdhtng-8310b): nvme m.2 (b+m) — не підходить
використання вживаних дисків для моїх експериментів дається взнаки: вже замінив один з дисків у бекплейні основного сервера, тепер надійшла черга системного диска в сервері файлів (на котрому я зберігаю майже виключно фільми й музику, нічого критичного) — smart вилаявся, а за якийсь час диск просто перестав монтуватися для читання, сервер спинився.
в теорії, план порятунку виглядає так: завантажитися з флешки, клонувати диск у файл на диску даних (місця достатньо), замінити диск на подібний (500 гб), клонувати з образу на новий диск, завантатижи; створення копії диска за допомогою dd за підказками в тенетах мало би виглядати ось так:
## клонування хворого системного диска (/dev/sde) у стиснений файл
## на здоровому диску/розділі (/mnt/disk2 для прикладу)
dd if=/dev/sde conv=sync,noerror status=progress bs=64K | gzip -c > /mnt/disk2/os_disk_image.dd.gz
але так робити не варто, а краще спробувати ddrescue замість dd: «ddrescue does not write zeros to the output when it finds bad sectors in the input, and does not truncate the output file if not asked to. so, every time you run it on the same output file, it tries to fill in the gaps without wiping out the data already rescued».
## спроба клонування хворого системного диска (/dev/sde) у файл
## на здоровому диску/розділі (/mnt/disk2) за допомогою ddrescue
ddrescue -r 3 /dev/sde /mnt/disk2/os_disk_image_ddr /mnt/disk2/os_disk_image.mapfile
повна процедура (після завантаження з флешки):
## ідентифікація дисків та розділів
lsblk -o +fstype,uuid,model,serial
## підключення розділу даних з достатнім простором
## для тимчасового збереження образу диска
## (/dev/sdd1 в моєму випадку)
sudo -s
mkdir /mnt/disk3
mount /dev/sdd1 /mnt/disk3
## клонування «хворого» диска (/dev/sde)
ddrescue -r 3 /dev/sde /mnt/disk2/os_disk_image.ddr /mnt/disk2/os_disk_image.mapfile
процес тривалий: за півтори години мій microserver спромігся зробити 38% з 512 гб і прогнозує роботи ще на 3 години (див. зняток екрана). насправді більше, ба значно більше, якщо на диску є проблемні ділянки (підручник з використання ddrescue, особливо розділ про застосовувані алгоритми — цікаве читання!)
з незрозумілих причин, за 11 годин роботи, завантажена з флешки система зависла — зображення на екрані є, але жодної реакції від машини на клавіатуру/мишу — на щастя, одна з переваг роботи з ddrescue в тому, що можна перезавантажитися, запустити процес ще раз, — і ddrescue підхопить з останнього етапу, зареєстрованого в тому ж файлі mapfile.
за другої спроби процес завершився після кількох етапів відновлення всього, що можна відновити, — з підсумковим «рахунком» 99,9% «врятованих» даних. далі — вимкнення сервера, заміна жорсткого диска на інший такого ж розміру, і запис даних з клонованого образу (файл mapfile має бути новий!):
## ідентифікація дисків
lsblk -o +fstype,uuid,model,serial
## підключення розділу з клонованим образом (/dev/sdd1)
sudo -s
mkdir /mnt/disk3
mount /dev/sdd1 /mnt/disk3
## запис клонованого образу на диск (/dev/sde)
ddrescue -f /mnt/disk3/os_disk_image.ddr /dev/sde /mnt/disk3/os_disk_restore.mapfile
після перезавантаження й невеличкої поправки в налаштуваннях bios (бо hp proliant microserver n40l потребує, щоби в bios’і з усіх наявних hdd лише один було призначено для завантаження — не питайте) — сервер «піднявся».
все? ну, так. але згодом треба буде зменшити основний, системний розділ на цьому диску так, щоби за потреби знову клонувати диск, можна було обмежитися меншим новим диском, на 128 гб, — там не треба півтерабайта.