O que f +++++++++ significa em logs rsync?

Estou usando rsyncpara fazer backup dos arquivos do meu servidor e tenho duas perguntas:

1. No meio do processo, preciso parar e começar de rsyncnovo.
   Vai rsynccomeçar do ponto onde parou ou vai reiniciar do começo?

2. Nos arquivos de log, vejo "f+++++++++". O que isso significa?

por exemplo:

2010/12/21 08:28:37 [4537] >f.st...... iddd/logs/website-production-access_log
2010/12/21 08:29:11 [4537] >f.st...... iddd/web/website/production/shared/log/production.log
2010/12/21 08:29:14 [4537] .d..t...... iddd/web/website/production/shared/sessions/
2010/12/21 08:29:14 [4537] >f+++++++++ iddd/web/website/production/shared/sessions/ruby_sess.017a771cc19b18cd
2010/12/21 08:29:14 [4537] >f+++++++++ iddd/web/website/production/shared/sessions/ruby_sess.01eade9d317ca79a

Vamos dar uma olhada em como o rsync funciona e entender melhor as linhas de resultados enigmáticas:

1 - Uma grande vantagem do rsync é que, após uma interrupção, na próxima vez, ele continua sem problemas.

A próxima chamada de rsync não transferirá os arquivos novamente, que já foram transferidos, se eles não foram alterados nesse meio tempo. Mas começará a verificar todos os arquivos novamente desde o início para descobrir, pois não está ciente de que foi interrompido.

2 - Cada caractere é um código que pode ser traduzido se você ler a seção para -i, --itemize-changesemman rsync

Decodificando seu arquivo de registro de exemplo da pergunta:

> f.st ......

> - the item is received
f - it is a regular file
s - the file size is different
t - the time stamp is different

.d..t ......

. - the item is not being updated (though it might have attributes 
    that are being modified)
d - it is a directory
t - the time stamp is different

> f +++++++++

> - the item is received
f - a regular file
+++++++++ - this is a newly created item

A parte relevante da página de manual do rsync:

-i, --itemize-changes

Solicita uma lista simples detalhada das mudanças que estão sendo feitas em cada arquivo, incluindo mudanças de atributo. Isso é exatamente o mesmo que especificar --out-format = '% i% n% L'. Se você repetir a opção, os arquivos inalterados também serão produzidos, mas apenas se o rsync de recebimento for pelo menos a versão 2.6.7 (você pode usar -vv com versões mais antigas do rsync, mas isso também ativa a saída de outras mensagens detalhadas sábios).

O escape "% i" tem uma saída enigmática de 11 letras. O formato geral é como a string YXcstpoguax, onde Y é substituído pelo tipo de atualização que está sendo feita, X é substituído pelo tipo de arquivo e as outras letras representam atributos que podem ser produzidos se estiverem sendo modificados.

Os tipos de atualização que substituem o Y são os seguintes:

• Um <significa que um arquivo está sendo transferido para o host remoto (enviado).
• Um >significa que um arquivo está sendo transferido para o host local (recebido).
• Um csignifica que uma mudança / criação local está ocorrendo para o item (como a criação de um diretório ou a mudança de um link simbólico, etc.).
• Um hsignifica que o item é um link físico para outro item (requer --hard-links).
• Um .significa que o item não está sendo atualizado (embora possa ter atributos que estão sendo modificados).
• Um *significa que o resto da área de saída detalhada contém uma mensagem (por exemplo, "excluindo").

Os tipos de arquivo que substituem o X são: fpara um arquivo, um dpara um diretório, um Lpara um link simbólico, um Dpara um dispositivo e um Spara um arquivo especial (por exemplo, sockets nomeados e fifos).

As outras letras na string acima são as letras reais que serão geradas se o atributo associado para o item estiver sendo atualizado ou um "." para nenhuma mudança. Três exceções são: (1) um item recém-criado substitui cada letra por um "+", (2) um item idêntico substitui os pontos por espaços e (3) um atributo desconhecido substitui cada letra por um "?" (isso pode acontecer ao falar com um rsync mais antigo).

