Почему при запуске копирования партиции через dd, перезагружается сервер?

Question

[3ton]

Имеется сервер с виртуализацией в LXC.

В датацентре предупредили о технических работах, на время которых мы выключили сервер.
После окончания работ мы запустили сервер и все стартануло нормально.
Спустя несколько месяцев надо было перенести виртуалку на другой сервер, но в момент запуска копирования при помощи dd, через минут 5-7 после запуска сервер перегрузился.
Сначала решили что просто совпадение, но в момент когда меньше всего посетителей, запустили снова бэкап, и ситуация повторилась.

Софт райд не ругается, все диски "в обойме". Вот что показывает smartctl -A /dev/sdX

/dev/sda

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-13-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   050    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0027   100   100   001    Pre-fail  Always       -       7118
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       25
  5 Reallocated_Sector_Ct   0x0033   100   100   050    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   050    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   050    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   001   001   000    Old_age   Always       -       53223
 10 Spin_Retry_Count        0x0033   100   100   030    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       25
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       106
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       19
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       106
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       37 (Min/Max 23/49)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   253   000    Old_age   Always       -       0
220 Disk_Shift              0x0002   100   100   000    Old_age   Always       -       0
222 Loaded_Hours            0x0032   001   001   000    Old_age   Always       -       53194
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
224 Load_Friction           0x0022   100   100   000    Old_age   Always       -       0
226 Load-in_Time            0x0026   100   100   000    Old_age   Always       -       640
240 Head_Flying_Hours       0x0001   100   100   001    Pre-fail  Offline      -       0

/dev/sdb

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.9.0-13-amd64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   050    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0027   100   100   001    Pre-fail  Always       -       7118
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       25
  5 Reallocated_Sector_Ct   0x0033   100   100   050    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   050    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   050    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   001   001   000    Old_age   Always       -       53223
 10 Spin_Retry_Count        0x0033   100   100   030    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       25
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       106
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       19
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       106
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       37 (Min/Max 23/49)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   253   000    Old_age   Always       -       0
220 Disk_Shift              0x0002   100   100   000    Old_age   Always       -       0
222 Loaded_Hours            0x0032   001   001   000    Old_age   Always       -       53194
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
224 Load_Friction           0x0022   100   100   000    Old_age   Always       -       0
226 Load-in_Time            0x0026   100   100   000    Old_age   Always       -       640
240 Head_Flying_Hours       0x0001   100   100   001    Pre-fail  Offline      -       0

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

Бэкап делаю так

lvcreate -L 30GB -s -n backends-snap /dev/lxc/backends
dd if=/dev/lxc/backends-snap bs=1M | gzip -9 > /mnt/backups/strato3/backends-snap30.gz
lvremove /dev/lxc/backends-snap

Comments

[rPman]

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

Можно, если это критично для тестов, замерять температуру, всю до куда можно дотянуться, со скважностью в десятые секунды.

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

[3ton]

rPman, при бэкапе температура дисков остается на том же значении

[rPman]

3ton, причем тут диски? я про дисковый контроллер и материнку
если говорить про диски, то нужно смотреть smart или его аналоги

[Ava256]

3ton Если это не диски, то возможно память или проц.
В dmesg и syslog какие-нибудь ошибки есть?
Какой модели сервер? У него есть ipmi? Там в логах есть ошибки в момент перезагрузки?

[3ton]

нет, до перезагрузки все ровно, а потом сразу в лог загрузка попадает
само собой нет лога отправки в ребут

[3ton]

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

[Ava256]

3ton, Смотрите логи сервера в ipmi, если они есть. Проверяйте память мемтестом.

[brar]

lvm случайно не забит "под завязку"?
Или может было такое, что вы создали снэпшот и работали, в итоге он забил собой место?

[3ton]

снэпшоты все удалены

[brar]

3ton,
=Ну, попробуйте примонтировать созданный снэпшот и tar-ом заархивировать. "tar -cvzf tar.gz /mnt/ваш_снэпшот".

-Или пусть его пайпом вместо gzip на удаленный ssh-сервер (так снизите нагрузку на физический диск).

-Либо, если есть на сервере, второй физический диск, то на него.

