No meu servidor linux de pequenas empresas, eu uso dump para backups. Eu tenho 4 sistemas de arquivos, (root, home, app1, app2), dos quais root é uma partição "real", enquanto os outros são partições LVM. Todos são ext4.
Eu costumava ser capaz de fazer o nível 0 em 40-45 minutos. De repente, um dia eles começaram a tomar 8 horas, desde então ele vai mais devagar e mais devagar ... agora leva mais de 24 horas. O nível 1 despeja ainda o zoom em 10-15 minutos na maioria dos dias.
Meu primeiro pensamento foi que poderia haver "sujeira" no maior sistema de arquivos (/ home), que foi o primeiro a ir devagar. Mas o fsck não o curou.
Eu me inspirei a verificar o status do dispositivo smartctl na unidade com os sistemas de arquivos ativos e, na verdade, encontrei algumas centenas de milhares de erros de leitura transitórios. Substituído a unidade e restaurado dos backups (que eram bons). Problema persistiu. O smartctl na unidade de substituição mostrou MILHÕES de erros de leitura transitórios. Alguns artigos na net sugeriram que isso poderia ser bom e normal para os drives modernos de terabytes. No entanto, substituí a unidade por um SSD, mas nada mudou.
O sistema de arquivos ao vivo estava em um disco Seagate Barracuda de 500 GB. Sempre me disseram que o Seagate Barracuda era o padrão ouro das unidades.
O disco temporário de backup é uma unidade WD de 1TB. smartctl mostra 0 erros nele.
Alguma idéia de por que esse problema apareceu do nada e o que pode estar causando isso?
Algumas pessoas dirão que o dump / restore é muito antigo para ser usado hoje, mas acho muito mais fácil gerenciar esse uso do que o rsync. Eu tenho incrementais diários e, em seguida, arquivar o nível semanal 0 para um disco BD-R DL.
AJUDA