Fazendo backup de um SSD local demorando mais do que o esperado

Question

Em um novo sistema Ubuntu 18.04, decidi dar uma chance ao Deja-Dup. É apenas uma GUI para Duplicity (que usa o rsync). Cerca de 850 GB de dados precisam de backup. O SSD de origem foi NVMe. O SSD de destino era SATA. O backup inicial (completo) demorou cerca de 7 horas.

No dia seguinte, eu não fiz nada mais do que verificar e-mail e instalar um aplicativo - que adicionou ~ 230MB - antes de executar o Deja-Dup novamente.

O Deja-Dup foi executado por aproximadamente 39 minutos carregando um único núcleo em 35 a 70% durante toda a duração.

A duplicidade foi invocada três vezes:

• A fase de digitalização fixou um núcleo em 100% por 18 minutos.
• A fase de backup localizou um núcleo em 100% por 16 minutos.
• A fase de verificação fixou um núcleo em 100% por 5 minutos.

Isso está em um novo computador com muita RAM. O backup não foi criptografado.

Agora, espero que os backups iniciais (completos) demorem um pouco, e tudo bem. O que eu não espera é que ~ 230MB de novos dados demorem ~ 39 minutos para serem armazenados em backup (e consumir em uma hora-núcleo coletiva de tempo de CPU).

Há algo errado ou quebrado? Devem os backups incrementais de algumas centenas de megabytes consumir tanto tempo? Eu esperava algo abaixo de 5 minutos, não ~ 39. Por que está demorando tanto?

(Se eu tivesse um SSD SATA de 1TB sobressalente, eu o conectaria e apenas rsincronizaria os dados diretamente para ver se isso é visivelmente mais rápido - mas infelizmente eu não faço isso.)

Atualização 1: executei um backup manual após alterações insignificantes (alguns KB de novos emails) e o tempo gasto foi o mesmo (~ 39 minutos). Assim, o tempo gasto parece ter pouco a ver com a quantidade de novos dados que precisam de backup.

Atualização 2: O monitoramento com o iotop revelou que a fase de varredura indica 7.36GB da unidade. Agora, obviamente, não são os 850GB inteiros ... mas não estão muito distantes do número que você obtém se multiplicar o número de arquivos na unidade de origem (1174000) pelo tamanho do bloco / cluster (4096) - ou seja, 4.81GB. Não sei como contabilizar os 2,5 GB restantes, se assim fosse.

    

Answer 1

Posso confirmar que a combinação Deja-Dup / Duplicity apenas torna o processo de backup atrozmente lento (~ 156x mais lento, na verdade).

Acabei limpando o backup do Deja-Dup / Duplicity e usei o rsync puro. Os backups estão demorando apenas 15 segundos.

$ rsync -a --delete /home/tim /media/tim/BackupDrive/

A menos que você realmente, realmente precise da simplicidade que o Deja-Dup oferece ou dos recursos que o Duplicity oferece, então não se preocupe - você está apenas desperdiçando ciclos de CPU, tempo, eletricidade, causando desgaste desnecessário em sua unidade e você terá um backup frágil. Deja-Dup / Duplicity é uma maneira ineficiente de simplesmente fazer backup de arquivos de uma unidade local para outra.

Para backups simples, automatizados e locais, tudo o que você precisa é adicionar uma entrada rsync ao seu crontab.