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

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

私は(まあ、私は持っていた) ディレクトリ:

/media/admin/my_data

サイズは約 49 GB で、数万個のファイルが含まれています。このディレクトリは、アクティブな 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 が所有しています。プログラムは最初にファイルを root としてコピーし、その後転送して自分のユーザー アカウントに戻したに 違いない
と思います。mvchown

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

つまり、次のコマンドを実行すればよいのです:

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

または、ファイルが破損していたり​​部分的にしか完了していない可能性があるため、回復をあきらめるべきでしょうか?

  • OS - Ubuntu 16.04
mv --version  
mv (GNU coreutils) 8.25

答え1

ファイルシステム間でファイルを移動する場合、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佐藤桂のためにリマインダー)。

答え2

Stephen Kitt の回答を得て、このコマンドを潜在的な解決策として議論した後:

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

何が起こっているのか理解するまで実行を保留することにしました。この回答では、私が発見したことと最終的に行ったことについて説明します。

私はmvファイルをターゲットにコピーする Gnu を使用しています。その後、コピー操作が成功した場合にのみ、元のファイルが削除されます。
ただし、このシーケンスを一度に 1 つのファイルずつ実行するかどうかを確認したかったのですmvが、それが正しい場合、元のフォルダーの内容は 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 個あることが分かりました。手動でファイルをチェックして確認したところ、両方のディレクトリに同じファイルが多数ありました。これは、大量のファイルをコピーした後にのみ、ソースファイルの削除が実行されることを示しています。onコマンドでmv簡単に調べたところ、infomv

[ 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ソースディレクトリに元のコピーが残っています。
  • 部分的にしかコピーされなかったファイルは、ソースディレクトリに元のファイルが残っていました。

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

答え3

並列処理を実行するために「xargs」を混ぜてみたいという人もいるかもしれないとコメントしておきます。私にはそれが不安で、上記の rsync ソリューションが本当に気に入っています。

移動やコピー、そしてオリジナルがいつ削除されるかというファイルシステムについては、VFS と基盤となるファイルシステムが連携して、削除手順に進む前にファイルごとのアトミック性を保証します。そのため、ターゲット ファイルが完全に書き込まれる前に中断された場合でも、VFS のロックはすべて厳格に行われ、並列処理の場合でもランダム データのインターリーブなどの問題から保護されます。(私は Linux VFS と NFS4 に取り組んでいました)

'xargs' を追加すると、複数のファイルが転送中に二重の整合性チェック手順が面倒になったでしょう。システム レベルのスクリプトがもっとあればよかったと思います。私にとっては良いリマインダーです!

質問が気に入りました。クモの巣にはぴったりです。また rsync が好きになりました。乾杯!

関連情報