Linuxで失われたデータと削除されたデータを回復する

投稿日: 2022-10-17 2022-10-17
タグ: Files, Filesystems

1. 序章

ハードウェアを修正または交換し、ソフトウェアを購入または再インストールできます。ただし、デバイスをユニークで価値のあるものにしているのは、そのデータです。それを失うことは、苦痛または悪夢である可能性があります。つまり、準備ができているかどうかにかかっています。

このチュートリアルでは、偶発的な情報の損失に対処する方法を発見します。まず、ストレージ、パーティション、ファイルシステム、およびファイルに関する知識を更新します。次に、ストレージとパーティションの損傷によるデータの損失と、そのような場合の対処方法について説明します。その後、破損したファイルシステム、その分析、およびリカバリに焦点を当てます。次に、ファイルが失われた方法と条件に応じて、ファイルの復元について説明します。最後に、完全なストレージ診断とリカバリのためのいくつかの組み合わせツールセットを提案します。

このチュートリアルのコードは、GNU Bash5.1.4を使用したDebian11（Bullseye）でテストしました。これはPOSIXに準拠しており、そのような環境で機能するはずです。

2. ストレージ、パーティション、ファイルシステム、ファイル、およびiノード

物理ストレージにはさまざまな形式があります。重要なのは、それらすべてに何らかのコントローラーがあることです。特に、コントローラーの役割は、以下を整理して最適化することです。

入力と出力（誰がいつ）
読み取りと書き込み（何とどこで）

オペレーティングシステム（OS）は、ファイルシステムを介してストレージ上のデータを注文します。 OSがそれをどのように行うかは、そのタイプによって異なります。

ネイティブLinuxファイルシステムは、 iノードを使用して、オブジェクトに関する情報を格納およびインデックス付けします。 iノードを持つそのようなオブジェクトはすべてファイルです。

たとえば、ディレクトリファイルと通常のファイルを作成できます。 Linuxのディレクトリは、iノード関係に対するファイル名のリストです。一方、通常のファイルは、ファイル情報を含むiノードにリンクします。

iノード番号
権限
ファイルの日付
コンテンツブロックポインタ
その他のメタデータ

実際のファイルデータはコンテンツブロックにあることに注意してください（セクターに似ていますが、論理的です）。ただし、iノードにポインタがないと、それらがどこにあるかはわかりません。さらに、実際のiノードはインデックステーブルにあります。

さらに、ファイルシステムはほとんどの場合、表で記述された個別のパーティションです。次に、それらを作成してフォーマットすることができます。

これらの関係を知ることは非常に重要です。 データを回復するには、データの種類、保存方法、および失われた方法を知る必要があります。それでは、トップレベルから始めましょう。

3. ストレージまたはパーティションの損失

データを失う1つの方法は、ハードウェア障害です。これは、不良ブロック、破損したコントローラー、または別の不良コンポーネントが原因である可能性があります。もちろん、そのような場合、データは失われるか、簡単に失われる可能性があります。 メディアに障害が発生すると、そのメディアに情報を保存することは危険または不可能になります。

ストレージデバイスでは、パーティションは次のとおりです。

表に記載
ヘッダーで識別
与えられたフォーマットで

特に、ヘッダーまたはパーティションテーブルが破損すると、パーティションが失われる可能性があります。これは、たとえば、悪意のある攻撃者、不正なソフトウェア、ハードウェアの問題、または間違いが原因で発生する可能性があります。

そのような問題を診断して元に戻すために何ができるか見てみましょう。

4. パーティションとストレージを分析する

ストレージ全般を扱う場合、有名な e2fsprogs （Ext2 / 3/4ファイルシステムプログラム）パッケージに目を向けることができます。

特に、 badblocksツールは、デバイス上の不良ブロックを見つけるのに便利です。実際、これらは通常、ストレージの損傷に関する最初の証拠です。

$ umount /dev/sda
$ badblocks -v -sn /dev/sda
Checking for bad blocks in non-destructive read-write mode
From block 1 to 26510666
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: 1.05% done, 4:34 elapsed. (55/0/0 errors)
[...]

ここでは、 -v （冗長）、 -s （進行状況を表示）、および -n （非破壊的な読み取り/書き込み）フラグを使用します。スキャンする前に、最初にパーティションをアンマウントする方法に注意してください。 通常、ターゲットから起動していないときに診断するのが最適です。

または、SMARTを使用することもできます（自己監視、分析、およびレポート技術）最新のストレージデバイス。たとえば、 smartmontools （SMART Monitor Tools）があります。

$ smartctl -l selftest /dev/sda
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.14.0-kali4-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      6660         -

デバイスのステータスを確認した後、 fdisk（Fixed Disk）とその –list （ -l ）フラグを介してパーティションテーブルを確認することもできます。

$ fdisk --list
Disk /dev/sda: 101 GiB, 108587687936 bytes, 212085328 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xc0666084

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1  *         2048 210088528 210086480  100G 83 Linux
/dev/sda2       210090576 212087376   1996800  975M 82 Linux swap / Solaris

