На моем сервере Linux для малого бизнеса я использую дамп для резервного копирования. У меня есть 4 файловые системы (root, home, app1, app2), из которых root является "реальным" разделом, а остальные - LVM-разделами. Все ext4.
Раньше я мог делать дампы уровня 0 за 40-45 минут. Внезапно, однажды они начали занимать 8 часов, с тех пор это идет все медленнее и медленнее ... теперь это занимает более 24 часов. Дампы уровня 1 все еще увеличивают масштаб за 10-15 минут в течение большинства дней.
Моей первой мыслью было "грязь" в самой большой файловой системе (/home), которая стала первой медленной. Но fsck не вылечил это.
Я был вдохновлен, чтобы проверить состояние устройства smartctl на диске с работающими файловыми системами, и действительно обнаружил несколько сотен тысяч временных ошибок чтения. Заменил накопитель и восстановил из резервных копий (которые были хорошими). Проблема сохраняется. На заменяющем диске smartctl показывал МИЛЛИОНЫ переходных ошибок чтения. Некоторые статьи в сети предполагают, что это может быть нормально и нормально для современных терабайтных накопителей. Тем не менее, я заменил накопитель на SSD, но ничего не изменилось.
Живая файловая система была на диске Seagate Barracuda 500 ГБ. Мне всегда говорили, что Seagate Barracuda - это золотой стандарт дисков.
Резервный промежуточный диск - это накопитель WD 1 ТБ. smartctl показывает 0 ошибок на нем.
Любая идея, почему эта проблема появилась из ниоткуда и что может быть причиной?
Некоторые люди скажут, что dump/restore - слишком старая школа, чтобы использовать ее сегодня, но я считаю, что управлять ею намного проще, чем rsync. У меня есть ежедневные инкременты, а затем архивирую еженедельный уровень 0 на диск BD-R DL.
ПОМОГИТЕ