LVMファイルシステムの回復

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
                ]
            }
        }
    }
}

ベストアンサー1

非常に幸運で、以前のサイズ変更のためにLVに断片化がない場合を除き、LVMのサイズを元のサイズに戻してLVMを変更することはできません。新しいLVは20G元のファイルシステムの最初の程度を持つ可能性が高いですが、残り780G(または何でも)はスクランブルエッグ(間違ったデータ、誤ったオフセット、誤った順序)です。

HDDメディアを使用しているとします。 SSDの場合、データは消えるissue_discards=1ためlvm.conf、このオプションは決して使用されません。

/etc/lvm/{archive,backup}/以前のバージョンのメタデータを確認する必要があります。ここにあるすべてのファイルは生成された日付を表します。たとえば、次のようになります。

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

Created before lvresize 850あなたは行方不明だと言った人を探していますG。その後、vgcfgrestoreLVMメタデータは正常に動作することを望み、そのバックアップを使用します。

このデータが失われたLive CDでこれを実行したか、ルートLVが破損しているためにそのファイルが存在しない場合は、/etc/lvmLVMメタデータを復元する必要があるため、状況がさらに複雑になります。正常に。循環バッファーにこの記録を含めます。

内部に何があるかを確認するためのおおよその方法は次のとおりです。

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

おすすめ記事