Strumento o script per rilevare file spostati o rinominati su Linux prima di un backup [chiuso]

Fondamentalmente sto cercando di vedere se esiste uno strumento o uno script in grado di rilevare file spostati o rinominati in modo da poter ottenere un elenco di file rinominati / spostati e applicare la stessa operazione sull'altra estremità della rete per risparmiare sulla larghezza di banda.

Fondamentalmente l'archiviazione su disco è economica ma la larghezza di banda non lo è, e il problema è che i file vengono spesso riorganizzati o spostati in una struttura di directory migliore, quindi quando si utilizza rsync per eseguire il backup, rsync non noterà che è un nome rinominato o ha spostato il file e lo ha ritrasmesso nuovamente sulla rete, nonostante abbia lo stesso file all'altra estremità.

Quindi mi chiedo se esiste uno script o uno strumento in grado di registrare dove sono tutti i file e i loro nomi, quindi appena prima di un backup, eseguirà una nuova scansione e rileverà i file spostati o rinominati, quindi posso prendere quell'elenco e riapplicare l'operazione sposta / rinomina dall'altro lato.

Ecco un elenco delle funzionalità "generali" dei file:

1. Grandi file invariati
2. Possono essere rinominati o spostati

[Modifica:] Queste sono tutte buone risposte, e quello che alla fine faccio alla fine è stato guardare tutte le risposte e scriverò un codice per affrontare questo. Fondamentalmente quello che sto pensando / lavorando ora è:

1. Usare qualcosa come AIDE per la scansione "iniziale" e consentirmi di mantenere i checksum sui file perché non dovrebbero mai cambiare, quindi aiuterebbe a rilevare la corruzione.
2. Creazione di un demone inotify che monitorasse questi file / directory e registrasse qualsiasi modifica relativa alla ridenominazione e spostando i file in un file di registro.
3. Ci sono alcuni casi limite in cui inotify potrebbe non riuscire a registrare che qualcosa è successo al file system, quindi c'è un passaggio finale nell'uso di find per cercare file nel file system che hanno un tempo di cambio più recente dell'ultimo backup .

Ciò ha diversi vantaggi:

