Lost connection слишком общая ошибка, чтобы только по ее названию можно было точно заключить в чем дело.
Ну попробуй в конфигах mysql убрать все таймауты, которые найдешь. Убедись что там есть skip-name-resolve или же, если нельзя ее эту директиву использовать, убедись что обратный резолв dns правильно и быстро работает.
С такими параметрами в обмене диска sda вам могут и отказать, но исходя их остальных сообщений об ошибках кабель проверить обязаны.
Вместо smartctl -A лучше указывать -a. Так будет больше информации. При диагностике по форуму никакая информация не лишняя.
Файлы за другие дни можно посмотреть в том же каталоге где вы нашли файл за этот день.
Данные SMART можно посмотреть с помощью предназначенной для этого программы.
Но вообще, лучше сначала озаботиться бекапом важных данных, чем выяснением первопричин.
А если хочу сверстать полностью свой шаблон?
там же есть "Добавить новый стиль".
Конечно, он будет являться измененной копией "основного стиля", который есть, но его не видно.
Mar 5 17:00:51 nebo-7 kernel: res 41/40:79:d8:bf:b8/bc:00:12:00:00/40 Emask 0x409 (media error) <F>
Mar 5 17:00:55 nebo-7 kernel: res 41/40:79:d8:bf:b8/bc:00:12:00:00/40 Emask 0x409 (media error) <F>
вот это совсем не хорошо. или диск мрет или некачественный кабель sata.
посмотрите файлы за другие дни. возможно, там уже были ошибки на винтах и именно они вызвали перестроение raid.
что ж вы smart не стали смотреть? такие ошибки скорее всего зафиксированы и в smart тоже. там у винта есть собственный лог ошибок.
Софтовый рейд каждое первое воскресенье месяца чекается, по крайней мере в Дебиане, в RHEL-based, думаю примерно так же.
Не, в RHEL в 4 раза корпоративнее - раз в неделю.
Но во время этой проверки массива надпись check, а у ТС recovery.
top - 17:46:15 up 17 days,
раз перегружали недавно, значит что-то не нормально ?
Ну pbackup это ж простейший скрипт. Нет приоритетов, нет инкрементного копирования, вымывает кеш файлов из памяти. Чего еще ожидать.
zames, так нужно подключиться и посмотреть сколько провисит соединение.
таймауты могут быть заданы в самых неожиданных местах.
zames, что там в настройке SQLConnectInfo ? может попробовать PERCONNECTION.
Все это похоже на какое-то несогласованное, а поэтому неожиданное отключение.
Дело в том, что точно такие же сервера коннектятся к нему же - есть еще два, у которых настройки и железо абсолютно идентичные.
Это ты так думаешь. Как минимум, у них разные IP адреса. Этого уже достаточно чтобы возникли проблемы с обратным резолвом.
Ну и другие отличия, которые ты не заметил могут быть.
Lost connection слишком общая ошибка, чтобы только по ее названию можно было точно заключить в чем дело.
Ну попробуй в конфигах mysql убрать все таймауты, которые найдешь. Убедись что там есть skip-name-resolve или же, если нельзя ее эту директиву использовать, убедись что обратный резолв dns правильно и быстро работает.
Ну а трафик то откуда берется ? Гугл, значит, вообще не нужен?
В табличке есть первая цифра IP и принадлежность http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
Выбери те, где ответственна RIPE NCC и получишь Европу.
Получится немного строк, поэтому хоть даже через .htaccess забань и будет нормально.