Normalmente, rsyncsalta i file quando i file hanno dimensioni e tempi identici sul lato di origine e di destinazione. Questa è un'euristica che di solito è una buona idea, in quanto impedisce rsyncdi dover esaminare i contenuti dei file che sono molto probabilmente identici sul lato di origine e di destinazione.
--ignore-timesdice rsyncdi disattivare l'euristica dei tempi e delle dimensioni dei file e quindi trasferire incondizionatamente TUTTI i file dall'origine alla destinazione. rsyncprocederà quindi a leggere tutti i file sul lato sorgente, poiché dovrà utilizzare il suo algoritmo di trasferimento delta o semplicemente inviare tutti i file nella loro interezza, a seconda che l' --whole-fileopzione sia stata specificata.
--checksummodifica anche l'euristica di tempi e dimensioni dei file, ma qui ignora i tempi ed esamina solo le dimensioni. I file sui lati di origine e destinazione di dimensioni diverse vengono trasferiti, poiché sono ovviamente diversi. I file con le stesse dimensioni vengono rsyncsottoposti a checksum (con MD5 nella versione 3.0.0+ o con MD4 nelle versioni precedenti) e vengono trasferiti anche quelli trovati con somme diverse.
Nei casi in cui i lati di origine e di destinazione sono sostanzialmente gli stessi, --checksumla maggior parte dei file verrà verificata su entrambi i lati. Ciò potrebbe richiedere molto tempo, ma il risultato è che il minimo indispensabile di dati verrà effettivamente trasferito via cavo, soprattutto se viene utilizzato l'algoritmo di trasferimento delta. Naturalmente, questa è una vittoria solo se si hanno reti molto lente e / o CPU molto veloci.
--ignore-timesd'altra parte, invierà più dati sulla rete e causerà la lettura di tutti i file di origine, ma almeno non imporrà l'onere aggiuntivo di calcolare molti hashs crittograficamente forti sulle CPU di origine e di destinazione. Mi aspetto che questa opzione funzioni meglio di --checksumquando le tue reti sono veloci e / o la tua CPU relativamente lenta.
Penso che lo userei sempre --checksumo --ignore-timesse trasferissi i file a una destinazione in cui si sospettava che il contenuto di alcuni file fosse corrotto, ma i cui tempi di modifica non fossero cambiati. Non riesco davvero a pensare a nessun altro buon motivo per usare entrambe le opzioni, anche se ci sono probabilmente altri casi d'uso.
--checksumutile insieme a--itemize-changesverificare i backup. Ogni tanto i miei script di backup eseguono un confronto completo in questo modo dopo il completamento degli attuali aggiornamenti giornalieri / settimanali. Ricevo un'e-mail contrassegnata come urgente se l'--itemize-changesoutput è inaspettato, quindi so che c'è un potenziale problema che dovrei esaminare.