O atributo associado a cada letra é o seguinte:

• Um csignifica que um arquivo regular tem uma soma de verificação diferente (requer --checksum) ou que um link simbólico, dispositivo ou arquivo especial tem um valor alterado. Observe que se você estiver enviando arquivos para um rsync antes de 3.0.1, este sinalizador de alteração estará presente apenas para arquivos regulares com checksum diferente.
• A ssignifica que o tamanho de um arquivo normal é diferente e será atualizado pela transferência do arquivo.
• A tsignifica que a hora de modificação é diferente e está sendo atualizada para o valor do remetente (requer --times). Um valor alternativo de T significa que o tempo de modificação será definido para o tempo de transferência, o que acontece quando um arquivo / link simbólico / dispositivo é atualizado sem --times e quando um link simbólico é alterado e o receptor não pode definir seu tempo. (Observação: ao usar um cliente rsync 3.0.0, você pode ver o sinalizador s combinado com t em vez do sinalizador T apropriado para esta falha de configuração de tempo.)
• A psignifica que as permissões são diferentes e estão sendo atualizadas para o valor do remetente (requer --perms).
• Um osignifica que o proprietário é diferente e está sendo atualizado com o valor do remetente (requer privilégios --owner e superusuário).
• A gsignifica que o grupo é diferente e está sendo atualizado com o valor do remetente (requer --group e autoridade para definir o grupo).
• O uslot está reservado para uso futuro.
• Os ameios que as informações ACL alterada.
• Os xmeios de que as informações de atributo estendido alterados.

Uma outra saída é possível: ao excluir arquivos, o "% i" produzirá a string "* deleting" para cada item que está sendo removido (supondo que você esteja falando com um rsync recente o suficiente para que ele registre as exclusões em vez de enviá-las como uma mensagem detalhada).

Algum tempo atrás, eu precisava entender a rsyncsaída de um script que estava escrevendo. Durante o processo de escrever esse script, pesquisei no Google e descobri o que @mit havia escrito acima . Usei essas informações, bem como a documentação de outras fontes, para criar meu próprio primer sobre os sinalizadores de bits e como obter rsyncsinalizadores de bits de saída para todas as ações (isso não é feito por padrão).

Estou postando essa informação aqui na esperança de que ajude outras pessoas que (como eu) tropeçam nesta página por meio de pesquisa e precisam de uma explicação melhor rsync.

Com a combinação do --itemize-changessinalizador e do -vvvsinalizador, rsyncnos dá uma saída detalhada de todas as alterações do sistema de arquivos que foram identificadas no diretório de origem em comparação com o diretório de destino. Os sinalizadores de bits produzidos por rsyncpodem ser decodificados para determinar o que mudou. Para decodificar o significado de cada bit, use a tabela a seguir.

Explicação de cada posição de bit e valor na rsyncsaída de:

YXcstpoguax  path/to/file
|||||||||||
||||||||||╰- x: The extended attribute information changed
|||||||||╰-- a: The ACL information changed
||||||||╰--- u: The u slot is reserved for future use
|||||||╰---- g: Group is different
||||||╰----- o: Owner is different
|||||╰------ p: Permission are different
||||╰------- t: Modification time is different
|||╰-------- s: Size is different
||╰--------- c: Different checksum (for regular files), or
||              changed value (for symlinks, devices, and special files)
|╰---------- the file type:
|            f: for a file,
|            d: for a directory,
|            L: for a symlink,
|            D: for a device,
|            S: for a special file (e.g. named sockets and fifos)
╰----------- the type of update being done::
             <: file is being transferred to the remote host (sent)
             >: file is being transferred to the local host (received)
             c: local change/creation for the item, such as:
                - the creation of a directory
                - the changing of a symlink,
                - etc.
             h: the item is a hard link to another item (requires 
                --hard-links).
             .: the item is not being updated (though it might have
                attributes that are being modified)
             *: means that the rest of the itemized-output area contains
                a message (e.g. "deleting")

