Історія порятунку даних з "вмираючого" жорсткого диска
Чергове ранок почався з читання листи від smartd. Один з дисків сервера, який використовується для резервного копіювання всіх інших серверів, почав свій шлях в кращий світ. У листі говорилося про появу одного pending sector. але поки я їхав в офіс від smartd прийшов другий лист, в якому говорилося, що цей сектор вже перейшов в розряд offline uncorrectable. А ось це вже погано, значить з великою часткою ймовірності вважати дані з цього сектора вже не вдасться.
Забігаючи вперед скажу, що я не прихильник "ховати" проблемні сектора на дисках і використовувати їх далі. Якщо на диску з'явилися проблеми з читанням секторів, то довіри до такого диску вже немає ніякого. Його потрібно швидше виводити з експлуатації і більш не використовувати (у всякому разі в серверах). Зараз вартість нових дисків достатньо низька щоб міняти їх на нові.
Після вихідних новий диск був встановлений в сервер і я приступив до міграції даних. Щоб мати можливість стежити за прогресом з будь-якого місця запускаю сесію screen
Сервер має віртуалізація OpenVZ і сервер резервного копіювання є одним з контейнерів. Для початку його потрібно зупинити і заборонити автозапуск на випадок нештатної перезавантаження фізичного сервера.
На вмираючому диску було зайнято більше 50% простору, причому дрібними файлами, і я вирішив переносити дані на блочному рівні. Для цього потрібно отмонтировать розділ і заборонити його автомонтірованіе (знову ж на випадок нештатної перезавантаження)
Оскільки у мене вже був досвід копіювання даних з проблемних носіїв, то я відразу відправився шукати ddrescue під CentOS. На відміну від класичного dd, ddrescue читає дані великими блоками, але при появі помилок зменшує розмір блоку і перечитує зіпсований ділянку. Це призводить до значного зниження швидкості копіювання, але після проходження проблемної ділянки, розмір блоку знову збільшується і швидкість знову зростає. Потрібний пакет знайшовся в репозиторії EPEL
Тут варто згадати, що є дві різні версії ddrescue. Первісна версія 1 була написана Kurt Garloff. Пізніше фондом GNU була випущена поліпшена версія 2. яка увібрала в себе всі найсильніші сторони.
У надії, що не читаються даних буде трохи, я відправився додому.
На наступний день мене чекав звіт ddrescue
Згідно зі звітом не вдалося прочитати лише 13 секторів. Зараз я ще не знаю в чи були ці сектори зайняті даними або припадали на незайняту область диска. Наступний щаг - визначити яких файлів належать ці сектори (і належать взагалі).
У звіті ddrescue вказані абсолютні номери секторів диска (починаючи з сектора номер 0) і це означає, що для подальшої роботу мені потрібно дізнатися з якого і по який сектор розташований розділ з даними на диску.
Оскільки розділ починається з сектора 64, то потрібно перерахувати номери секторів щодо початку розділу і перевести номера секторів в номери блоків. Спочатку дізнаємося розмір блоку файлової системи в секторах.
Оскільки розмір блоку 4096 байт і розмір фізичного сектора 512 байт, то розмір блоку дорівнює 8 фізичним секторам. Отже формула перерахунку буде (LBAN - 64) / 8
Частина зіпсованих секторів належить одним і тим же блокам, визначимо унікальні номери блоків
Тут мені трохи полегшало, номери блоків йдуть підряд і висока ймовірність, що всі вони належать тільки одному файлу. Залишилося це перевірити - знаючи номера блоків можна визначити зайняті вони і якщо зайняті, то який файл був пошкоджений. На розділі з даними використовує файлову систему ext3 і для низкоуровневой роботи з нею призначена утиліта debugfs. Після запуску потрібно відкрити розділ / dev / sdd1. Відкриття розділу на 2TB зайняло більше часу, ніж я очікував і довелося чекати.
Перевіряю, зайняті чи блоки 68307918, 68307919, 68307920 та 68307921 даними (блоки йдуть підряд і замість перерахування я вказав початковий і кількість)
Дива не сталося, все ж частина даних пошкоджена. Залишилося з'ясувати які файли були порушені. Для цього потрібно зіставити номери блоків з иноді, яким належать ці блоки.
Трохи краще, 4 пошкоджених блоку належать 3 різних инодом. Залишається дізнатися імена файлів або директорій, які відповідають цим инодом.
Зачепило файли інкрементів одного з тестових сайтів. Цей сайт не представляє великої цінності і бекап "до купи". Тепер можна видихнути і вийти з debugfs.
Пізніше вирішив зробити невеличкий експеримент, який показує, що fsck для ext3 не може виявити пошкодження в області даних.