RAID가 구성되어있다고 들은 서버가 하드 디스크 fail된 이후에야 LVM 구성되었다는 걸 알게 됐다.
LVM은 RAID(5, 6)와 달리 디스크 fail 시 데이터가 유실된다.
수많은 감정을 억누르고 하나씩 문제를 해결해보았다.
문제의 서버는 fedora 13이 운영되고 있는 Dell PowerEdge 530였다.
서버에서 자체적으로 디스크 에러를 경고해주어 LVM이 아닌 디스크 자체의 문제로 확인되었다.
배경지식
fedora를 포함한 대부분의 리눅스에서는 Physical Volumn(PV)과 Volumn Group(VG), Logical Volumn(LV)을 이용하여 LVM을 구성한다.
다수의 물리 디스크, 즉 PV가 볼륨 그룹(VG)을 구성하고 이 VG가 다시 다수의 논리 디스크(LV)를 구성하는 방식이다.
즉, 사용자가 사용하는 드라이브는 LV지만 그 실체는 PV인 것이다.
이 상황에서 PV 중 하나가 fail된다면 해당 PV와 연관된 데이터가 JBOD처럼 모두 유실될 수 있다.
그래도 VG 내 LV 중 해당 PV와 연관되지 않은 데이터는 lvchange를 통해 복구할 수 있다.
다만 하나의 파일이라도 여러 PV로 쪼개어 저장될 수 있기 때문에 데이터 복구 가능성이 높진 않다는 것이 문제다.
cf. 이런 심각한 일이 터지면 미신을 믿게 된다.
예전에 과열에 노출된 디스크를 냉동보관하면 플래터가 잠시 정상 형태로 돌아가 데이터 백업을 받을 시간 정도는 확보할 수 있다는 이야기를 들은 적이 있다.
반신반의하다가 천과 비닐로 디스크를 싸매고 6시간정도 냉동보관을 했더니 놀랍게도 디스크가
살아나지 않았다.
믿을 걸 믿어야 한다.
기도가 통하지 않으니 이젠 과감한 선택만 남았다.
1. LV 복구
VG에서 missing PV와 연관되지 않은 데이터를 대상으로 LV를 복구한다.
참고로 VG의 이름은 vgs나 vgdisplay, LV의 이름은 lvs 등의 명령어로 알 수 있다.
$ lvchange --partial -ay /dev/<VG_NAME>/<LV_NAME>
2. 복구된 LV 마운트
LV를 복구한 후에는 dd나 ddresque를 통해 백업하는게 일반적이나
필자는 다음과 같이 복구된 LV를 마운트해서 다른 디스크에 복구된 내용을 저장하고자 한다.
데이터 복구 후에는 다시 마운트를 해제한다.
$ mount /dev/<VG_NAME>/<LV_NAME> /mnt $ cp -r /mnt/* /path/to/backup/ $ umount /mnt
3. 기존 VG 제거
기존의 문제가 됐던 VG를 제거하고 하드웨어 수준의 RAID를 적용하려 한다.
다음의 명령어를 통해 VG와 PV 설정을 모두 제거한다.
$ lvremove /dev/<VG_NAME>/<LV_NAME> $ vgremove <VG_NAME> $ pvremove /dev/<PV_NAME>
이제 서버 RAID 컨트롤러를 통해 RAID를 구성하여 알맞게 사용하면 된다.
전 단계에서 백업했던 데이터를 RAID 구성된 디스크에 저장한 후, 다시 백업에 사용된 디스크를 백업 디스크로 사용한다. (rsync)
$ rsync -av --delete /source/directory/ /backup/directory/