Yedeklemeden önce Linux'ta taşınmış veya yeniden adlandırılmış dosyaları algılamak için araç veya komut dosyası [kapalı]

Temel olarak, yeniden adlandırılan / taşınan dosyaların bir listesini almak ve aynı işlemi bant genişliği tasarrufu için ağın diğer ucuna uygulamak böylece taşınmış veya yeniden adlandırılmış dosyaları algılayabilir bir araç veya komut dosyası olup olmadığını görmek için arıyorum.

Temelde disk depolama ucuzdur, ancak bant genişliği değildir ve sorun, dosyaların sık sık yeniden düzenlenmesi veya daha iyi bir dizin yapısına taşınmasıdır, böylece yedeklemeyi yapmak için rsync kullandığınızda, rsync'in yeniden adlandırılmış veya aynı dosya diğer ucunda olmasına rağmen dosyayı taşıdı ve yeniden ağ üzerinden yeniden iletir.

Bu yüzden, tüm dosyaların ve adlarının nerede olduğunu kaydedebilen bir komut dosyası veya araç olup olmadığını merak ediyorum, sonra bir yedeklemeden hemen önce, taşınan veya yeniden adlandırılan dosyaları yeniden tarayabilir ve tespit edebilir, sonra bu listeyi alıp yeniden uygulayabilirim diğer taraftaki taşıma / yeniden adlandırma işlemi.

İşte dosyaların "genel" özelliklerinin bir listesi:

1. Değişmeyen büyük dosyalar
2. Yeniden adlandırılabilir veya taşınabilir

[Düzenle:] Bunların hepsi iyi cevaplar ve sonunda yaptığım şey tüm cevaplara bakıyordu ve bununla başa çıkmak için bazı kodlar yazacaktı. Temelde şimdi düşünüyorum / üzerinde çalışıyorum:

1. "İlk" tarama için AIDE gibi bir şey kullanmak ve hiçbir zaman değişmemesi gerektiği için dosyalar üzerinde sağlama toplamları tutmama izin verin, böylece yolsuzluğun algılanmasına yardımcı olur.
2. Bu dosyaları / dizini izleyen bir inotify arka plan programı oluşturma ve yeniden adlandırma ile ilgili değişiklikleri kaydetme ve dosyaları bir günlük dosyasına taşıma.
3. İnotify'ın dosya sistemine bir şey olduğunu kaydetmede başarısız olabileceği bazı son durumlar vardır, bu nedenle dosya sisteminde son yedeklemeden daha sonra bir değişiklik süresi olan dosyaları aramak için find kullanmanın son bir adımı vardır .

Bunun birkaç faydası vardır:

1. Bazı ortamların bozulmadığından emin olmak / kontrol etmek için AIDE'den sağlama toplamları / vb.
2. Inotify kaynak kullanımını düşük tutar ve dosya sistemini tekrar tekrar taramaya gerek yoktur
3. Rsync'i yamalamaya gerek yok; Yapabileceğim şeyleri düzeltmek zorunda kalırsam, ancak yükü daha düşük tutmak için şeyleri yamalamaktan kaçınmayı tercih edersem, (IE her güncelleme olduğunda yeniden yama yapmak zorunda değildir).
4. Daha önce Unison kullandım ve gerçekten güzel, ancak Unison'un dosya sisteminde kopyalar tuttuğunu ve "arşiv" dosyalarının oldukça büyük olabileceğine yemin edebilirdim?

Unison http://www.cis.upenn.edu/~bcpierce/unison/ hamle ve yeniden adlandırma tespit edebildiğini iddia ediyor.

Taşıma / yeniden adlandırma algılama eklemek için rsync için birkaç düzeltme eki vardır:

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

Bu sorunu izleyen Bugzilla girişi: https://bugzilla.samba.org/show_bug.cgi?id=2294

Bu biraz garip bir çözüm, ancak ... git dosya içeriğine göre hareketleri ve yeniden adlarını algılar, bu nedenle söz konusu dizinleri sürüm kontrolü altında tutarsanız, git hareketleri algılayabilir ve aktarmayı önleyebilir içerik (zaten telin her iki tarafında olduğu için) ağaçta hareket ederken.

Sadece bir düşünce.

ilginç öneriler burada. Ayrıca ZFS gibi dosya sistemi özelliklerini kullanmayı düşündüm. Bu basit şeyi yapan bir araç olmadığını garip buldum. Unison seçeneği çoğu durumda insanların bana bildirdiği gibi çalışmaz.

Bu özelliğin klasörleri yeniden düzenlerken ikinci sabit diskteki film koleksiyonumu senkronize halde tutmasını istiyorum.

Şimdi bu basit C betiğini buldum http://sourceforge.net/projects/movesync/

İyi çalışıyor gibi görünüyor. Çalıştırın ve sonra normalde yani bizonla senkronize edin.

AIDE gibi ana bilgisayar tabanlı bir IDS kullanabilir ve çıktısını kullanarak bir sarıcı komut dosyası yazabilirsiniz. Sağlama toplamlarını göz önünde bulundurarak muhtemelen daha karmaşık bir mantık yazmanız gerekir.

Aksi takdirde, değişiklikler tüm konumlara yansıtılacağı için ağ tabanlı bir dosya sistemi mantıklı olabilir. Yine de, İnternet üzerinden transfer yaptığınızdan şüpheleniyorum, bu da burada seçenekleri sınırlandıracak.

