Ferramenta ou script para detectar arquivos movidos ou renomeados no Linux antes de um backup [fechado]

Basicamente, estou pesquisando para ver se existe uma ferramenta ou script que pode detectar arquivos movidos ou renomeados, para que eu possa obter uma lista de arquivos renomeados / movidos e aplicar a mesma operação na outra extremidade da rede para economizar largura de banda.

Basicamente, o armazenamento em disco é barato, mas a largura de banda não, e o problema é que os arquivos geralmente são reorganizados ou movidos para uma estrutura de diretórios melhor, portanto, quando você usa o rsync para fazer o backup, o rsync não notará que é renomeado ou arquivo movido e retransmiti-lo pela rede novamente, apesar de ter o mesmo arquivo do outro lado.

Então, eu estou me perguntando se existe um script ou ferramenta que possa gravar onde estão todos os arquivos e seus nomes; logo antes de um backup, ele examinaria novamente e detectaria arquivos movidos ou renomeados, para que eu possa pegar essa lista e reaplicar a operação de mover / renomear do outro lado.

Aqui está uma lista dos recursos "gerais" dos arquivos:

1. Arquivos grandes e imutáveis
2. Eles podem ser renomeados ou movidos

[Editar:] Todas essas são boas respostas, e o que eu acabei fazendo no final foi analisar todas as respostas e estará escrevendo algum código para lidar com isso. Basicamente, o que estou pensando / trabalhando agora é:

1. Usar algo como o AIDE para a verificação "inicial" e permitir que eu mantenha somas de verificação nos arquivos porque eles nunca devem mudar, portanto, isso ajudaria na detecção de corrupção.
2. Criando um daemon inotify que monitore esses arquivos / diretório e registre quaisquer alterações relacionadas a renomeações e mova os arquivos para um arquivo de log.
3. Existem alguns casos extremos em que o inotify pode falhar ao registrar que algo aconteceu com o sistema de arquivos, portanto, há uma etapa final de usar find para procurar no sistema de arquivos por arquivos com um tempo de alteração posterior ao último backup .

Isso tem vários benefícios:

1. Soma de verificação / etc da AIDE para poder verificar / certificar-se de que algumas mídias não foram corrompidas
2. O Inotify mantém baixo o uso de recursos e não é necessário verificar novamente o sistema de arquivos repetidamente
3. Não há necessidade de corrigir o rsync; Se eu precisar consertar as coisas que puder, mas preferiria evitar consertar as coisas para manter a carga mais baixa (o IE não precisa corrigir novamente sempre que houver uma atualização).
4. Eu usei o Unison antes e é muito bom, no entanto, eu poderia jurar que o Unison mantém cópias no sistema de arquivos e que seus arquivos "archive" podem crescer bastante grandes?

O Unison http://www.cis.upenn.edu/~bcpierce/unison/ afirma ser capaz de detectar movimentos e renomear.

Existem algumas correções no rsync para adicionar a detecção de mudança / renomeação:

http://gitweb.samba.org/?p=rsync-patches.git;a=blob;f=detect-renamed-lax.diff;h=1ff593c8f97a97e8970d43ff5a62dfad5abddd75;hb=master

http://gitweb.samba.org/?p=rsync-patches.git;a=blob;f=detect-renamed.diff;h=c3e6e846eab437e56e25e2c334e292996ee84345;hb=master

Entrada do Bugzilla que rastreia esse problema: https://bugzilla.samba.org/show_bug.cgi?id=2294

Essa é uma solução um pouco estranha, mas ... o git detecta movimentos e renomeia com base no conteúdo do arquivo, portanto, se você mantivesse os diretórios em questão sob controle de versão, o git seria capaz de detectar movimentos e outros e evitar transferir o conteúdo (já que ele já está nos dois lados do fio) enquanto ainda move as coisas pela árvore.

Apenas um pensamento.

sugestões interessantes aqui. Também pensei em usar os recursos do sistema de arquivos, ou seja, o ZFS. Achei estranho que não houvesse uma ferramenta que fizesse essa coisa simples. A opção Unison não funciona na maioria dos casos, como as pessoas relatam, também não para mim.

Quero que o recurso mantenha o backup da minha coleção de filmes no segundo disco rígido sincronizado ao rearrar as pastas.

Agora eu encontrei esse script C simples http://sourceforge.net/projects/movesync/

Parece funcionar bem. Execute-o e sincronize normalmente com, ou seja, uníssono.

Você pode usar um IDS baseado em host , como o AIDE, e gravar um script de wrapper usando sua saída. Você provavelmente teria que escrever uma lógica mais complexa considerando as somas de verificação.

Caso contrário, um sistema de arquivos baseado em rede pode fazer sentido, pois as alterações serão refletidas em todos os locais. No entanto, suspeito que você esteja transferindo pela Internet, o que limitará as opções aqui.

