Ben sadece bir 49GB dizini kötü bir dosya yoluna "mv" edindim, dosyaların orijinal durumunu geri yüklemek mümkün mü?

Ben (iyi, ben vardı bir dizin):

/media/admin/my_data

Yaklaşık olarak 49GB boyutundaydı ve içinde on binlerce dosya vardı. Dizin, etkin bir LUKS bölümünün bağlama noktasıdır.

Dizini yeniden adlandırmak istedim:

/media/admin/my_data_on_60GB_partition

O zamanlar farkında değildim, fakat emri ev dizininden verdim, böylece bittim:

~% sudo mv /media/admin/my_data my_data_on_60GB_partition

Böylece mvprogram /media/admin/my_datayeni bir dizine taşınmaya başladı ~/my_data_on_60GB_partition.

Komut kısmını iptal etmek için Ctrl+ tuşlarını kullandım C, bu yüzden şimdi dizinlere ayrılmış bir sürü dosyam var:

~/my_data_on_60GB_partition    <---  about 2GB worth files in here

/media/admin/my_data           <---- about 47GB of orig files in here

Yeni dizin ~/my_data_on_60GB_partitionve bazı alt dizinleri root'a aittir. Programın başlangıçta dosyaları kök olarak kopyalamış olması gerektiğini ve aktarımın ardından kullanıcı hesabıma geri döndüğünü
farz ediyorum . mvchown

Dizin / bölümün biraz eski bir yedeğim var.
Sorum şu ki, taşınan dosyaların bir demetini güvenilir bir şekilde geri yüklemek mümkün mü?

Yani, sadece koşabilir miyim:

