Eu adicionei o comando --ignore-existing e parece que ele não alterará nada e só baixará novos arquivos.
rsync -vzr --ignore-existing -e
Editar: Quando há novos arquivos, ainda leva mais tempo em cada ciclo.
Eu tenho uma linha simples de rsync no meu crontab que obtém arquivos de backup do servidor prod para outro.
Parece que está tocando nos arquivos já existentes na pasta de destino. Dessa forma, o backup aumentaria gradualmente cada intervalo.
Por favor, veja a data e a hora em que os arquivos abaixo foram alterados.
Como eu uso o rsync para não tocar (e baixar?) os arquivos que ele já possui. Eu não preciso de nenhuma soma de verificação calculada, uma vez que os backups são criados, eles não mudam mais.
rsync -vzre 'ssh' stor@server:/backup/system/ /storage/share/Backup/Server
Os arquivos a serem buscados:
-rw-r-x--- 1 root stor 896K Jun 22 05:02 giant-140622-etc.zip
-rw-r-x--- 1 root stor 620K Jun 22 05:02 giant-140622-sql.zip
-rw-r-x--- 1 root stor 84M Jun 22 05:02 giant-140622-www.zip
-rw-r-x--- 1 root stor 899K Jun 25 05:00 giant-140625-etc.zip
-rw-r-x--- 1 root stor 603K Jun 25 05:00 giant-140625-sql.zip
-rw-r-x--- 1 root stor 84M Jun 25 05:00 giant-140625-www.zip
-rw-r-x--- 1 root stor 899K Jun 28 05:00 giant-140628-etc.zip
-rw-r-x--- 1 root stor 620K Jun 28 05:00 giant-140628-sql.zip
-rw-r-x--- 1 root stor 86M Jun 28 05:00 giant-140628-www.zip
-rw-r-x--- 1 root stor 899K Jun 30 05:00 giant-140630-etc.zip
-rw-r-x--- 1 root stor 617K Jun 30 05:00 giant-140630-sql.zip
-rw-r-x--- 1 root stor 86M Jun 30 05:00 giant-140630-www.zip
O destino:
-rw-r-x--- 1 stor stor 896K Jun 30 06:06 giant-140622-etc.zip
-rw-r-x--- 1 stor stor 620K Jun 30 06:06 giant-140622-sql.zip
-rw-r-x--- 1 stor stor 84M Jun 30 06:06 giant-140622-www.zip
-rw-r-x--- 1 stor stor 899K Jun 30 06:06 giant-140625-etc.zip
-rw-r-x--- 1 stor stor 603K Jun 30 06:06 giant-140625-sql.zip
-rw-r-x--- 1 stor stor 84M Jun 30 06:06 giant-140625-www.zip
-rw-r-x--- 1 stor stor 899K Jun 30 06:06 giant-140628-etc.zip
-rw-r-x--- 1 stor stor 620K Jun 30 06:06 giant-140628-sql.zip
-rw-r-x--- 1 stor stor 86M Jun 30 06:06 giant-140628-www.zip
-rw-r-x--- 1 stor stor 899K Jun 30 06:07 giant-140630-etc.zip
-rw-r-x--- 1 stor stor 617K Jun 30 06:08 giant-140630-sql.zip
-rw-r-x--- 1 stor stor 86M Jun 30 06:10 giant-140630-www.zip
Atualização:
Quando executo o comando rsync (com o --skip-existing arg) do shell, ele só faz o download de novos arquivos inexistentes e pula os arquivos que já possui.
Ao investigar o comportamento do mesmo comando exato executado por um cronjob , os arquivos já existentes mudam a cada ciclo e todo o trabalho é incrementalmente mais longo a cada cycle ( compara os tempos acima, cronjob começando às 06:00, 2 minutos por arquivo, mesmo que eles já existam ).
rsync -vzr --ignore-existing -e 'ssh -i /path/id_rsa -l backup' [email protected]:/backup/system/ /nfs/share-private/Backup/Server
Atualização:
Aqui estão os arquivos de julho, eu coloquei uma linha extra em branco, por favor, veja os horários, que começaram com 06:01 e aumentaram cada novo arquivo.
-rw-r-x--- 1 stor stor 899K Jul 4 06:01 giant-140702-etc.zip
-rw-r-x--- 1 stor stor 621K Jul 4 06:01 giant-140702-sql.zip
-rw-r-x--- 1 stor stor 86M Jul 4 06:03 giant-140702-www.zip
^-- 01 to 03
-rw-r-x--- 1 stor stor 899K Jul 4 06:04 giant-140704-etc.zip
-rw-r-x--- 1 stor stor 634K Jul 4 06:05 giant-140704-sql.zip
-rw-r-x--- 1 stor stor 86M Jul 8 06:02 giant-140704-www.zip
^-- ???
-rw-r-x--- 1 stor stor 899K Jul 8 06:03 giant-140706-etc.zip
-rw-r-x--- 1 stor stor 629K Jul 8 06:03 giant-140706-sql.zip
-rw-r-x--- 1 stor stor 86M Jul 8 06:06 giant-140706-www.zip
^-- 03 - 06
-rw-r-x--- 1 stor stor 899K Jul 8 06:07 giant-140708-etc.zip
-rw-r-x--- 1 stor stor 629K Jul 8 06:07 giant-140708-sql.zip
-rw-r-x--- 1 stor stor 86M Jul 8 06:10 giant-140708-www.zip
^-- 07 - 10
Agora, quando eu imagino ir em outro mês, o tempo seria como:
-rw-r-x--- 1 stor stor 899K Jul 8 06:32 giant-140808-etc.zip
-rw-r-x--- 1 stor stor 629K Jul 8 06:32 giant-140808-sql.zip
-rw-r-x--- 1 stor stor 86M Jul 8 06:35 giant-140808-www.zip
^-- what I imagine to happen
Por padrão, rsync lerá o arquivo inteiro na origem e no destino, para verificar se são idênticos. Isso não consome a largura de banda da rede, pois ela só estará comparando um valor de hash. Mas gasta tempo lendo do disco.
Em um cenário de uso, descobri que isso é terrivelmente ineficiente porque os arquivos de origem só estavam sendo anexados. Eu usei o --size-only , que funcionou bem para mim.
Existem algumas outras opções, que parecem ser aplicáveis, --append e --append-verify , mas eu mesmo não testei isso.
Não parece que você tem um diretório com muitos arquivos pequenos, então o tempo para ler a lista de diretórios do disco e informar cada arquivo, não deve ser um grande problema.
Acho que adicionar -t à sua lista de argumentos ajudará.
Para verificar isso, você pode adicionar --itemize-changes aos argumentos (sem -t ). Se eu entendi corretamente, isso mostraria o T -flag em cada linha
man 1 rspec :
A t means the modification time is different and is being updated to the sender’s value (requires --times). An alternate value of T means that the modification time will be set to the transfer time, which happens when a file/symlink/device is updated without --times and when a symlink is changed and the receiver can’t set its time. (Note: when using an rsync 3.0.0 client, you might see the s flag combined with t instead of the proper T flag for this time-setting failure.)
Depois disso, adicione -t ao comando (keep --itemize-changes ) e você receberá um t -flag em cada linha. Na próxima execução, a lista conterá apenas os novos arquivos.
Este é o meu exemplo executado:
krissi@host ~/tmp/rsync % l *
dst:
total 0
src:
total 0
-rw-r--r-- 1 krissi users 0 Jul 13 18:05 bar
-rw-r--r-- 1 krissi users 0 Jul 13 18:05 foo
-rw-r--r-- 1 krissi users 0 Jul 13 18:19 later
krissi@host ~/tmp/rsync % rsync -vzr --itemize-changes src/ dst/
sending incremental file list
>f+++++++++ bar
>f+++++++++ foo
>f+++++++++ later
sent 174 bytes received 69 bytes 486.00 bytes/sec
total size is 0 speedup is 0.00
krissi@host ~/tmp/rsync % l *
dst:
total 0
-rw-r--r-- 1 krissi users 0 Jul 13 18:21 bar
-rw-r--r-- 1 krissi users 0 Jul 13 18:21 foo
-rw-r--r-- 1 krissi users 0 Jul 13 18:21 later
src:
total 0
-rw-r--r-- 1 krissi users 0 Jul 13 18:05 bar
-rw-r--r-- 1 krissi users 0 Jul 13 18:05 foo
-rw-r--r-- 1 krissi users 0 Jul 13 18:19 later
krissi@host ~/tmp/rsync % rsync -vzr --itemize-changes src/ dst/
sending incremental file list
>f..T...... bar
>f..T...... foo
>f..T...... later
sent 174 bytes received 69 bytes 486.00 bytes/sec
total size is 0 speedup is 0.00
krissi@host ~/tmp/rsync % rsync -vzr --itemize-changes src/ dst/
sending incremental file list
>f..T...... bar
>f..T...... foo
>f..T...... later
sent 174 bytes received 69 bytes 486.00 bytes/sec
total size is 0 speedup is 0.00
krissi@host ~/tmp/rsync % rsync -vzrt --itemize-changes src/ dst/
sending incremental file list
.d..t...... ./
>f..t...... bar
>f..t...... foo
>f..t...... later
sent 177 bytes received 72 bytes 498.00 bytes/sec
total size is 0 speedup is 0.00
krissi@host ~/tmp/rsync % rsync -vzrt --itemize-changes src/ dst/
sending incremental file list
sent 66 bytes received 12 bytes 156.00 bytes/sec
total size is 0 speedup is 0.00
krissi@host ~/tmp/rsync % l *
dst:
total 0
-rw-r--r-- 1 krissi users 0 Jul 13 18:05 bar
-rw-r--r-- 1 krissi users 0 Jul 13 18:05 foo
-rw-r--r-- 1 krissi users 0 Jul 13 18:19 later
src:
total 0
-rw-r--r-- 1 krissi users 0 Jul 13 18:05 bar
-rw-r--r-- 1 krissi users 0 Jul 13 18:05 foo
-rw-r--r-- 1 krissi users 0 Jul 13 18:19 later
Por que você diz que leva mais tempo a cada vez? como isso é possível?
talvez seja o programa que gera os arquivos que estão tocando neles?
experimente com --checksum : ignorar com base na soma de verificação, não no tempo de modulação & tamanho, veja se isso muda alguma coisa (eu não manteria essa opção porque lê cada arquivo do disco toda vez, muito caro, só estou sugerindo para encontrar o problema.)
(e talvez tente depurar com a opção -t , que preserva os tempos de modificação)