Proxmox проверка диска на ошибки

Проверка диска на наличие плохих секторов возникает нежданно и лучше знать как это сделать имея под рукой всё необходимое. Вариантов проверки дисков множество. Расскажу о проверке средствами консоли Linux. Просто и ничего лишнего.

Причины для проверки диска

Основная причина проверки это как правило медленная работа системы или зависание при определенных действиях. Вывести диск из строя могут разные факторы. Вот некоторые из них:

• Время жизни диска не вечна;
• Некорректные выключения системы при пропадании питания;
• Физические удары;
• Запуск холодного диска зимой.

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

Храните важные данные в двух совершенно разных физически местах. Только такой подход гарантирует вам полную сохранность данных.

Определение диска для проверки

Для того чтобы понять какой диск проверять нам достаточно ввести команду в консоли которая выдаст нам список всех имеющихся дисков в системе.

fdisk -l
= вывод части команды =
Диск /dev/sda: 232.9 GiB, 250059350016 байт, 488397168 секторов
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт
Тип метки диска: dos
Идентификатор диска: 0x42ef42ef

Устр-во Загрузочный начало Конец Секторы Размер Идентификатор Тип
/dev/sda1 * 2048 184322047 184320000    87.9G 7 HPFS/NTFS/exFAT
/dev/sda2 184322048 488394751 304072704 145G  7 HPFS/NTFS/exFAT

Мы видим в выводе диск который нам надо проверить. Диск имеет 2 раздела с данными.

Проверка диска на битые секторы

Перед проверкой разделы необходимо отмонтировать. Как правило я загружаю операционную систему на базе Linux c Live образа или использую подготовленный PXE сервер на котором присутствуют и другие программы для проверки жестких дисков.

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

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

Создание файла для записи плохих секторов

Создадим файл указав для удобства имя проверяемого раздела.

touch "/root/bad-sda1.list"

Проверка диска утилитой badblocks

Запустим проверку с информацией о ходе процесса с подробным выводом. Чем больше диск тем дольше проверка!

badblocks -sv /dev/sda1 > /root/bad-sda1.list
= Информация о ходе процесса = 
badblocks -sv /dev/sda1 > /root/bad-sda1.list Checking blocks 0 to 976761542 Checking for bad blocks (read-only test): 0.91% done, 1:43 elapsed. (0/0/0 errors)
= Подробный вывод результата =
badblocks -sv /dev/sda1 > /root/bad-sda1.list Checking blocks 0 to 156289862 Checking for bad blocks (read-only test): done             Pass completed, 8 bad blocks found. (8/0/0 errors)

В нашем случае диск с 8 плохими секторами.

Пометка плохих секторов диска

Запустим утилиту e2fsck, указав ей список битых секторов. Программа пометит плохие сектора  и попытается восстановить данные.

Указывать формат файловой системы нет надобности. Утилита сделает всё сама.

e2fsck -l /root/bad-sda1.list /dev/sda1
= Вывод команды =
e2fsck -l /root/bad-sda1.list /dev/sda1e2fsck 1.43.3 (04-Sep-2016)
Bad block 44661688 out of range; ignored.
Bad block 44661689 out of range; ignored.
Bad block 44661690 out of range; ignored.
Bad block 44911919 out of range; ignored.
Bad block 44958212 out of range; ignored.
Bad block 44958213 out of range; ignored.
Bad block 44958214 out of range; ignored.
Bad block 44958215 out of range; ignored.
/dev/sda1: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 11/9773056 files (0.0% non-contiguous), 891013/39072465 blocks

Подготовка диска для проверки

Бывают случаи когда таблица разделов повреждена на диске и нет возможности посмотреть какие есть разделы с данными. Возможно вам не надо никаких данных на диске и вы хотите диск отформатировать и затем проверить. Случаи бывают разные и надо подходить исходя из ситуации.

С помощью команды с ключом -z вы сможете создать заново таблицу разделов и создать необходимые вам разделы.

cfdisk -z /dev/sda

Как работать с утилитой cfdisk я не буду объяснять, так как это выходит за рамки данной статьи.

Предположим что вы создали из всего диска лишь один раздел /dev/sda1. Для форматирования его в ext4 достаточно выполнить команду:

mkfs.ext4 /dev/sda1
= Вывод команды =
mke2fs 1.43.3 (04-Sep-2016)Creating filesystem with 244190385 4k blocks and 61054976 inodesFilesystem UUID: c4a1eeed-960a-4aea-a5ff-02ce93bf0a2eSuperblock backups stored on blocks:  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,  4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,  102400000, 214990848
Allocating group tables: done                            
Writing inode tables: done                           
Creating journal (262144 blocks): doneWriting superblocks and filesystem accounting information: done

