web-dev-qa-db-ja.com

49GBディレクトリを不正なファイルパスに「mv」したところ、ファイルの元の状態を復元できますか？

私は（まあ、私had）ディレクトリがあります：

/media/admin/my_data

サイズは約49GBで、何万ものファイルが含まれていました。ディレクトリは、アクティブなLUKSパーティションのマウントポイントです。

ディレクトリの名前を次のように変更したいと思いました。

/media/admin/my_data_on_60GB_partition

そのときは気づきませんでしたが、ホームディレクトリからコマンドを発行したため、次のようになりました。

~% Sudo mv /media/admin/my_data my_data_on_60GB_partition

そのため、mvプログラムは/media/admin/my_dataとその内容を新しいディレクトリ~/my_data_on_60GB_partitionに移動し始めました。

使った Ctrl + C コマンドを途中でキャンセルするため、ディレクトリ全体に分割された一連のファイル全体を取得します。

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

そして

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

新しいディレクトリ~/my_data_on_60GB_partitionとそのサブディレクトリの一部はルートによって所有されています。
私はmvプログラムが最初にrootとしてファイルをコピーし、次に転送後にファイルを自分のユーザーアカウントにchownして戻したと想定しています。

ディレクトリ/パーティションのやや古いバックアップがあります。
私の質問は移動された一連のファイルを確実に復元することは可能ですか？

つまり、単に実行できますか？

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

または、ファイルが破損している可能性があるため、回復を試みるのをやめるべきですか？

  • OS-Ubuntu 16.04
mv --version  
mv (GNU coreutils) 8.25
filesdata-recoverymvadministration
59
the_velour_fog

ファイルシステム間でファイルを移動する場合、mvはファイルのコピーが完了する前にファイルを削除せず、ファイルを順番に処理します（最初はファイルを順番にコピーしてから削除すると言っていましたが、保証はありません—少なくともGNU mvは次に各コマンドライン引数をコピーして削除し、 POSIXはこの動作を指定します ）です。ファイルはターゲットディレクトリにあり、元のファイルはソースディレクトリに残ります。

元に戻すには、-iフラグを追加して、mvが何も上書きしないようにします。

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

（~/my_data_on_60GB_partition/から復元する隠しファイルがない場合）、またはそれ以上（削除を待っているファイルが多数ある可能性がある場合）、-nフラグを追加しますしたがって、mvは何も上書きしませんが、それについて尋ねることはありません。

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

-vフラグを追加して、何が行われているかを確認することもできます。

POSIX準拠のmvを使用しても、元のディレクトリ構造はそのままであるはずなので、代わりにそれを確認し、/media/admin/my_data...を削除することもできます（ただし、一般的なケースでは、mv -nバリアント安全なアプローチです—egmv /media/admin/my_data/* my_data_on_60GB_partition/を含むmvのすべての形式を処理します。）

おそらくいくつかの権限を復元する必要があります。 chownとchmodを使用してen masseを実行するか、getfaclとsetfaclを使用してバックアップから復元することができます（ Sato Katsura のおかげで リマインダー ）。

88
Stephen Kitt

スティーブン・キットの答えを得て、このコマンドを潜在的な解決策として議論した後：

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

私は何が起こっているのか頭に浮かぶまでそれを実行することを控えることにしました、この答えは私が見つけて結局やったことを説明しています。

ファイルをターゲットにコピーするGnu mvを使用しています。コピー操作が成功した場合にのみ、元のファイルが削除されます。
しかし、mvがこのシーケンスを一度に1ファイルずつ実行するかどうかを確認したかったのですが、これが当てはまる場合、元のフォルダーの内容は2つの部分にきれいにスライスされ、1つは宛先にシフトされていました。 、もう1つはまだソースに残されています。また、コピー中に中断されたファイルが1つあり、2つのディレクトリ間で共通している可能性があり、形式が正しくない可能性があります。

2つのディレクトリ間で共通していたファイルを見つけるために、次のコマンドを実行しました。

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

この結果は、ソースディレクトリとターゲットディレクトリの両方に同じファイルのインスタンスが14,237あることを示唆しており、ファイルを手動で確認して確認しました-はい、両方のディレクトリに同じファイルが多数ありました。これは、mvが大量のファイルをコピーした後にのみ、ソースファイルの削除を実行することを示唆しています。 infoコマンドでのmvのクイックルックアップが示されました

[mv]は、最初にcp -aが使用するものと同じコードの一部を使用して、要求されたディレクトリとファイルをコピーし、次に（コピーが成功したと仮定して）元のファイルを削除します。コピーが失敗すると、宛先パーティションにコピーされた部分が削除されます。

コマンドは実行しませんでしたが、実行しようとしたのではないかと思います

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

-i上書き前のプロンプトは、14,000回以上トリガーした可能性があります。

したがって、新しく作成されたディレクトリにある合計ファイル数を調べるには、次のようにします。

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

したがって、新しいディレクトリに合計14238の通常ファイルがあり、14237がソースに同じオリジナルがあった場合、ソースに対応する同じファイルを持たないファイルが新しいディレクトリに1つしかなかったことを意味します。そのファイルが何であるかを調べるために、ソースの方向にrsyncを実行しました。

~% 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)

簡単なチェックにより、これが不正なファイルであることが確認されました。このファイルは、ソースと宛先の両方に存在し、宛先ファイル= 64 MB、元= 100 MBでした。このファイルとそのディレクトリ階層は依然としてrootが所有しており、元の権限はまだ復元されていませんでした。

要約すると：

  • mvに到達したことのないすべてのファイルは、まだ元の場所に戻っています（明らかに）
  • mvが完全にコピーしたすべてのファイルには、ソースディレクトリに元のコピーが残っています
  • 部分的にのみコピーされたファイルには、元のファイルがソースディレクトリに残っています。

つまり、元のファイルはすべてそのままで、この場合の解決策は、新しいディレクトリを削除することでした。

20
the_velour_fog

並行して実行するために「xargs」をミックスに投入したくなる人もいるとコメントしたいと思いました。それは私に意欲を与え、私は上記のrsyncソリューションが本当に好きです。

移動とコピーに関するファイルシステムに関するもの、および元のファイルが正確に削除された場合、VFSと基になるファイルシステムは、その削除手順に進む前にファイルごとのアトミック性を保証するために調整されます。そのため、ターゲットファイルが完全に書き込まれる前に中断された場合でも、VFSのロックはすべて厳密で、並列の場合でもランダムデータインターリーブなどから保護されます。 （私はLinux VFSとNFS4のものに取り組みました）

'xargs'をミックスに追加すると、おそらく複数のファイルが送信中のため、二重健全性チェックのステップが頭痛の種になったでしょう。もっとシステムレベルのスクリプトがあったらいいのに。良いリマインダー！

クモの巣に適した質問が大好きで、再びrsyncが好きになりました。乾杯！

4
david richter