-Или загрузитесь с какого-нибудь live-usb iso. Арч, например, в нем есть lvm2, насколько помню, а если - нет, устанОвите. Правда, если в сети нет dhcp сервера, то придется руками настроить. Примонтируйте свой целевой lvm-раздел и попробуйте повторить ваши операции. Если пройдет гладко, значит косяк в вашей ОС, если же опять вывалится, то к хостеру.

(единствненное, не понятно, почему хостер отмахивается от того факта, что селфтест завис на старте).

[ValdikSS]

Может зависать не непосредственно железо, а ядро, а перезагружаться из-за настроенного watchdog.
Модуль netconsole поможет увидеть последние сообщения ядра (и возможную панику), если они не сохраняются на диск — потребуется второй сервер в той же сети с L2-связностью.

Иногда причину ошибки можно увидеть через ras-mc-ctl или в pstore-хранилище.

[3ton]

договорился на счет консоли и запустил тестерпамяти
в машине 32 гига памяти, тест запустил так

memtester 18000 5
memtester version 4.3.0 (64-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 18000MB (18874368000 bytes)
got  18000MB (18874368000 bytes), trying mlock ...locked.
Loop 1/5:
  Stuck Address       : testing   0
Socket error Event: 32 Error: 10053.

в итоге в консоли отловил это

memtester

[ 77.839328] EDAC MC0: 1 CE ie31200 CE on mc#0csrow#0channel#0 (csrow:0 channel:0 page:0x0 offset:0x0 grain:8 syndrome:0x8a)
[ 79.588921] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0
[ 79.588921] {1}[Hardware Error]: event severity: fatal
[ 79.588922] {1}[Hardware Error]: Error 0, type: fatal
[ 79.588922] {1}[Hardware Error]: fru_text: UncorrectedErr
[ 79.588922] {1}[Hardware Error]: section_type: memory error
[ 79.588922] {1}[Hardware Error]: node: 1 device: 0
[ 79.588922] {1}[Hardware Error]: error_type: 3, multi-bit ECC
[ 79.588923] Kernel panic - not syncing: Fatal hardware error!
[ 79.588923] CPU: 0 PID: 1562 Comm: memtester Not tainted 4.19.0-27-amd64 #1 Debian 4.19.316-1
[ 79.588923] Hardware name: Supermicro Super Server/X11SSL-F, BIOS 2.0c 10/06/2017
[ 79.588923] Call Trace:
[ 79.588923] dump_stack+0x66/0x81
[ 79.588923] panic+0xfa/0x25d
[ 79.588924] ? ghes_copy_tofrom_phys+0xe4/0x260
[ 79.588924] __ghes_panic.cold.21+0x21/0x21
[ 79.588924] ghes_notify_nmi+0xca/0x180
[ 79.588924] nmi_handle+0x62/0x120
[ 79.588924] default_do_nmi+0x4e/0x100
[ 79.588924] do_nmi+0xff/0x150
[ 79.588925] nmi+0xa6/0xef
[ 79.588925] RIP: 0033:0x55ab30302d82
[ 79.588925] Code: 0f 1f 84 00 00 00 00 00 48 83 c2 01 48 83 c0 08 48 83 eb 08 49 39 d6 0f 84 93 00 00 00 4a 8d 34 2a 48 8b 08 83 e6 01 48 89 de <48> 0f 44 f0 48 39 ce 74 d5 8b 05 e7 34 20 00 85 c0 0f 85 a7 00 00
[ 79.588925] RSP: 002b:00007ffe2f76c970 EFLAGS: 00000202
[ 79.588926] RAX: 00007f5be9800428 RBX: ffff80a4167ffbd7 RCX: ffff80a4167ffbd7
[ 79.588926] RDX: 0000000040fd6285 RSI: ffff80a4167ffbd7 RDI: 0000000000000000
[ 79.588926] RBP: 00007f59e194f000 R08: 00007f5e46b0b8c0 R09: 00007f5e46b10500
[ 79.588926] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 79.588927] R13: 0000000000000000 R14: 000000008c9ffe02 R15: 0000000000000000
[ 79.588983] Kernel Offset: 0xa00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)