LVM 위에 있는 소프트웨어 RAID1 파티션 크기 조정(축소 및 확장)

cat /proc/mdstat

(원문에는 df, pvdisplay, vgdisplay, lvdisplay 출력들도 포함되어 있습니다. 실제 환경에서는 이 출력들을 캡처해 두세요.)

## 1. 온전한(Intact) 배열에서 축소하는 절차

아래 절차는 원문 예시를 한국어로 자세히 설명한 것입니다. 각 명령의 목적을 병기했습니다.

준비: 라이브 시스템에서 부팅한 뒤 필요한 커널 모듈을 로드합니다.

mdadm.conf 백업 및 재생성:

RAID 배열 자동 활성화:

LVM 서비스 시작:

파일 시스템 검사(항상 수행):

설계 목표(예시): /dev/md1(5GB)를 4GB로 축소. 원리: 파일 시스템 크기 <= LV 크기 <= PV 크기 <= md 크기. 따라서 파일 시스템 → LV → PV → md 순으로 조정.

1) 파일 시스템 축소(예: root FS를 2G로 설정 — 실제로는 사용 중인 용량보다 여유 있게 지정)

목적: LV보다 파일 시스템이 크지 않도록 만드는 단계입니다. 실패 시 데이터 손실 위험이 있으니 resize2fs가 허용하는 최소 크기를 반드시 초과해야 합니다.

2) LV 축소(예: root LV를 2.5G로 축소)

주의: lvreduce는 영구적 변경입니다. 명령어 실행 전 lvdisplay 결과와 사용중인 바이트를 확인하세요. -L 대신 -l(논리 확장 단위 이용)을 사용할 수도 있습니다.

3) 끝에 위치한 swap LV 제거(원본 예시에서는 swap이 PV 끝에 있었음)

설명: PV를 더 작게 만들려면 PV 끝에 배치된 LV가 있으면 안 됩니다. 만약 swap이 끝에 있지 않다면 삭제 대신 해당 LV가 PV 안에 들어가게끔 크기를 조정하세요.

4) PV 크기 축소(예: /dev/md1을 3G로 설정)

목적: PV의 크기를 md보다 작게 조정하여 md를 축소할 수 있도록 만듭니다. --setphysicalvolumesize는 PV의 새로운 크기를 지정합니다.

5) md 장치 축소(예: md를 4GiB로 축소). mdadm --grow의 --size 값은 KiB 단위로 지정해야 하며 64로 나누어질 수 있어야 합니다. 예: 4GiB = 4 * 1024 * 1024 KiB = 4194304

주의: md 장치를 줄이는 작업은 위험할 수 있으니 정확한 계산을 확인하세요. 배열의 블록 수가 줄어들면 PV와 그 위의 데이터가 영향을 받습니다.

6) PV를 가능한 최대 크기로 재조정(옵션: pvresize만 실행하면 PV는 md의 현재 크기에 맞게 최대 크기로 조정됩니다)

7) VG 및 LV 상태 확인(vgdisplay로 잔여 PE 확인)

- 예시: 383 free PE가 생기면 삭제했던 swap LV를 재생성 가능

8) root LV 확장(남은 PE 사용)

9) 파일 시스템을 LV의 최대 크기로 확장

10) 최종 파일 시스템 검사

이제 재부팅 후 mdstat와 df -h, pvdisplay, vgdisplay, lvdisplay를 확인하여 모든 것이 의도치 않게 줄어들지 않았는지 검증합니다.

중요: 위 순서를 잘못 적용하면 데이터 손실이 발생할 수 있습니다. 특히 resize2fs와 lvreduce를 사용할 때는 파일 시스템 사용량과 지정할 크기를 반드시 확인하세요.

## 2. 열화된(Degraded) 배열에서의 대처(핵심 전략)

상황: 한 디스크가 완전히 실패했고, 남은 디스크에 손상된 섹터 일부가 존재하여 전체 동기화가 실패할 수 있습니다. 전략은 손상된 섹터를 md 장치에서 제외하도록 md 크기를 줄여 안전한 블록만 남기고, 새 디스크로 대체한 뒤 다시 확장하는 것입니다.

일반 절차(요약):

