間違ったファイルパスに49GBのディレクトリを「mv」しただけですが、ファイルの元の状態を復元することは可能ですか？

私はディレクトリを持っています（まあ、持っていました）：

/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とそのサブディレクトリの一部は、rootが所有しています。
私は、mvプログラムが最初にルートとしてファイルをコピーしてから、転送後にファイルをchownユーザーアカウントにコピーし直さなければならないと想定しています。

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

つまり、ただ実行できますか？

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

または、ファイルが破損しており、部分的に完了しているなどの可能性があるため、回復を試みるのをあきらめる必要がありますか？

• OS-Ubuntu 16.04

mv --version  
mv (GNU coreutils) 8.25

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

物事を戻すには、-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バリアントは安全なアプローチだと思いますmv。含むなど mv /media/admin/my_data/* my_data_on_60GB_partition/。）

おそらくいくつかのアクセス許可を復元する必要があります。あなたはそれを行うことができます大挙使用chownしてchmod、または使用してバックアップから復元getfaclし、setfacl（のおかげで佐藤桂用リマインダー）。

Stephen Kittの回答を得て、このコマンドを潜在的なソリューションとして議論した後：

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

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

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

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)

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

要約すると：

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

言い換えれば、元のファイルはすべてそのままであり、この場合の解決策は、新しいディレクトリを削除するだけでした！

一部の人々は、「xargs」をミックスに投げ入れて、物事を並行して実行したいと思うかもしれないとコメントしたいと思いました。それは私にウィリーを与え、私は上記のrsyncソリューションが本当に好きです。

移動とコピーに関するファイルシステムの内容、および元のファイルが正確に削除される場合、VFSとその下にあるファイルシステムは、削除ステップに進む前にファイルごとの原子性を保証するよう調整します。そのため、ターゲットファイルが完全に書き込まれる前に中断された場合でも、VFSのロックはすべて厳密に行われ、並列の場合でもランダムデータインターリービングなどを防ぎます。（Linux VFSとNFS4の仕事をしました）

ミックスに「xargs」を追加すると、おそらく途中で複数のファイルが発生するため、二重健全性チェックのステップが頭痛の種になります。もっとシステムレベルのスクリプトがあればいいのに。私に良いリマインダー！

クモの巣に良い質問を愛し、私は再びrsyncが好きになります。乾杯！