レイアウトがまだ読み取り可能かどうかを知る必要があります。紛失（空白）または単に故障している可能性があります。

被害を分析した後、問題を解決するために何ができるか見てみましょう。

5. ストレージレスキュー

物理的なデバイスの修理は、この記事の範囲外です。障害のあるストレージを交換する以外に、直接できることはほとんどありません。ただし、メディアがまだ部分的に読み取り可能である場合は、メディアからデータを復元できる可能性があります。

もちろん、デバイスの完全バックアップを作成するのが、すべてを復元する最も簡単な方法です。それを除けば、対処する他の手段を見つける必要があります。

たとえば、 GNU ddrescue（Disc Dump Rescue）ツールは、問題のあるメディアの生の画像をブロックごとにダンプできます：

$ ddrescue --idirect --retry-passes=3 /dev/sda dump.img dump.logfile
GNU ddrescue 1.23
Press Ctrl-C to interrupt
     ipos:    1597 MB, non-trimmed:        0 B,  current rate:  47972 kB/s
     opos:    1597 MB, non-scraped:        0 B,  average rate:    228 MB/s
non-tried:  273280 MB,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:    1597 MB,   bad areas:        0,        run time:          6s
pct rescued:    0.58%, read errors:        0,  remaining time:         19m
                              time since last successful read:         n/a
Copying non-tried blocks... Pass 1 (forwards)

–idirect （ -d ）を使用して、カーネルキャッシュをスキップします。さらに、 –retry-passes （ -r ）フラグは、不良セクターでの再試行回数を設定します。ただし、このオプションは、障害のあるデバイスにさらにストレスがかかるのを避けるために、2回目のパスに残しておくのが最適な場合があります。重要なのは、 ddrescueが特別なアルゴリズムを使用して、メディアの摩耗をできるだけ少なくすることです。

ここでも、 / dev / sda をマウントしないでください。また、dump.imgを別のデバイスにインストールする必要があります。この後、このイメージファイルを新しいメディアに復元します。

$ ddrescue -f dump.img /dev/sda restore.logfile

同様の機能を持つ別のツールは、safecopyです。

デバイスの完全なレスキューを確認したので、1つ下のレベルに進みましょう。

6. パーティションを回復する

パーティションテーブルは通常、ストレージをトップレベルで編成します。いつものように、現在は機能していないパーティションテーブルのバックアップがある場合、スクリプトバージョンのfdisk、つまりsfdisk を介して復元することができ、おそらく復元する必要があります。

$ sfdisk -d /dev/sda > parttable
$ sfdisk /dev/sda < parttable

最初のコマンドはテーブルをparttableにダンプしますが、2番目のコマンドはそのファイルからテーブルを復元します。

ただし、ほとんどの場合、バックアップがない場合でも、希望はあります。 インタラクティブテストディスクツールは失われたテーブルをスキャンできます：

$ testdisk
[...]
TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <[email protected]>
https://www.cgsecurity.org

Disk /dev/sda - 107 GB / 100 GiB - CHS 13054 255 63
Analyse cylinder  5127/13054: 39%


  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux Swap             538 123 34   799 144 41    4194296
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  
Stop
[...]

ここで、 testdisk は、古いテーブルとそれらからのエントリを検出しました。この後、これらのいずれかをセットアップに適用することもできます。さらに、MBRを書き換えるオプションがあります。

パーティションは、メディア内の孤立した「部屋」です。ただし、破損していない限り、識別できる形式になっていることがよくあります。

7. ファイルシステムの破損とファイルの問題

ファイルシステムは基本的にデータの形式であるため、順序付けられたメタデータを使用します。それをいじると問題が発生する可能性があります。

無効なファイル、つまり、失われたiノードへのハードリンク
アクセスできない有効なファイル、つまり、既存のiノードへのハードリンクがない
システムを起動できません
ファイルシステムのマウントまたは認識が不可能
その他の予期しない動作

実際、どのような問題が発生するかは、ファイルシステムの種類、その構造、および失われるものに大きく依存します。

たとえば、iノード内のポインタは、ファイルの内容など、ほとんどの場合データと呼ばれるものを指します。 iノードを紛失または損傷すると、コンテンツブロックポインタが無効になり、ファイルがシェルファイル名としてのみ残る可能性があります。それらには完全なメタデータが含まれますが、コンテンツは含まれません。

一方、ブロック内のデータ損失は永続的である可能性がありますが、それがどのように発生するかは重要です。 失われたデータが見つかるかどうかは、次のような多くの要因によって異なります。

情報がどのように失われたか
データまたはそれを指すメタデータを失ったかどうか
データを指すメタデータがまだあるかどうか
ストレージタイプ
損失以降のデバイスの使用
ファイルシステムの状態

最後のポイントに集中しましょう。

8. ファイルシステムの分析と回復

