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

답변2

이전 ext4를 버리지 않았다면 fsck일부 복구를 수행하고 손상되지 않은 디렉터리 구조를 찾을 수 있다는 희망이 여전히 있을 수 있습니다.

실제로, 당신이 다루지 않은 디스크 부분에 있는 여분의 슈퍼블록을 사용함으로써 여전히 희망이 있을 수 있습니다 mkfs. 또는 이전 FS에 현재 빈 FS와 다른 수의 백업 슈퍼블록이 있는 경우 덮어쓰지 않은 일부가 있을 수 있습니다.

e2fsck -b some-offset

이는 LV가 이전 LV와 동일한 바이트에 매핑되는 경우에만 적용됩니다(Frostschultz가 답변에서 이에 대해 이야기합니다).


바이너리 스트림에서 선택한 여러 유형의 파일을 복구할 수 있습니다. (파일 이름을 바이트 범위로 매핑하는 메타데이터가 없기 때문입니다.) 일부 파일에는 인식되는 헤더가 있으며 파일의 끝이 어디인지 알 수 있습니다. 파일이 조각화되어 있는 한 이름이 지정되지 않은 일부 파일을 복구할 수 있다는 희망이 있습니다.

가장 중요한 것은이를 수행하는 도구입니다. jpg, gif, png, bmp, avi, exe, mpg, wav, riff, wmv, mov, pdf, ole, doc, zip, rar, htm 및 cpp 파일을 찾는다고 주장합니다.

관련 정보