Você pode tentar uníssono ; especialmente o

-xferbycopying otimizar transferências usando cópias locais (padrão true)

opção mencionada nos documentos como

Quando essa preferência é definida, o Unison tentará evitar a transferência do conteúdo do arquivo pela rede, reconhecendo quando um arquivo com o conteúdo necessário já existe na réplica de destino. Isso geralmente permite que as movimentações de arquivos sejam propagadas muito rapidamente. O valor padrão é verdadeiro.

parece que pode fazer o que você deseja.

Syrep faz o que você precisa. Ele mantém os resumos das mensagens em uma árvore de arquivos atualizados; manter os resumos disponíveis torna mais eficiente que o rsync. Ele foi projetado para sneakernet, portanto, você pode querer adicionar um invólucro que atualiza / compila / mescla de uma só vez.

Não tenho certeza se existe uma ferramenta existente que faça isso por você, mas você pode escrever um script simples que execute apenas um finddiretório base onde mtimeé mais recente que o último backup. Isso fornecerá uma lista de todos os arquivos que foram modificados . Se um arquivo foi simplesmente movido, ele não aparecerá na lista. Infelizmente, essa lista incluirá os diretórios para os quais os arquivos foram movidos, pois o diretório é atualizado quando um arquivo é adicionado / removido.

Com essa lista de arquivos, você pode usar o rsync para sincronizar apenas esses arquivos. O rsync tem uma opção para ler em uma lista de arquivos. Aqui está um teste mostrando este exemplo:

$ cd tmp
$ echo test > test
$ ls -la
total 16
drwxr-xr-x 2 root root 4096 Aug 18 11:34 .
drwxr-x--- 5 root root 4096 Aug 18 11:34 ..
-rw-r--r-- 1 root root    5 Aug 18 11:34 test
$ mkdir tmp2
$ find . -mmin 1
$ date
Wed Aug 18 11:35:10 EDT 2010
$ find . -mmin 1
$ find . -mmin 2
.
./test
./tmp2
$ mv test tmp2
$ find . -mmin 1
.
./tmp2

Observe que esperei aproximadamente 1 minuto entre executar cada findcomando. A partir disso, mostra que, ao criar o arquivo, ele é listado por find. Se eu mover o arquivo para outro diretório e re-executar o findcomando, ele exibe apenas o diretório Mudei o arquivo para, e não o arquivo em si. Você pode usar uma combinação de comandos finde rsyncpara listar apenas os arquivos desejados, provavelmente isso pode atingir seu objetivo.

Eu espero que isso ajude.

Dado o seu fluxo de trabalho, pergunto-me se trabalhar no nível do arquivo (como o que outros propuseram até agora) é a melhor solução. Você poderia trabalhar ...

No nível do sistema de arquivos

A idéia é fazer com que o sistema de arquivos acompanhe as operações entre os backups. Em vez de fazer um backup do sistema de arquivos, faça backup do diário do sistema de arquivos (e, opcionalmente, reproduza as alterações na máquina de backup, se desejar um backup pronto para uso). Um diário do sistema de arquivos naturalmente expressa movimentos e exclusões em alguns bytes.

O Fuse torna relativamente fácil projetar um sistema de arquivos com requisitos específicos localizados em cima de um "sistema de arquivos real". Eu nunca o usei, mas o LoggedFS parece promissor.

Com esta solução, valeria a pena ter alguma forma de compactação de diário. Por exemplo, se um arquivo foi substituído 10 vezes, mantenha apenas sua última atualização no diário. Outra otimização que vale a pena seria reconhecer as operações de cópia e, melhor ainda, as edições (por exemplo, criar um arquivo que é quase totalmente idêntico a outro arquivo). Não sei se alguém implementou isso. Para o seu fluxo de trabalho, não acho que isso importaria muito.

No nível do volume

A idéia é fazer com que o gerenciador de volumes acompanhe as operações entre os backups. Em vez de fazer um backup do sistema de arquivos, tire uma captura instantânea com o gerenciador de volume e faça backup da captura instantânea expressa como uma diferença da captura instantânea anterior.

Isso deve funcionar bem se tudo o que você fizer é criar arquivos, renomeá-los e removê-los. Seria muito mais difícil detectar coisas como cópias e edições ou otimizar a criação de um arquivo seguido por sua exclusão.

O Unison é bom para isso, mas ainda precisa copiar arquivos localmente e não pode detectar uma movimentação / renomeação se o conteúdo do arquivo também foi alterado um pouco.

Criei um script Python simples para detectar arquivos e diretórios renomeados / movidos usando números de inode (apenas * nix) e reproduzir essas alterações na máquina sincronizada. Você pode usá-lo sozinho ou como um "pré-processador de renomeação" para Unison ou rsync. Pode ser encontrado aqui