Birlik deneyebilirsiniz ; özellikle de

-xferbycopying yerel kopyaları kullanarak aktarımları en iyi duruma getirir (varsayılan true)

seçenek belirtilen dokümanlar olarak

Bu tercih ayarlandığında Unison, gerekli içeriklere sahip bir dosyanın hedef eşlemede zaten var olduğunu fark ederek ağ üzerinden dosya içeriklerinin aktarılmasını önlemeye çalışır. Bu genellikle dosya hareketlerinin çok hızlı bir şekilde yayılmasını sağlar. Varsayılan değer true.

istediğini yapabilir gibi görünüyor.

Syrep ihtiyacınız olanı yapar. Bir dosya ağacındaki mesaj özetlerini güncel tutar; özetleri tutmak, rsync'den daha verimli hale getirir. Sneakernet için tasarlandığından, bir kerede güncelleme / makepatch / birleştirme yapan bir sarıcı eklemek isteyebilirsiniz.

Bunu sizin için yapan mevcut bir araç olup olmadığından emin değilim, ancak sadece son yedeklemeden daha yeni findolan temel dizinde çalışan basit bir komut dosyası yazabilirsiniz mtime. Bu size değiştirilmiş tüm dosyaların bir listesini verecektir . Bir dosya basitçe taşındıysa, listede görünmez. Maalesef bu liste, dosya eklendiğinde / kaldırıldığında dizin güncelleneceğinden dosyaların taşındığı dizinleri içerecektir.

Bu dosya listesiyle, yalnızca bu dosyaları senkronize etmek için rsync kullanabilirsiniz. rsync'in bir dosya listesinde okuma seçeneği vardır. İşte bu örneği gösteren bir test:

$ 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

Her findkomutu çalıştırmak arasında yaklaşık 1 dakika beklediğimi lütfen unutmayın . Bundan, dosyayı ilk oluştururken tarafından listelendiğini gösterir find. Dosyayı başka bir dizine taşır ve findkomutu yeniden çalıştırırsam , dosyanın kendisini değil, yalnızca dosyayı taşıdığım dizini görüntüler. Sadece istediğiniz dosyaları listelemek için findve rsynckomutlarının bir kombinasyonunu kullanabilirsiniz , muhtemelen hedefinize ulaşabilir.

Umarım bu yardımcı olur.

İş akışınız göz önüne alındığında, dosya düzeyinde çalışmanın (başkalarının şimdiye kadar önerdiği gibi) en iyi çözüm olup olmadığını merak ediyorum. Çalışabilirsin ...

Dosya sistemi düzeyinde

Fikir, dosya sisteminin yedeklemeler arasındaki işlemleri izlemesini sağlamaktır. Dosya sisteminin yedeğini almak yerine, dosya sistemi günlüğünü yedekleyin (ve kullanıma hazır bir yedekleme istiyorsanız, isteğe bağlı olarak yedekleme makinesindeki değişiklikleri yeniden oynatın). Bir dosya sistemi günlüğü doğal olarak birkaç bayttaki hamleleri ve silmeleri ifade eder.

Fuse , “gerçek dosya sisteminin” üstünde yer alan özel gereksinimlere sahip bir dosya sistemi tasarlamayı nispeten kolaylaştırır. Hiç kullanmadım, ancak LoggedFS umut verici görünüyor.

Bu çözümle, bir tür dergi sıkıştırmasına sahip olmak faydalı olacaktır. Örneğin, bir dosyanın üzerine 10 kez yazıldıysa, yalnızca son güncellemesini günlükte tutun. Bir başka değerli optimizasyon, kopyalama işlemlerini ve daha da iyisi düzenlemeleri tanımaktır (yani, çoğunlukla ancak tamamen başka bir dosyayla aynı olmayan bir dosya oluşturmak). Kimsenin bunu uygulayıp uygulamadığını bilmiyorum. İş akışınız için bunun çok önemli olacağını düşünmüyorum.

Ses seviyesinde

Fikir, birim yöneticisinin yedeklemeler arasındaki işlemleri izlemesini sağlamaktır. Dosya sisteminin yedeğini almak yerine, birim yöneticisiyle bir anlık görüntü alın ve önceki anlık görüntüden farklı olarak ifade edilen anlık görüntüyü yedekleyin .

Yaptığınız tek şey dosyaları oluşturmak, yeniden adlandırmak ve kaldırmaksa bu iyi çalışmalıdır. Kopyalar ve düzenlemeler gibi şeyleri tespit etmek veya bir dosyanın oluşturulmasını ve ardından silinmesini optimize etmek çok daha zor olurdu.

Unison bunun için iyidir, ancak yine de dosyaları yerel olarak kopyalamak gerekir ve dosya içeriği biraz değiştiğinde bir taşıma / yeniden adlandırma algılayamaz.

Yeniden adlandırılan / taşınan dosyaları ve dizinleri inode numaralarını (yalnızca * nix) kullanarak algılamak ve senkronize makinede bu değişiklikleri tekrarlamak için basit bir Python betiği yaptım. Tek başına veya Unison veya rsync için "yeniden adlandırma önişlemcisi" olarak kullanabilirsiniz. Bu bulunabilir burada