sudo mv ~/my_data_on_60GB_partition/*  /media/admin/my_data

veya dosyalar muhtemelen bozuk ve kısmen tamamlanmış olduğu için kurtarmaya çalışmaktan vazgeçmeli miyim?

İşletim Sistemi - Ubuntu 16.04

mv --version  
mv (GNU coreutils) 8.25

files data-recovery mv administration

— the_velour_fog
kaynak

Panik yaparken alışkanlık haline Control-Zgelmek yerine (duraklatmak) yazın Control-C. Bu durumda, o anda hangi dosyanın aktarıldığını görebilecek ve böylece hangi dosyanın yalnızca kısmen kopyalandığını bileceksiniz. Daha sonra nasıl devam edeceğinize sakin bir şekilde karar verebilirsiniz. ( kill -stopTty'de olmayan işlemler için kullanın ).

— meuh

2 GB + 47 GB = 60 GB ???

— tbodt

@tbodt (2GB + 47GB) < 60GB. bölüm kapasitesi 60GB, klasör boyutu ve içeriği: 49GB.

— the_velour_fog

Yanıtlar:

Dosyaları dosya sistemleri arasında taşırken, mvbir dosyayı kopyalamayı bitirmeden silmez ve dosyaları sırayla işler (İlk önce kopyaladığını ve ardından her dosyayı sırayla sildiğini söyledim, ancak bu garanti edilmedi - en azından GNU mvkopyaları daha sonra her komutu siler. sırayla argüman ve POSIX bu davranışı belirtir ). Öyleyse, hedef dizinde en fazla bir eksik dosya bulunmalıdır ve orijinali hala kaynak dizinde olacaktır.

Bir şeyleri geri taşımak için -ibayrağı ekleyin, böylece mvhiçbir şeyin üzerine yazmaz:

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

(geri yüklemek için hiçbir gizli dosyaya sahip olmadığınız varsayılarak ~/my_data_on_60GB_partition/) veya daha iyisi (keşfedildiği üzere silinmeyi bekleyen bir çok dosyaya sahip olabileceğiniz göz önüne alındığında) -nbayrağı ekleyin, böylece mvhiçbir şeyin üzerine yazmaz sana şunu sor:

sudo mv -n ~/my_data_on_60GB_partition/* /media/admin/my_data/

Ne -vyapıldığını görmek için bayrak da ekleyebilirsiniz .

Herhangi POSIX uyumlu sayesinde mv, orijinal dizin yapısı hala sağlam olmalı, bu nedenle alternatif çağrıya bakar mısın - ve sadece silme /media/admin/my_dataolsa genel durumunda (... sanırım mv -nvaryant güvenli bir yaklaşımdır - bu her türlü kolları mv, dahil örneğin mv /media/admin/my_data/* my_data_on_60GB_partition/ .)

Muhtemelen bazı izinleri geri yüklemeniz gerekecek; bunu yapabilir topluca kullanarak chownve chmodya kullanan yedeklerden geri yüklemek getfaclve setfacl(sayesinde Sato Katsura için hatırlatma ).

— Stephen Kitt
kaynak

Teşekkürler Stephen Kitt, bu çok büyük bir yardım! findİzinleri bulmak ve ayarlamak için kullanabilirim . Yeni dizinde, dosya adlarında boşluk olan ancak bildiğim gizli dosya bulunmayan çok sayıda dosya var. Komuttaki glob'un sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/sözcük bölme sorunları olmadan dosya adını genişleteceğini düşünüyor musunuz ? Alternatif olarak sudo rsync ~/my_data_on_60GB_partition/ /media/admin/my_data/, dosya yollarını boşluklarla idare edebileceğini düşündüğümü kullanabilir miyim?

— the_velour_fog

Sadece tarif edilen OP gibi şeyler olduğunda emin olmak için rsyncyerine kullanıyorum, böylece tüm dosyaların bütünlüğünü de kontrol ediyordu. Ama buna ihtiyacım olmadığını bilmek güzel.

— Hauleth,

@ the_velour_fog globbing dosya isimlerindeki boşlukları problemsiz işler.

— Stephen Kitt

Ben ediyorum su command mv -i ...(veya su /bin/mv -i ...), yerine sudo mv -i ...,) durumunda yok "mv" bir işlev "mv -f" yapılan bazı (garip) yönetici sistem düzeyinde (yani / etc / profile veya sistem çapında dosyaları) .. komut bir şey: komutu, aynı ismin bir fonksiyonunu veya diğer ismini değil bir şeyi başlatın. (örneğin: biri (çok!) şanssız olabilir ve function mv { /bin/mv -f -- "$@" }her zaman kaynaklanmış bir dosyada (çok, çok kötü!) olabilir ve sonra "rm -i" bir şey sormaz (ve sadece bunu protesto eder) -i "dosya mevcut değil!) ... [Böyle şeyler görüyorum ... titreme ]

— Olivier Dulac

@OlivierDulac - takma adları veya komut dosyalarını standart programlarla aynı adlarla kullanmanın neden kötü bir uygulama olduğuna mükemmel bir örnek.

— Joe,

Stephen Kitt'in cevabını aldıktan ve bu komutu potansiyel bir çözüm olarak tartıştıktan sonra:

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

Neler olup bittiğini kafamı dolana kadar sürdürmeye karar verdim, bu cevap neyi bulduğumu ve ne yaptığımı açıklıyor.

mvDosyaları hedefe kopyalayan Gnu kullanıyorum , ancak yalnızca kopyalama işlemi başarılı olursa orijinali siler.
Bununla birlikte, mvbu diziyi bir defada bir dosya gerçekleştirip gerçekleştirmediğini doğrulamak istedim, bu doğruysa, orijinal klasör içerikleri temiz bir şekilde iki bölüme dilimlenir, bir bölüm hedefe kaydırılır, diğeri hala kaynakta kalır. Muhtemelen, iki dizin arasında ortak olacak olan kopya sırasında kesilen bir dosyaya sahip olacaktı - ve muhtemelen yanlış biçimlendirilmiş olacaktı.

İki dizin arasında ortak olan dosyaları keşfetmek için koştum:

~% sudo diff -r --report-identical-files my_data_on_60GB_partition/. /media/admin/mydata/. | grep identical | wc -l
14237

Bu sonuç, hem kaynak hem de hedef dizinlerde aynı dosyaların 14.237 örneği olduğunu gösterdi, dosyaları manuel olarak kontrol ederek onayladım - evet, her iki dizinde de aynı dosyaların çoğu vardı. Bu, yalnızca mvdosyaların büyük kopyalarını kopyaladıktan sonra kaynak dosyaların silinmesini gerçekleştirdiğini gösterir. Bir hızlı arama infoüzerine mvkomuta gösterdi

[ mv] Önce cp -aistenen dizinleri ve dosyaları kopyalamak için kullanılan kodun bazılarını kullanır , sonra (kopyalamanın başarılı olduğunu varsayarak) orijinalleri kaldırır. Kopyalama başarısız olursa, hedef bölüme kopyalanan kısım kaldırılır.

Emri çalıştırmadım ama kaçmaya çalıştığımdan şüpheleniyorum.

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

Üzerine -i yazmadan önce sorulması muhtemelen 14.000'den fazla kez tetiklerdi.

Böylece, yeni oluşturulan dizinde kaç tane toplam dosya olduğunu bulmak için:

~% sudo find my_data_on_60GB_partition/ -type f -a -print | wc -l                                                                    
14238

Öyleyse, yeni dizinde toplam 14238 normal dosya varsa ve 14237 kaynağında aynı orijinallere sahipse, bu, yeni dizinde kaynağa karşılık gelen aynı dosyaya sahip olmayan tek bir dosya olduğu anlamına gelir. Bu dosyanın ne olduğunu bulmak için, kaynak yönünde geri döndüm:

~% sudo rsync -av --dry-run my_data_on_60GB_partition/ /media/admin/my_data
sending incremental file list
./
Education_learning_reference/
Education_learning_reference/Business_Education/
Education_learning_reference/Business_Education/Business_education_media_files/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/Jeff and David F interview/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/Jeff and David F interview/018 business plans-identifying main KPIs.flv

sent 494,548 bytes  received 1,881 bytes  330,952.67 bytes/sec
total size is 1,900,548,824  speedup is 3,828.44 (DRY RUN)

Hızlı bir kontrol, dosyanın hem kaynak hem de hedef üzerinde bulunduğu hatalı biçimlendirilmiş dosya olduğunu doğruladı, hedef dosya = 64 MB, orijinal = 100 MB. Bu dosya ve dizin hiyerarşisi hala root tarafından sahiplenildi ve henüz orijinal izinler geri yüklenmedi.

Yani özet olarak:

mvAsla erişilmeyen tüm dosyalar hala orijinal konumlarına geri döndü (açıkçası)
mvKopyalanan tüm dosyalar tamamen kaynak dizinde orijinal kopyalarına sahipti.
Sadece kısmen kopyalanan dosya hala kaynak dizinde orjinaline sahipti.

Başka bir deyişle, tüm orijinal dosyalar hala sağlam ve bu durumda çözüm basitçe yeni dizini silmek oldu!

— the_velour_fog
kaynak

Vay ... Cevabımı güncelledim -n, genel durumda daha iyi olurdu. mvKaynak kodunu kontrol ettim, her seferinde kaynak bir argümanı siler.

— Stephen Kitt

@StephenKitt ah güzel. mvKaynaktaki silme işleminin ne zaman yapıldığını merak ediyordum . Yani komuta mv foo bar bazhareket edeceğini fooiçin baz/foo daha sonra orijinal silin foosonra hareket baretmek baz/bar..?

— the_velour_fog

Evet bu doğru; aslında POSIX'in belirttiği şey budur (temel olarak, herhangi bir kaynak argümanı etkileyen herhangi bir hatanın kaynak kaynak hiyerarşisini sağlam bırakır).

— Stephen Kitt

Ayrıca bitmemiş bir dosyayı bulmak için diff'i kullanabileceğini düşünüyorum.

— StarWeaver

İkili dosyaları karşılaştırmak cmpyerine kullanmalısınız diff. Ayrıca, yukarıdaki tartışmanız yalnızca farklı dosya sistemlerindeki dosyaları taşırken anlamlıdır. Aynı dosya sistemindeki dosyaları taşırken hiçbir kopyalama yapılmamaktadır.

— Satō Katsura

Ben sadece bazı şeyleri paralel olarak çalıştırmak için 'xargs'i' karışıma atmaya teşvik edebileceğini düşündüm. Bu bana willies verir ve yukarıdaki rsync çözümü gerçekten seviyorum.

Dosya sistemi taşınma ve kopyalama ile ilgili olarak ve orijinali tam olarak silindiğinde, VFS ve altta yatan dosya sistemleri, bu silme adımına ulaşmadan önce dosya başına atomiteyi garantilemek üzere koordine eder. Bu nedenle, hedef dosya tam olarak yazılmadan önce kesintiye uğrasa bile, VFS'deki kilitlemenin tamamı gerçektir ve paralel durumlarda bile rastgele veri araya girme gibi şeylere karşı koruma sağlar. (Linux VFS ve NFS4 konusunda çalıştım)

Karışıma 'xargs' eklemek muhtemelen çift aklı kontrol kontrol basamağını bir baş ağrısına çevirdi, bu sayede transitte birden fazla dosya vardı. Keşke daha fazla sistem düzeyinde kod yazabilseydim. Benim için iyi hatırlatıcılar!

Bu soruyu çok sevdim, örümcek ağları için iyi ve tekrar rsync'i sevmemi sağlıyor. Şerefe!

— David Richter
kaynak

Dosya adları boşluk içerdiğinde sorundan bahsetmiyorum.

— Wildcard,