Дамп / восстановление раньше занимало 40 минут для 4 файловых систем, теперь занимает 24 часа

307
Lars Poulsen

На моем сервере 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.

ПОМОГИТЕ

1
Можете ли вы рассказать нам больше о процессе резервного копирования? Где вы записываете свои файловые системы? Может ли цель быть вашим узким местом? В качестве альтернативы вы расскажете нам о том, что rsync не предоставляет инкрементальные файлы ... Вы рассматривали такие решения, как Bacula? SYN 7 лет назад 0
Crontab запускает 4 дампа уровня 0 в субботу 00:15, 4 дампа уровня 1 с понедельника по пятницу в / резервные копии, которые являются разделом LVM и занимают все / dev / sdb (производственные файловые системы работают на / dev / sda). Lars Poulsen 7 лет назад 0
Я не люблю GUI-подсистемы - нелегко писать сценарии. Да, я знаю, что вы можете делать приращения с помощью rsync, играя в игры с жесткими ссылками, но (а) это сложнее, чем мне нравится (б) я получаю тысячи маленьких файлов для размещения на моем внешнем носителе, а не 4 сжатых дамп файлов. (c) нам нравится то, к чему мы привыкли, и я использовал это в течение десятилетия. (На самом деле, у меня был магнитофон, на который можно было намотать файлы дампа, пока набор больше не помещался на ленту, и он не стал DVD, DVD-DL, BD-R и теперь BD-R / DL.) Lars Poulsen 7 лет назад 0
Да, я рассматривал промежуточный диск как возможное узкое место, но (а) почему вдруг (б) smartctl не говорит об ошибках Lars Poulsen 7 лет назад 0
Хотя я все еще надеюсь услышать ответ на эту проблему, я изучаю обходной путь использования rsync с жесткими ссылками. Я вижу, что представление rsync для 4 файловых систем добавляет до 70 ГБ вместо 47 ГБ (сжатых) файлов дампа - один уровень 0 плюс один уровень 1. Lars Poulsen 7 лет назад 0

0 ответов на вопрос

Похожие вопросы