1) 남은(작동 중인) 디스크에서 I/O 오류를 유발하는 섹터가 배열 끝에 위치해 있는지 확인합니다(로그: dmesg, /var/log/kern.log).
2) 레스큐 환경에서 LVM과 mdadm을 활성화하고 파일 시스템을 언마운트/체크합니다.
3) 위의 '온전한 배열' 절차와 동일하게 파일 시스템 → LV → PV를 축소하여 md를 작게 만들고, mdadm --grow --size로 md를 줄여 손상된 섹터를 제외합니다.
4) 새 하드디스크를 물리적으로 설치하고 파티션을 생성(원래와 동일한 파티셔닝), 새 파티션을 md 배열에 추가하여 re-sync를 수행합니다.
5) 리빌드가 끝나면 실패한 디스크를 제거하고 필요한 경우 교체된 디스크로 동일한 작업을 반복합니다.
6) 안전이 확인되면 md를 원래 크기로 확장하고 pvresize → lvextend → resize2fs 순으로 확장합니다.

중요: degraded 상태에서 md 크기를 줄이는 것은 가능하지만, 줄이기 전에 남아있는 블록에 필수 데이터가 있는지 여부를 반드시 확인하세요. 배열의 동기화가 중간에 실패하면 남은 복사본에서 복구 불가능한 데이터 손상이 발생할 수 있습니다. 항상 백업이 우선입니다.

예시 작업 흐름(원문에서 사용한 방식과 유사):

- /dev/md1의 문제 섹터가 sdb5의 끝부분에 있다 판단 → md 크기를 줄여 해당 섹터 제외
- 새 디스크(sda 교체)에서 새 파티션(sda5) 생성 → mdadm --add /dev/md1 /dev/sda5 → sync 완료
- sync 완료 후 /dev/sdb5를 제거하고(sdb 교체) → 새 sdb5 추가 → md sync 완료
- md를 다시 원래 용량으로 확장 → pvresize → lvextend → resize2fs

참고: 배열의 shrink가 불가능하거나 위험할 때 대체 방법은 전체 디스크를 새로 복제(예: dd → 네트워크 전송)하거나 백업에서 재구성하는 것입니다.

## 3. 대안 접근법 및 언제 실패하는가

대안 1: 전체 LVM과 파일 시스템을 새 디스크로 마이그레이션
- 장점: md나 PV 축소 과정에서 발생할 수 있는 복잡성을 회피
- 단점: 더 많은 I/O와 데이터 복사 필요

대안 2: 손상된 디스크를 제거하고 남은 복제본으로 바로 복구 후 백업에서 복원
- 장점: 신속
- 단점: 복원 시간이 길고 다운타임 가능성

실패 가능성/한계:
- 파일 시스템이 축소하려는 크기보다 실제 사용량이 크면 resize2fs가 실패합니다.
- PV의 메타데이터가 손상되어 pvresize나 vgdisplay가 제대로 동작하지 않을 수 있습니다.
- mdadm --grow --size로 배열을 줄이는 작업은 데이터 레이아웃에 따라 불가능한 경우가 있습니다.

대응: 문제 발생 시 즉시 작업을 중단하고 백업에서 복원하거나 전문가와 상의하세요.

## 4. 점검 및 검증 체크리스트

사전점검(작업 전)
- [ ] 전체 백업 수행
- [ ] Live 환경에서 부팅 가능 미디어 준비
- [ ] mdadm과 lvm2 패키지 설치 확인
- [ ] 현재 md, PV, VG, LV, 파일 시스템 사용량 스냅샷 확보
- [ ] 중요 로그(dmesg, kern.log) 확인

작업 중
- [ ] 각 단계 후 vgdisplay, pvdisplay, lvdisplay, df -h 결과 확인
- [ ] resize2fs 실행 전 e2fsck 실행
- [ ] mdadm 상태 확인(cat /proc/mdstat)

작업 후
- [ ] 전체 검증(e2fsck, mount 테스트)
- [ ] 재부팅 후 부팅 로그 확인
- [ ] 모니터링(예: SMART, dmesg)로 디스크 상태 추적

역할별 체크리스트

- 시스템 관리자
  - 백업과 복원 절차 문서화
  - 유지보수 시간(다운타임) 계획
  - RAID/파티션 레이아웃 검토

- 운영자
  - Live USB로 부팅 및 네트워크 연결
  - 명령 실행 및 결과 캡처
  - 재부팅 후 서비스 확인

- 엔지니어(하드웨어)
  - 디스크 교체 및 파티션 레이아웃 동일성 확인
  - SMART 검사 및 불량 섹터 검사

## 5. 위험 행렬 및 완화

- 리스크: 데이터 손상(중대) — 완화: 전체 백업, 체크섬/스냅샷
- 리스크: 재동기화 실패 또는 중단(중) — 완화: 디스크 상태 점검, 충분한 전력 및 쿨링
- 리스크: 인적 실수(중) — 완화: 단계별 승인, 명령 기록

## 6. 테스트 케이스 및 수락 기준

