web-dev-qa-db-ja.com

LVMファイルシステムのリカバリ

私はこれに従ってLUKSクリプトのサイズを変更しようとしていました https://wiki.archlinux.org/index.php/Resizing_LVM-on-LUKS そして私はパーティションのサイズ変更に行き着きました。新しいサイズとして870と入力し、最後にGを付けるのを忘れました。パーティションが870Mに縮小され、すぐに870Gにサイズ変更されましたが、それまでに損傷が発生しました。幸いなことに、LUKS暗号を復号化することはできましたが、論理ボリュームにシステム上にデバイスファイルを持たせることさえできませんでした。 LVMはボリュームを存在するものとして認識し、接続されているデバイスファイルを表示しましたが、ファイルが存在せず、ファイルシステムがないことを示しました。 vgscan --mknodesを実行すると、デバイスファイルが正常に生成されましたが、testdiskでは表示されませんでした。ボリュームを再作成し、新しいext4ファイルシステムをそのボリュームに配置すると、testdiskにドライブが表示されますが、スキャンしても何も生成されません。たくさんのext4エントリを取得しましたが、すべて「ファイルシステムを開くことができません」または「ファイルが見つかりません」と表示されます。とにかく、ディスク上にあったファイルシステムを回復することはできますか？それが不可能でない限り、データを取得するまでデータを書き込みたくありません。

編集：私が助けを必要としている本物を突っついた後、以前のext4ファイルシステムからファイルを回復することです。私のドライブにはext4システムがあり、それ以降は新しいシステムで上書きされていますが、Sudo dd if=/dev/Storage/Storage bs=1M | strings -fn 16で示されているように、古いシステムのすべてのデータがまだ存在しています。失敗した後に私がした唯一のことは、新しいext4 FSをオンにすることだけでした。そのため、ほとんどのデータはおそらくまだ無傷です。そのデータを回復する必要があります。

pvdisplayは次のことを示しています

--- Physical volume ---
PV Name               /dev/mapper/Storage
VG Name               Storage
PV Size               931.51 GiB / not usable 3.68 MiB
Allocatable           yes (but full)
PE Size               4.00 MiB
Total PE              238466
Free PE               0
Allocated PE          238466
PV UUID               CAueGx-Glzx-zCd0-H00m-R8d5-KTRc-9Ff7ay

--- Physical volume ---
PV Name               /dev/mapper/sda3_crypt
VG Name               mint-vg
PV Size               118.50 GiB / not usable 0   
Allocatable           yes 
PE Size               4.00 MiB
Total PE              30336
Free PE               10
Allocated PE          30326
PV UUID               UJJfu8-S2Ac-pEZl-PlPa-uUzJ-axEs-ckbDWG

私のバックアップは示しています

# Generated by LVM2 version 2.02.98(2) (2012-10-15): Thu Aug 13 20:45:52 2015

contents = "Text Format Volume Group"
version = 1

description = "Created *before* executing '/sbin/lvreduce --config log{command_names=0} -f -l 217600 /dev/Storage/Storage'"

creation_Host = "desktop"   # Linux desktop 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64
creation_time = 1439523952  # Thu Aug 13 20:45:52 2015

Storage {
     id = "lM3S9T-inH1-mKsq-5doN-H8hT-zO3F-LF9jDx"
    seqno = 2
    format = "lvm2" # informational
    status = ["RESIZEABLE", "READ", "WRITE"]
    flags = []
    extent_size = 8192      # 4 Megabytes
    max_lv = 256
    max_pv = 256
    metadata_copies = 0

    physical_volumes {

        pv0 {
            id = "nH1Axo-5nBo-WcyA-Xc4E-KwRt-K0Ib-ScK8Ch"
            device = "/dev/mapper/Storage"  # Hint only

            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 1953520999   # 931.511 Gigabytes
            pe_start = 2048
            pe_count = 238466   # 931.508 Gigabytes
        }
    }

    logical_volumes {

        Storage {
            id = "Qb01kz-y1RG-PVQp-cGjB-sj77-xgnJ-w9kn3n"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            creation_Host = "desktop"
            creation_time = 1436247513  # 2015-07-06 22:38:33 -0700
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 238466   # 931.508 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 0
                ]
            }
        }
    }
}
linuxlvmdata-recoveryext4testdisk
3
Scoopta

非常に幸運で、以前のサイズ変更によるLVの断片化がまったくない場合を除いて、サイズを元のサイズに戻してLVMを修正することはできません。新しいLVには元のファイルシステムの最初の20G程度が含まれる可能性がありますが、残りの780G（またはその他）はスクランブルエッグ（データの誤り、オフセットの誤り、順序の誤り）です。

そして、それはあなたがHDDメディアを使用していることを前提としています。 SSDの場合、issue_discards=1にlvm.confが含まれていると、データが失われるだけなので、このオプションを使用することはありません。

メタデータの古いバージョンについては、/etc/lvm/{archive,backup}/を確認する必要があります。そこにある各ファイルは、いつ作成されたかを示しています。次に例を示します。

description = "Created *before* executing 'lvremove HDD/mdtest1'"

Gが欠落しているCreated before lvresize 850と書かれているものを探しています。そして、そのバックアップを使用してvgcfgrestore LVMメタデータを作成すると、正常に機能するようになります。

/etc/lvmにそのようなファイルがない場合、このデータを失ったLive CDからこれを行ったか、ルートLVに損傷が発生したため、状況は少し複雑になります。ディスク上のLVMメタデータは、循環バッファーにこのビットの履歴を含みます。

そこに何があるかを確認するための大まかな方法​​：

dd if=/dev/pvdevice bs=1M count=1 | strings -w -n 16
2
frostschutz

古いext4を吹き飛ばしていなければ、fsckがいくつかの修復を行い、いくつかの無傷のディレクトリ構造を見つけるという希望があったかもしれません。

mkfsを台無しにしないディスクの一部にあった代替のスーパーブロックを使用することにより、実際にはまだその希望があるかもしれません。または、古いFSのバックアップスーパーブロックの数が現在の空のFSと異なる場合は、上書きされなかったものがある可能性があります。

e2fsck -b some-offset

これは、LVが古いバイト（Frostschultzが彼の回答で説明したもの）と同じバイトにマップされている場合にのみ適用されます。

バイナリストリームから選択できるいくつかの種類のファイルを回復できます。 （ファイル名をバイト範囲にマッピングするメタデータがないため。）一部のファイルには認識可能なヘッダーがあり、ファイルの終わりがどこにあるかを知ることができます。ファイルが断片化されている限り、名前のないファイルを回復する可能性があります。

Foremost はこれを行うためのツールです。 jpg、gif、png、bmp、avi、exe、mpg、wav、riff、wmv、mov、pdf、ole、doc、Zip、rar、htm、およびcppファイルを検索すると主張しています。

1
Peter Cordes