「rm -rf」を元に戻す最良の方法は何ですか？
はじめに
私は誤って恐ろしいことをしました。 lsの代わりにcdと入力すると、後でいくつかのコマンドが現在のディレクトリで_rm -rf_を数日前にこのディレクトリのコピーではなくmntに表示されましたが、私が書いたスクリプトが私が書いたスクリプトの後に期待された。
ここではすでにこのような質問があることは承知していますが、包括的な質問はありません。 「機会」を利用して、将来他の人の参照として使用できる公開投稿シリーズの回答を開始したいと思います。
たとえば、photorecとtestdiskの使用に関する提案があります。これらは最善の解決策ではない可能性があります。 locateの使用を提案する別の回答 here を見つけました。私はこれについて、またはそれがどのように機能するかについて何も知りません。
私のシステム
私のシステムは、Testingブランチを追跡するDebian 10システムです。データはSSDにあり、ext4としてフォーマットされました。間違った場所で_rm -rf_を実行したことに気付いたらすぐに、コンピューターの電源ボタンを押し続けて電源をオフにしました。
解決へのステップ
別のDebianシステムを実行している別のラップトップを持っています。 SSDをコンピューターから取り出し、外部USBからSataインターフェイスに差し込みました。
これを、システムがデバイスにデータを書き込めない方法でマウントする必要があると思います。どうすればよいですか？
次に、このlocateメソッド（リンクされた質問）を使用してデータを取得できますか？これを実行する前に、それが正しいことであることを確認したいと思います。
データは重要ですか？
はい-削除したディレクトリには、博士号のすべてのコードが含まれています。あと2週間残っています。私は使用できる古いバージョンを持っていますが、ここ数週間かそこらの間に行ったすべてを再実装します。しかし、その短い期間に私は多くのものを変えました。今週の研究で「ブレイクスルー」を作りました。コードの記述方法は、これを再実装することは決して簡単ではないことを意味します。
バックアップはありましたか？ （編集）
私が確実に知っているのは、日付が_2 May 2020_のサーバー上だけです。それ以来、私は24時間体制でかなりの作業を行っているため、膨大な量の作業を行っています。
このSSDには他にもmightバックアップがある可能性がありますが、それらの一部は私のホームディレクトリにあります-したがって、これらは_rm -rf_バックアップスクリプトが期待どおりに機能しなかったため、通常のバックアップが存在しない可能性があります。 （コピーされていた奇妙なものを削除しようとすると、私はこのように混乱しました。）
現在、SSDにアクセスして日付を確認することができません。可能であれば、データを書き込めないようにマウントする方法を知る必要があります。
5月2日のものしかなければ、それは本当に非常に悪いことです。私は最近、これについてクレイジーな時間を費やしてきました。それがおそらく、今朝目が覚めてそれを誤って発射した理由です。
考慮すべき点がいくつかあります。
まずディスク全体をコピーします：
dd if=/dev/sdX of=image.img bs=1M status=progress
ディスク自体ではなく、このコピー（たとえば、photorec image.img）で作業します。私の（長い）経験では、
foremostは多くのファイルタイプでphotorecよりも優れています。カスタムファイルヘッダーをforemostに追加することを検討する必要があるファイルタイプによっては、これは過去に私にとって非常に効果的でした。私の答えの最前線/ photorecの詳細 こここれ 私の答えは、回復した干し草の山から使用可能なファイルを見つけるのに役立つかもしれません。
SSDをマウントしないでください。コメントですでに述べたように、readonlyをマウントしても、上書きを防ぐのに必ずしも十分ではない場合があります。
dd画像で作業します。
さて、ここで私がしばらく前に学んだ（感動的な）トリックを紹介します。
私が削除したディレクトリには、私の博士号のすべてのコードが含まれています
つまり、テキストです。コードの大部分が1つ（またはいくつか）のファイルにある場合、実際にこれを試すことができます。
grep -ai '<this text is in my newest code revision>' image.img
簡単そうに聞こえるかもしれませんが、同じ状況で以前は助かりました。コマンドに-C xを追加して、一致した行の上下にx（数字で置き換える）行を含めることができます。
ファイルが部分的に破損している可能性があることに注意してください。多くのパターンを試してください。多くの単語から始めて、完全に一致するものを見つけてください。結果がない場合は、より少ない単語を試してください。
そして義務...常にバックアップを作成します。同じドライブ上ではありません。バックアップを確認します。あなたはテキストを扱っていますが、これは数百ギガバイトではないので、クラウドバックアップ（もちろん暗号化されている）などをセットアップすることもできます。
もう1つのアドバイス：コードを書き直すのに必要な時間よりも、これに慌てる必要はありません。落ち着いて、できることを試して、私のgrepメソッドが役立つかどうかを確認します。1日たっても何も起こらない場合は、おそらく最新のバックアップを取得して、そこから再び作業することをお勧めします。
答えの始まり
photorecユーティリティスイートのtestdiskを使用して、一部のデータを回復しました。
私が試したことのリスト
- Debian 10ラップトップ（別のマシン）を起動します。
- USB経由でSSDをSATAコントローラーに挿入します（悪いアイデア！）
- 自動的にマウントされたディスク（これを防ぐ方法がわからない）
- バックアップを作成するためにddを使用してデータのコピーを開始しました
- スペース不足
- キャンセルされたddジョブ
- 最初にデータをddコピーするのは良い考えかもしれませんが、それを行う方法がわかりません
- 私が抱えている問題：ディスクのサイズが1 TBであり、
photorecで調べる前に、その1 TBのすべてをコピーする必要があります（おそらく？ゼロのブロックは無視できますか？）。 - 内蔵SSD（ラップトップ）はわずか500 GB
- 付属の外付け4TBドライブ
- マウント解除された1TB SSD（私が回復しようとしているもの）
- DDを気にしませんでした
- ロード済み
photorec - ここでの手順： https://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step
- 私が違ったことをした唯一のことは、検索するファイルの種類を変更し、それらをすべてオフにして、
.tx?および.txt関連オプション（.cソースファイルなどを含む）
データの処理
- Photorecは何百もの出力フォルダと何千ものファイルを生成しました
- ファイル名やディレクトリ名の命名規則がわかりません
- ファイル名はすべてごちゃまぜにされた
- 中古
grep -rIwサブフォルダー内の完全に一致するWord文字列全体を検索するには - 関係のない行を削除するために、bashスクリプトを使用して出力を処理しましたか
- 結果の一致を比較するために
diffを使用しました - ソースファイルのいずれかの最新バージョンを見つけた
- あといくつかあります...
概要
これが「受け入れられる答え」であるかどうかはわかりませんが、上記の方法でファイルを取得しました。
これは特に良い方法ではありませんが、機能します。
失われたデータが画像である場合は、物事をフリックしたり、サムネイルを表示して適切なファイルを見つけたりする方がはるかに簡単です。
システムが生成するテキストファイルやログなどにより、システムが多くの誤検知を作成するため、テキストファイルの処理はより困難です。
電源オフで十分高速だった場合は、パーティションの完全なバイナリバックアップの後に、 extundelete を試してみることができます。
私が正しく覚えている場合、extundeleteはパーティション上のジャーナルを利用して、rm -rfによって引き起こされたディレクトリファイルの変更を「元に戻す」。