테스트 케이스 1: 온전한 테스트 배열에서 축소
- 준비: 테스트 md에 동일한 LVM, 파일 시스템 구성
- 실행: 전체 절차 수행(파일 시스템 축소 → LV 축소 → PV 축소 → md 축소 → pvresize → LV 재생성 및 확장 → resize2fs)
- 수락 기준: 재부팅 후 파일 시스템의 데이터 무결성 확인, df와 lvdisplay가 예상 크기와 일치

테스트 케이스 2: degraded 상태 재현
- 준비: 한 디스크를 오프라인으로 설정하여 degraded 상태 유도
- 실행: 위의 degraded 절차 수행
- 수락 기준: 동기화 성공 및 데이터 무결성 확보

## 7. 복구 플레이북(요약된 SOP)

1) 백업 확보
2) Live 미디어로 부팅 → md, lvm 활성화
3) e2fsck 실행 → resize2fs로 FS 축소
4) lvreduce로 LV 축소 → lvremove로 끝부분 LV 제거(필요 시)
5) pvresize --setphysicalvolumesize로 PV 축소
6) mdadm --grow --size로 md 축소
7) pvresize(크기 자동 맞춤) → lvcreate, lvextend, resize2fs 순으로 복원 및 확장
8) e2fsck로 최종 검사 → 재부팅

## 8. 머리 속 모델(휴리스틱)

- "항상 위에서 아래로(축소) — 아래에서 위로(확장)"을 기억하세요: 파일 시스템 → LV → PV → md → 물리 디스크.
- "끝(끝부분)에 있는 LV가 문제" — PV 끝부분에 LV가 있으면 축소 전 이동 또는 삭제 필요.
- "백업 없이는 축소하지 마라" — 축소는 되돌릴 수 없는 경우가 있습니다.

## 9. 자주 묻는 질문

### Q: 파일 시스템이 XFS이면 절차가 달라지나요?
A: 예. XFS는 온라인 축소를 지원하지 않습니다. XFS의 경우 백업 → 새 FS 생성 → 데이터 복원 방식으로만 축소가 가능합니다.

### Q: mdadm --grow --size 값이 잘못되면 어떻게 하나요?
A: 즉시 작업을 중단하고 md 상태를 확인하세요. 가능한 경우 최신 백업에서 복원하거나 전문가에게 문의하세요. 일부 상황에서는 --size를 다시 키워 복구가 가능할 수 있습니다.

### Q: 라이브 시스템에서 LV를 줄일 수 있나요?
A: 루트나 마운트된 파일 시스템을 줄이려면 언마운트하거나 레스큐 환경에서 작업해야 안전합니다. 마운트된 상태에서의 축소는 매우 위험합니다.

## 10. 용어집(한 줄 요약)

- mdadm: Linux 소프트웨어 RAID 관리 도구
- LVM: 논리 볼륨 매니저
- PV: 물리적 볼륨(예: /dev/md1)
- VG: 볼륨 그룹
- LV: 논리 볼륨
- e2fsck: ext 계열 파일 시스템 검사 도구
- resize2fs: ext 계열 파일 시스템 크기 조정 도구

## 11. 검증을 위한 체크리스트(간단 템플릿)

- 백업 완료: [ ]
- Live 미디어 준비: [ ]
- md 상태 캡처: [ ]
- PV/VG/LV 스냅샷: [ ]
- e2fsck 완료: [ ]
- resize2fs(축소) 완료: [ ]
- lvreduce 완료: [ ]
- pvresize --setphysicalvolumesize 완료: [ ]
- mdadm --grow(--size) 완료: [ ]
- pvresize(최대화) 완료: [ ]
- lvcreate/lvextend/resize2fs(확장) 완료: [ ]
- e2fsck(최종) 완료: [ ]
- 재부팅 및 서비스 확인: [ ]

## 결론

LVM 위에 있는 소프트웨어 RAID1 파티션을 축소 및 확장하는 작업은 순서와 사전 준비가 중요합니다. 항상 파일 시스템 검사와 전체 백업을 먼저 수행하고, 레스큐 환경에서 단계별로 진행하세요. 열화된 배열의 경우 md 크기를 줄여 손상된 섹터를 제외한 뒤 새 디스크로 재구성하는 방법이 실무에서 유용합니다. 본 문서의 체크리스트와 플레이북을 따라 안전하게 작업하시기 바랍니다.

---

참고: 본 문서는 실무 예시와 일반적인 권장 절차를 설명하며, 특정 환경에서는 추가 조치가 필요할 수 있습니다. 문제가 복잡하거나 불확실하면 즉시 숙련된 시스템 엔지니어나 데이터 복구 전문가에게 문의하세요.