Вывод

Проще и понятней механизма проверки диска на битые сектора как в системе Linux я не встречал. Ничего лишнего только суть. Выбор варианта как проверять и когда всегда за вами. После того как я один раз потерял важные данные храню всё важное в 3 разных местах.

(Or any pool, really; doesn’t need to be Proxmox…)

Just recently, a server I commissioned 5 years ago began emailing me SMART drive errors. The RAIDZ-1 pool of four WD RED 3TB drives had a couple drives going bad at once — bad news indeed.

In a case like this, it’s important to ensure your backups are current (or make a backup in a hurry, if you haven’t already done so!) With peace of mind knowing that your data is safe even if you make a mis-move and blow up your zpool, you are supposed to be able to replace drives in a ZFS pool quite easily. But pulling a drive that is good will probably take down the whole storage pool; so how do you know which physical drive is failing? How do you identify each drive from its identifier in the ZFS pool?

1. View verbose zpool status

Firstly, view the status of your zfs pool with the “zpool status -v” command. Here’s what my output looked like. I know, not good! (note: if you have more than one pool, and you only want to display the status of one, specify the pool name: e.g. “zpool status -v dpool”.)

root@pve:~# zpool status -v dpool
  pool: dpool
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
    corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
    entire pool from backup.
   see: http://zfsonlinux.org/msg/ZFS-8000-8A
  scan: scrub repaired 1012K in 0 days 08:31:31 with 0 errors on Sun Oct 11 08:55:32 2020
config:

    NAME                                                   STATE     READ WRITE CKSUM
    dpool                                                  DEGRADED     0     0     0
      raidz1-0                                             DEGRADED    70     0     0
        wwn-0x50014ee2b667195e                             DEGRADED    75     0     0  too many errors
        wwn-0x50014ee2b6662089                             ONLINE       0     0     0
        wwn-0x50014ee2b666d820                             FAULTED     24     0     0  too many errors
        wwn-0x50014ee2b665e775                             ONLINE       0     0     0
    logs	
      ata-Samsung_SSD_860_EVO_250GB_S3YHNX0M117855W-part1  ONLINE       0     0     0
    cache
      sdb2                                                 ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        dpool/vms/vm-100-disk-0:<0x1>

Note the drive identifiers ZFS is using, each beginning with “wwn-“. Popping open the cover of my Proxmox host and viewing the drives gets me the serial numbers of each:

2. Correlate physical drives to their identifiers in the zpool

So without shutting down the server and pulling drives to view their big label stickers, how do we find out which of the drives are failing? Which drive serial numbers correspond to each WWN identifier in the zpool? Turns out it’s easy with smartctl. Let’s find out which disk is DEGRADED in the pool above:

root@pve:~# smartctl -a /dev/disk/by-id/wwn-0x50014ee2b667195e | grep Serial
Serial Number:    WD-WCC4N3VR2V07

All right, a quick compare with the photo of the drives reveals that’s the bottom drive. Next, which one is FAULTED?

root@pve:~# smartctl -a /dev/disk/by-id/wwn-0x50014ee2b666d820 | grep Serial
Serial Number:    WD-WCC4N4HUCHLP

OK, so that’s the second drive down from the top. Now we know exactly which drives are causing the issue and need to be replaced. Actually, after 5 years of 24/7 service, hmmmm… likely they all ought to be replaced! In my case I took a backup, destroyed the pool altogether, and started over with a mirror of two 4TB drives. (I am coming to prefer mirrors over RAID-Z arrays.) For the curious, I opted for Seagate IronWolf drives this time; I’ll see how they treat me.

Obviously there are other methods to arrive at the same place. You can simply run “smartctl -a” on each drive in turn, looking for the Serial number and WWN number for each drive among the information that is printed to screen:

smartctl -a /dev/sda

and so forth. Whatever best suits your style!

Of course, physically pulling the drive and inspecting the top sticker will also reveal serial number, WWN identifier, and so forth. But if all you can see is the serial number, and you want to find out which drive is failing without shutting down the server to pull drives, this method will get you there. And if your pool happens to list its drives by their /dev/sdx identifiers, you’ll for sure need help to figure out which physical devices are specified in pool config. (e.g. “smartctl -a /dev/sdc | grep WWN” or “smartctl -a /dev/sdd | grep Serial”, etc)