1. Checksums / etc da AIDE per poter verificare / assicurarsi che alcuni media non siano stati corrotti
2. Inotify mantiene basso l'utilizzo delle risorse e non è necessario ripetere la scansione del file system
3. Non è necessario patchare rsync; Se devo correggere le cose che posso, ma preferirei evitare di correggere le cose per mantenere il carico più basso, (IE non ha bisogno di ricollegare ogni volta che c'è un aggiornamento).
4. Ho usato Unison in precedenza ed è davvero bello, tuttavia avrei potuto giurare che Unison conserva copie sul filesystem e che i suoi file di "archivio" possono diventare piuttosto grandi?

Unison http://www.cis.upenn.edu/~bcpierce/unison/ afferma di essere in grado di rilevare mosse e rinominazioni.

Esistono un paio di patch da rsync per aggiungere il rilevamento di spostamento / rinomina:

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

Registrazione bugzilla per tracciare questo problema: https://bugzilla.samba.org/show_bug.cgi?id=2294

Questa è una soluzione un po 'strana, ma ... git rileva mosse e rinomina in base al contenuto del file, quindi se dovessi tenere le directory in questione sotto il controllo della versione, git sarebbe in grado di rilevare mosse e simili ed evitare di trasferire il contenuto (dal momento che è già su entrambi i lati del filo) mentre si spostano ancora le cose nell'albero.

Solo un pensiero.

suggerimenti interessanti qui. Ho anche pensato di utilizzare le capacità del filesystem, ad esempio ZFS. Ho trovato strano che non esiste uno strumento che faccia quella cosa semplice. L'opzione Unison non funziona nella maggior parte dei casi come riportato dalle persone, neanche per me.

Voglio che la funzione mantenga sincronizzato il backup della mia collezione di film sul secondo disco rigido durante la riorganizzazione delle cartelle.

Ora ho trovato questo semplice script C http://sourceforge.net/projects/movesync/

Sembra funzionare bene. Eseguilo e poi sincronizza normalmente con ie unison.

Potresti essere in grado di utilizzare un ID basato su host come AIDE e scrivere uno script wrapper usando il suo output. Probabilmente dovresti scrivere una logica più complessa considerando i checksum.

Altrimenti, un file system basato su rete potrebbe avere senso, poiché le modifiche si rifletterebbero in tutte le posizioni. Tuttavia, sospetto che tu stia trasferendo su Internet, il che limiterà le opzioni qui.

Potresti provare all'unisono ; in particolare il

-xferbycopying ottimizza i trasferimenti utilizzando copie locali (impostazione predefinita true)

opzione menzionata nei documenti come

Quando viene impostata questa preferenza, Unison cercherà di evitare il trasferimento del contenuto del file attraverso la rete riconoscendo quando esiste già un file con il contenuto richiesto nella replica di destinazione. In genere ciò consente di propagare gli spostamenti dei file molto rapidamente. Il valore predefinito è true.

sembra che potrebbe fare quello che vuoi.

Syrep fa quello che ti serve. Mantiene aggiornati i digest dei messaggi su un albero di file; mantenere i digest in giro lo rende più efficiente di rsync. È stato progettato per sneakernet, quindi potresti voler aggiungere un wrapper che aggiorni / makepatch / merge in una volta.

Non sono sicuro se esiste uno strumento esistente che fa questo per te, ma potresti scrivere un semplice script che esegue semplicemente un findnella directory di base dove mtimeè più recente dell'ultimo backup. Verrà visualizzato un elenco di tutti i file che sono stati modificati . Se un file è stato semplicemente spostato, non verrà visualizzato nell'elenco. Sfortunatamente, questo elenco includerà le directory in cui sono stati spostati i file, poiché la directory viene aggiornata quando un file viene aggiunto / rimosso.

Con quell'elenco di file, è possibile utilizzare rsync per sincronizzare solo quei file. rsync ha un'opzione per leggere in un elenco di file. Ecco un test che mostra questo esempio:

$ 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

Si noti che ho aspettato circa 1 minuto tra l'esecuzione di ciascun findcomando. Da questo, mostra che durante la creazione iniziale del file, viene elencato da find. Se sposto il file in un'altra directory ed eseguo nuovamente il findcomando, viene visualizzata solo la directory in cui ho spostato il file e non il file stesso. È possibile utilizzare una combinazione di finde rsynccomandi per elencare solo i file desiderati, probabilmente può raggiungere il tuo obiettivo.

Spero che questo possa essere d'aiuto.

Dato il tuo flusso di lavoro, mi chiedo se lavorare a livello di file (come quello che altri hanno proposto finora) sia la soluzione migliore. Potresti lavorare ...

A livello di filesystem

L'idea è che il filesystem tenga traccia delle operazioni tra i backup. Invece di eseguire un backup del filesystem, eseguire il backup del journal del filesystem (e facoltativamente riprodurre le modifiche sul computer di backup, se si desidera un backup pronto per l'uso). Un diario di filesystem esprime naturalmente mosse ed eliminazioni in pochi byte.

Fuse rende relativamente semplice la progettazione di un filesystem con requisiti specifici che si collocano al di sopra di un "filesystem reale". Non l'ho mai usato, ma LoggedFS sembra promettente.

Con questa soluzione, varrebbe la pena avere una qualche forma di compressione del journal. Ad esempio, se un file è stato sovrascritto 10 volte, mantenere solo il suo ultimo aggiornamento nel journal. Un'altra utile ottimizzazione sarebbe quella di riconoscere le operazioni di copia e, ancora meglio, le modifiche (ovvero la creazione di un file che è principalmente ma non completamente identico a un altro file). Non so se qualcuno lo abbia implementato. Per il tuo flusso di lavoro, non penso che importi molto comunque.

A livello di volume

L'idea è che il gestore di volumi tenga traccia delle operazioni tra i backup. Invece di fare un backup del filesystem, scatta un'istantanea con il gestore di volumi ed esegui il backup dell'istantanea espressa come diff dall'istantanea precedente.

Questo dovrebbe funzionare bene se tutto ciò che fai è creare file, rinominarli e rimuoverli. Sarebbe molto più difficile rilevare cose come copie e modifiche o ottimizzare la creazione di un file seguito dalla sua eliminazione.

Unison è utile, ma deve comunque copiare i file localmente e non è in grado di rilevare uno spostamento / ridenominazione se anche il contenuto del file è cambiato un po '.

Ho creato un semplice script Python per rilevare file e directory rinominati / spostati utilizzando i numeri di inode (solo * nix) e riprodurre queste modifiche sulla macchina sincronizzata. Puoi usarlo da solo o come "rinominare preprocessore" per Unison o rsync. Può essere trovato qui