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
. 그런 다음 vgcfgrestore
LVM 메타데이터 는 정상적으로 작동하기를 바라며 해당 백업을 사용합니다.
이 데이터가 손실된 Live CD에서 이 작업을 수행했거나 루트 LV가 손상되었기 때문에 에 해당 파일이 없는 경우 /etc/lvm
LVM 메타데이터를 복원해야 하기 때문에 상황이 더 복잡해집니다. 정상으로. 순환 버퍼에 이 기록을 포함합니다.
내부에 무엇이 있는지 확인하는 대략적인 방법은 다음과 같습니다.
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 파일을 찾는다고 주장합니다.