☰

업데이트 1

tag-icon • tag-icon lvm data-recovery mdadm raid1
업데이트 1

고장난 오래된 NAS 드라이브에서 데이터를 복구하려고 합니다. 왜 실패했는지는 잘 모르겠지만 드라이브에 있는 파일은 비교적 손상되지 않았으며 과거에 꽤 투박한 debugfs 방법을 사용하여 일부 작업을 완료할 수 있었습니다. 나는 내 삶을 더 쉽게 만들어 줄 올바르고 올바른 방법으로 이것을 설치하기를 희망하면서 이것을 다시 보고 있습니다. 실제 올바른 드라이브처럼 실제로 설치하는 데 몇 가지 문제가 있었습니다. 문제의 드라이브는 SDB이고 파티션 SDB8에는 내 모든 데이터가 있습니다.

[dan-mech15g2rx sdb8]# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda           8:0    1     0B  0 disk  
sdb           8:16   0   1.8T  0 disk  
├─sdb1        8:17   0  19.1M  0 part  
├─sdb2        8:18   0    18M  0 part  
├─sdb3        8:19   0   954M  0 part  
├─sdb4        8:20   0   953M  0 part  
├─sdb5        8:21   0   191M  0 part  
├─sdb6        8:22   0   954M  0 part  
├─sdb7        8:23   0   976M  0 part  
└─sdb8        8:24   0   1.8T  0 part  
  └─md127     9:127  0   1.8T  0 raid1 
nvme0n1     259:0    0   1.8T  0 disk  
├─nvme0n1p4 259:1    0 381.5G  0 part  
├─nvme0n1p5 259:2    0   300M  0 part  /boot/efi
├─nvme0n1p6 259:3    0  31.3G  0 part  [SWAP]
├─nvme0n1p7 259:4    0   250G  0 part  /
└─nvme0n1p8 259:5    0   1.2T  0 part  /home

mdadm이 이를 md127로 어셈블했습니다. 1개 드라이브의 Raid1 어레이입니다. 예, 말도 안 되는 일이라는 건 알지만, 사전 구축된 NAS가 이렇게 구성되어 있습니다.

[dan-mech15g2rx sdb8]# mdadm -Dv /dev/md127
/dev/md127:
           Version : 1.2
     Creation Time : Sat Jul 13 20:02:09 2013
        Raid Level : raid1
        Array Size : 1949349781 (1859.04 GiB 1996.13 GB)
     Used Dev Size : 1949349781 (1859.04 GiB 1996.13 GB)
      Raid Devices : 1
     Total Devices : 1
       Persistence : Superblock is persistent

       Update Time : Sun Apr 30 14:35:46 2023
             State : clean 
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : resync

              Name : BA-001075392B1C:1
              UUID : fca7e030:4cde51c2:8d9cd534:be1158a5
            Events : 96133

    Number   Major   Minor   RaidDevice State
       0       8       24        0      active sync   /dev/sdb8

이 RAID 드라이브를 마운트하려고 하면 다음과 같은 결과가 나타납니다.

[dan-mech15g2rx sdb8]# mount /dev/md127 /mnt/sdb8
mount: /mnt/sdb8: unknown filesystem type 'LVM2_member'.
       dmesg(1) may have more information after failed mount system call.

이것은 내 LV 그룹입니다.

[dan-mech15g2rx sdb8]# vgscan
[dan-mech15g2rx sdb8]# lvscan
[dan-mech15g2rx sdb8]# lvdisplay
[dan-mech15g2rx sdb8]# vgdisplay
[dan-mech15g2rx sdb8]#

저는 지난 며칠 동안 LV 제품을 사용해 왔지만 일종의 LV 작업의 일부로 드라이브가 지워지는 것을 방지하는 데 매우 조심스럽습니다. 정말 이 드라이브에 들어가서 파일을 꺼내서 완전히 지우고 싶습니다. 이 시점에서 진행하는 방법에 대한 아이디어가 있으면 크게 감사하겠습니다.

답변1

걱정 없이 테스트 목적으로 LVM 블록 장치의 "읽기 전용 복사본"을 생성할 수 있습니다.

dmsetup create lvm_pv_ro --readonly --table "0 "$(blockdev --getsz /dev/md127)" linear /dev/md127 0"

그런 다음:

pvscan --cache /dev/mapper/lvm_pv_ro
pvs
vgs

업데이트 1

방금 "블록 장치 복사본"을 생성하면 LVM이 동일한 PV를 두 번 보게 되어 심각한 문제가 발생할 수 있다는 것을 깨달았습니다(미러링된 btrfs 볼륨에서도 유사한 문제가 발생할 수 있음). 이를 처리하는 것이 가능할 수도 있지만 원시 블록 장치를 사용하고 LV 읽기 전용만 활성화하는 것이 더 쉽습니다.

pvscan --cache /dev/md127
vgchange -ay --readonly vg_name
# mount LVs
mount /dev/vg_name/lv_name /path/to/mountpoint

물론 파일 시스템을 읽기 전용으로 마운트할 수도 있습니다. 이상하게도 이것이 모든 쓰기 액세스를 차단하지는 않습니다(커밋되지 않은 로그 항목을 처리하는 것은 예외입니다).

관련 정보