4개의 드라이브가 있는 LVM PV 그룹이 있습니다. 드라이브에 장애가 발생하여(음, 새 케이스에 설치하고 종료했습니다.) 다른 드라이브로 교체하고 남은 데이터를 복구했습니다.
재부팅 후 LVM 파일 시스템 검사가 진행되지 않습니다 /dev/mapper/storage-storage1. 취소하고 건너뛰기 위해 fastboot 플래그로 재부팅했습니다. 장치 fsck에서 실행했는데 한동안 /dev/mapper/...실행되다가 RAM이 부족해 실패했습니다. 이제 물리적 드라이브 중 2개가 파티션 테이블을 표시하지 않으며 VG에서 누락되었습니다. 전체 드라이브에 걸쳐 있는 LVM 파티션이 있습니다.
어쨌든 이 LVM을 없애고 RAID5 구성을 설정하고 싶지만 먼저 LVM에 일부 데이터를 백업하고 싶습니다. (다시 다운로드할 수 없는 것은 없지만 먼저 로컬에 백업해 두면 시간이 많이 절약됩니다.)
두 드라이브 모두에서 손실된 파티션 정보를 복구할 수 있습니까? 호스트 운영 체제는 OpenMediaVault가 포함된 Debian 7입니다.
답변1
같은 문제를 겪고 있는 누군가를 위해,
PV Create 명령을 사용하고 이전 UUID를 사용하여 UUID를 설정했습니다. LVM에는 파티션 매핑이 필요하지 않으므로 계속 데이터를 볼 수 있습니다. 어떤 UUID가 어떤 드라이브에 속하는지 알아내기 위해 더 깊이 파헤쳐야 했습니다. 결국 나는 추측할 뿐이다. 드라이브가 하나만 누락된 경우 누락된 UUID를 사용하게 됩니다.
추측하고 있다면 파일 시스템을 읽기 전용으로 마운트하고 파일을 확인하십시오. 손상된 파일을 발견한 경우 UUID를 제거하고 교환합니다(드라이브가 여러 개 누락되었다고 가정).
이 문제의 원인이 무엇인지 아직도 모르겠습니다. 그러나 위의 단계를 통해 내가 원하는 데이터 중 일부를 얻을 수 있을 만큼 오랫동안 문제가 해결되었습니다. 그래서 나는 매우 행복합니다.
답변2
모든 LVM 구조가 손상되지 않은 것처럼 들리므로 작업이 좀 더 쉬워집니다. 다음 단계를 사용하여 복구 가능한 데이터를 복구할 수 있습니다.
LV 이미지 사본 만들기
작업할 수 있도록 충분한 공간이 있는 곳에 배치하세요. dd_rescue이것에 아주 효과적입니다. 때를할 수 있는원본 버전에서 작업하면 시작한 곳으로 돌아갈 수 있습니다. 음... 문제가 발생하면 다시 복사본을 만드세요.
잔해를 찾아내기 위해 디지털 포렌식 프로그램을 사용
무료 도구인 Autopsy가 바로 그 일을 할 수 있습니다. Windows 전용 복구 도구만큼 사용자 친화적이지는 않지만 처음 사용자를 위한 Sleuth Kit보다 낫습니다. Sleuth Kit를 사용하면 파일 시스템 구조를 실제로 이해할 수 있지만 학습 곡선이 상당히 가파릅니다.
반면 부검 결과는 나쁘지 않았다. 이것은Autopsy 사용을 위한 단계별 지침
데이터 손실의 원인은 무엇입니까?
드라이브 하나만 고장난 것처럼 보일 수 있지만 어딘가에 또 다른 문제가 숨어 있거나 이 문제가 발생하지 않을 것입니다. RAID-5에 의해 "복구된" 일부 데이터는 유효하지 않습니다. 더 나은 데이터 무결성 보장(ZFS, btrfs 등)이 있는 항목을 조사하고 싶을 수도 있습니다.