もちろん、ファイルシステムをチェックする標準的な方法は、fsck（ファイルシステム整合性チェック）ツールです。

$ fsck /dev/sda1
fsck from util-linux 2.37.2
e2fsck 1.46.4 (18-Aug-2021)
/dev/sda1: clean, 11/6553600 files, 557848/26510666 blocks

ストレージデバイス全体/dev / sda ではなく、パーティション / dev /sda1を指定していることに注意してください。 / dev / sda を使用したとしても、fsckはファイルシステムを1つずつ通過するだけです。

testdiskと同じように、fsckはスキャンとリカバリの両方を組み合わせています。後者を回避するために、 -n を追加して、変更を防ぐことができます。 Linuxには同様の機能を持つツールがありますが、たとえば ext4magic 、fsckはどこにでもあります。

したがって、ストレージが正常で、パーティションテーブル（正しい）とファイルシステム（ファイルシステム）が損なわれていない場合は、ファイルが欠落している可能性があります。それはどこに行きましたか、そしてどうやってそれを取り戻すのですか？

9. データとファイルの検出と回復

まず、重要なデータを常にバックアップします。

次に、データ損失後のメディア使用量を最小限に抑えます。これには、手動アクティビティと、最適化、スキャン、 cronjobs 、OSプロセスなどの自動タスクが含まれます。

私たちは常に欠けているものを確立する必要があります。単一の通常のファイル、1つのファイルの一部、多数の個別のファイル、またはディレクトリ全体のいずれであっても。次に、ログをチェックしてスキャンし、それがどのように失われたかを調べたり推測したりします。

実際、スキャンは最も正確または最も一般的な方法です。したがって、そのタイプによって異なります。

9.1. 失われた+見つかった

通常、オブジェクトへのすべてのハードリンクが削除されると、そのiノードは無効になります。ただし、これが発生しない場合、 lost + foundディレクトリには、まだ有効であるがアクセスできないiノードを指すプレースホルダーファイルが含まれている可能性があります。

これを行うには、事前に fsck を実行して、「斬首された」iノードを見つける必要があります。

9.2. データ認識

一方、iノードを失うと、ファイルの内容がどこにあるかがわからなくなる可能性があるため、より大きな問題が発生する可能性があります。 スキャンにより、フォーマットに基づいてファイルを部分的または完全に復元できる場合があります。

ただし、多くの注意点があります。たとえば、断片化、つまりファイルブロックがどの程度分散しているかが重要な役割を果たします。これは、フラグメントがiノード内の情報によってリンクされているためです。さらに、それはソフトウェアによって、識別できるフォーマットの数とフォーマットによって異なります。

たとえば、 photorecツールは、その名前にもかかわらず、480を超える拡張機能を認識します。便利なことに、これは testdisk パッケージの一部であるため、同様のインタラクティブなコマンドラインインターフェイスを備えています。

あるいは、空軍特別調査局による最前線ツールがあります。ただし、photorecほど積極的に保守されているツールは多くありません。

9.3. 破損したファイル情報

実際、ファイルの一貫性に影響を与える要因の組み合わせがある可能性があります：

不良ストレージブロック、ファイルのハードリンク、コンテンツ、またはiノードに影響を与える
ファイルシステムの問題、iノードの欠落、部分的、または置換につながる
偶発的なファイルの損傷、削除、または上書き

次に、話し合ったすべてのことを使用して、問題を1つずつ処理する必要があります。これを簡単にするために、無料のパッケージを利用できます。

実際、それらには、私たちが調査した標準ツールだけでなく、特定のケースのための他のツールも含まれていることがよくあります。

10. 起動可能なツールセット

すでに述べたように、問題のあるストレージではアクティビティを最小限に抑えるのが最善です。このため、通常、問題のあるメディアのクローンを作成し、そのクローンを使用します。不可能な場合は、少なくともマウントを解除する必要があります。

ただし、OSは作業しようとしているのと同じデバイスから実行されていることが多いため、環境内でツールを使用することはできません。そのために、パッケージ化されたイメージがあります。これには、起動可能な環境にプリインストールされたレスキューツールセットが含まれています。

Trinity Rescue Kit 、主にWindowsリカバリを対象としたLinux環境
Hiren’s Boot CD 、多くのツールを備えたユニバーサルWindowsポータブル環境
アルティメットブートCD
System Rescue 、Linuxシステムレスキューツールキット

これらの使用は、イメージを取得してメディアに書き込み、そのメディアから起動するのと同じくらい簡単です。実際、データが失われたり破損したりしているデバイスから起動しないと、デバイスを復元する可能性が大幅に高まります。

11. 概要

この記事では、データが失われたり、破損したり、削除されたりする可能性のあるさまざまな方法について説明しました。また、すべてのケースで診断、修復、および回復について説明しました。

結論として、失われたデータを復元するためのツールはたくさんありますが、手順を実行する前に、いつ、何が損失を引き起こしたかを分析する必要があります。

getdocs

13036