Alguns exemplos de saída de rsync para vários cenários:

>f+++++++++ some/dir/new-file.txt
.f....og..x some/dir/existing-file-with-changed-owner-and-group.txt
.f........x some/dir/existing-file-with-changed-unnamed-attribute.txt
>f...p....x some/dir/existing-file-with-changed-permissions.txt
>f..t..g..x some/dir/existing-file-with-changed-time-and-group.txt
>f.s......x some/dir/existing-file-with-changed-size.txt
>f.st.....x some/dir/existing-file-with-changed-size-and-time-stamp.txt 
cd+++++++++ some/dir/new-directory/
.d....og... some/dir/existing-directory-with-changed-owner-and-group/
.d..t...... some/dir/existing-directory-with-different-time-stamp/

Capturando rsynca saída (com foco nos sinalizadores de bits):

Em minha experiência, tanto o --itemize-changessinalizador quanto o -vvvsinalizador são necessários para obter rsynca saída de uma entrada para todas as alterações do sistema de arquivos. Sem o -vvvsinalizador triple verbose ( ), eu não estava vendo as alterações de diretório, link e dispositivo listadas. Vale a pena experimentar sua versão do rsync para ter certeza de que está observando e anotando tudo o que você esperava.

Um uso prático dessa técnica é adicionar o --dry-runsinalizador ao comando e coletar a lista de alterações, conforme determinado por rsync, em uma variável (sem fazer alterações) para que você mesmo possa fazer algum processamento na lista. Algo como o seguinte capturaria a saída em uma variável:

file_system_changes=$(rsync --archive --acls --xattrs \
    --checksum --dry-run \
    --itemize-changes -vvv \
    "/some/source-path/" \
    "/some/destination-path/" \
| grep -E '^(\.|>|<|c|h|\*).......... .')

No exemplo acima, a saída (stdout) de rsyncé redirecionada para grep(via stdin) para que possamos isolar apenas as linhas que contêm sinalizadores de bit.

Processando a saída capturada:

O conteúdo da variável pode então ser registrado para uso posterior ou iterado imediatamente para itens de interesse. Eu uso essa tática exata no roteiro que escrevi durante a pesquisa sobre rsync. Você pode olhar o script ( https://github.com/jmmitchell/movestough ) para exemplos de pós-processamento da saída capturada para isolar novos arquivos, arquivos duplicados (mesmo nome, mesmo conteúdo), colisões de arquivos (mesmo nome, diferente conteúdo), bem como as alterações nas estruturas de subdiretórios.

1) Wodin, isso não é totalmente verdade. Se estiver usando a tag --partial ou -P (igual a --partial --progress), o rsync retoma as transferências interrompidas.

2) Exatamente, essa é a saída comum para a tag --itemize-changes.

1.) Vai "reiniciar a sincronização", mas não vai transferir arquivos do mesmo tamanho e carimbo de data / hora, etc. Primeiro, ele cria uma lista de arquivos a serem transferidos e durante este estágio verá que já transferiu alguns arquivos e irá ignorá-los. Você deve dizer ao rsync para preservar os carimbos de data / hora, etc. (por exemplo, usando rsync -a ...)

Enquanto o rsync está transferindo um arquivo, ele o chamará de algo como, em .filename.XYZABCvez de filename. Então, quando terminar de transferir esse arquivo, ele irá renomeá-lo. Portanto, se você encerrar o rsync durante a transferência de um arquivo grande, terá que usar a opção --partial para continuar a transferência em vez de começar do zero.

2.) Não sei o que é. Você pode colar alguns exemplos?

EDITAR: De acordo com http://ubuntuforums.org/showthread.php?t=1342171 esses códigos são definidos na página de manual do rsync na seção para a -i, --itemize-changesopção.

Parte fixa se minha resposta for baseada na de João