Os backups do Ubuntu consomem 100% da CPU

Question

Estou usando o software Backups pré-instalado do Ubuntu, com o Ubuntu 16.04 for Desktop (mas talvez o mesmo problema esteja no Ubuntu antigo também).

Cada vez que inicia (uma vez por dia), consome 100% da CPU durante vários minutos. Como eu estava pensando que um software de backup deveria ser silencioso e invisível, isso é muito chato.

Tudo bem se você levar de quatro a cinco vezes mais do que o tempo que leva para fazer as coisas, mas consumir menos CPU e ficar mais quieto.

Existe um modo silencioso para o software Backups ou um software de backup alternativo melhor para o Ubuntu?

    

Answer 1

Honestamente, nunca ouvi falar do programa que você está usando.

Eu pessoalmente prefiro rsnapshot ( link ) para minhas necessidades de backup. O pacote do Ubuntu é o mesmo nome.

Como ele usa hardlinks, a primeira vez que ele é executado pode consumir muito tempo da CPU, mas depois disso, não. (Especialmente se você tiver poucos arquivos que mudam entre os backups - o que é o caso da maioria das pessoas.) Da mesma forma, não usará muito espaço em disco ao longo do tempo.

Dito isto, eu programo backups no meio da noite. Então, diferente de quando eu estou testando o arquivo de configuração, eu realmente não tenho a chance de notar o tempo da CPU. Isso não está relacionado a se você está ou não executando isso em um servidor; rsnapshot pode ser executado na linha de comando. Ou você pode criar um atalho na sua área de trabalho para ele.

Outra sugestão é apenas renice do programa para que ele seja executado com prioridade mais baixa. Se você precisar fazer isso automaticamente, será necessária alguma programação breve. Veja, por exemplo, o link ou apenas procure a frase "renice automático".

Fora do topo da minha cabeça, eu não sei como fazê-lo, mas meu palpite é que você teria que:

• escreva um script bash que descubra o ID do processo
• execute o renice nele
• insira este script em cronjob e execute-o logo após o início do backup ou execute-o repetidamente (por exemplo, a cada hora)

Eu acho que o script pode ser assim, mas você realmente precisa limpar isso, já que está realmente fora da minha cabeça:

 #!/bin/bash
 PID='ps -ef | grep "<program name>" | grep -v "grep" | tr -s ' ' | cut -f 2 -d ' '  | head -n 1'
 renice -10 ${PID}

A linha PID faz isso em ordem:

1. Obtém uma lista de processos.
2. Pesquisas por.
3. Remove qualquer linha que tenha ambos e "grep".
4. Substitua os espaços consecutivos por um único espaço.
5. Pegue os valores da segunda coluna usando o espaço como um delimitador.
6. Pegue a primeira linha.

Espero que isso ajude você a começar!

    

Answer 2

Ubuntu Backup a.k.a DejaDup usa duplicity como o back-end. Houve um bug duplicado em 2014 que foi corrigido e causou isso. Ainda assim acontece, portanto, você poderia reportar outro bug em duplicidade. Esse bug afeta apenas um núcleo físico, portanto, o computador ainda deve ser responsivo em máquinas com várias CPUs. Caso contrário, você poderá considerar as várias outras alternativas de backup ou fazer o backup do seu computador quando não estiver usando-o.

Você também pode tentar um tamanho maior de blocos?

duplicity --max-blocksize 4096 [full/incremental] src dest

   --max-blocksize number
          determines the number of the blocks examined for changes during the diff process.  For files < 1MB
          the blocksize is a constant of 512.  For files over 1MB the size is given by:

          file_blocksize = int((file_len / (2000 * 512)) * 512)
          return min(file_blocksize, globals.max_blocksize)

          where globals.max_blocksize defaults to 2048.  If you specify a larger max_blocksize, your difftar
          files will be larger, but your sigtar files will be smaller.  If you specify a smaller max_blocksize,
          the reverse occurs.  The --max-blocksize option should be in multiples of 512.