[리눅스 스토리지] LVM 볼륨 확장 및 축소: 실전 마이그레이션 시나리오 분석

목차

• LVM 마이그레이션이 중요한 이유
• LVM 볼륨 관리 핵심 개념 정리
• 실전 시나리오 1: 디스크 확장 중심 LVM 마이그레이션
• 1. 현재 상태 확인
• 2. 새 디스크를 LVM에 편입
• 3. 논리 볼륨 확장
• 4. 파일시스템 확장
• 실전 시나리오 2: 축소 후 더 작은 디스크로 이동하는 마이그레이션
• 축소 작업 기본 순서
• 1. 사용량 확인
• 2. 파일시스템 검사 및 축소
• 3. LV 축소
• 4. 다시 마운트 후 확인
• 5. 새 디스크로 익스텐트 이동
• 6. 기존 PV 제거
• ⚠️ 주의사항과 트러블슈팅
• 1. XFS는 일반적인 축소가 어렵습니다
• 2. 축소 순서를 반대로 하면 위험합니다
• 3. 마운트 상태 확인을 자주 해야 합니다
• 4. 백업과 복구 경로를 먼저 생각해야 합니다
• 검증: 작업 후 무엇을 확인해야 하나
• 비교로 보는 확장과 축소 전략
• 자주 묻는 질문 정리
• Q1. LVM 마이그레이션 중 서비스 중단 없이 가능한가요?
• Q2. XFS를 쓰고 있는데 용량 축소가 필요하면 어떻게 하죠?
• Q3. pvmove는 언제 유용한가요?
• Q4. 작업 전에 꼭 확인할 것은 뭔가요?
• 마무리: 안전한 디스크 확장 축소의 핵심

[리눅스 스토리지] LVM 볼륨 확장 및 축소: 실전 마이그레이션 시나리오 분석

LVM 마이그레이션은 서버 운영하다 보면 생각보다 자주 만나게 됩니다. 디스크는 부족해지고, 서비스는 멈추면 안 되고, 기존 파티션 구조는 애매하게 꼬여 있거든요. 저도 홈랩과 실서버에서 LVM 볼륨 관리를 여러 번 만지면서 느낀 게 하나 있습니다. 확장은 비교적 편한데, 축소는 방심하면 바로 사고로 이어지더라고요. 특히 리눅스 스토리지를 운영하는 입장에서는 "용량만 늘리면 끝"이 아니라 파일시스템(File System, 파일 시스템)과 논리 볼륨(Logical Volume, 논리 볼륨), 물리 볼륨(Physical Volume, 물리 볼륨)의 관계를 같이 봐야 합니다.

이번 글에서는 제가 실제로 자주 쓰는 흐름 기준으로, 디스크 확장 축소가 필요한 상황에서 어떤 순서로 접근해야 안전한지 정리해보겠습니다. 단순 명령어 나열이 아니라, LVM 마이그레이션 관점에서 왜 이런 순서를 타야 하는지까지 같이 보시죠. 혹시 새 디스크를 붙였는데 기존 마운트 포인트는 그대로 유지하고 싶었던 경험 있으신가요? 바로 그 상황에 딱 맞는 내용입니다.

LVM 마이그레이션 전체 흐름을 한눈에 보여주는 개요 이미지입니다. 기존 디스크, 새 디스크, VG, LV, 파일시스템의 관계를 이해하는 데 도움이 됩니다.

LVM 마이그레이션이 중요한 이유

처음엔 저도 "디스크만 더 달면 되는 거 아닌가?" 싶었습니다. 근데 실제로 써보니까 서버는 그렇게 단순하지 않더라고요. 운영 중인 서비스는 이미 특정 마운트 포인트에 의존하고 있고, 애플리케이션은 경로가 바뀌는 걸 싫어합니다. 여기서 LVM(Logical Volume Manager, 논리 볼륨 관리자)을 쓰면 스토리지를 비교적 유연하게 다룰 수 있거든요.

• 확장: 새 디스크를 붙이고 기존 볼륨 그룹(Volume Group, 볼륨 그룹)에 편입해 용량을 늘릴 수 있습니다.
• 축소: 사용량을 정리한 뒤 논리 볼륨과 파일시스템을 줄여 더 작은 디스크로 옮길 수 있습니다.
• 마이그레이션: 서비스 경로는 유지하면서 백엔드 스토리지만 교체하는 방식이 가능합니다.

쉽게 말해, LVM은 물리 디스크와 실제 사용 볼륨 사이에 한 겹의 추상화 레이어를 둬서 운영을 편하게 해주는 도구입니다. 이 추상화가 있는 덕분에 디스크 교체나 재배치가 훨씬 수월해집니다. 물론, 축소 작업은 여전히 조심해야 합니다. 이건 진짜입니다 ㅎㅎ

LVM 볼륨 관리 핵심 개념 정리

실전 들어가기 전에 개념은 한번 정리하고 가야 합니다. 저도 처음엔 PV, VG, LV가 머릿속에서 계속 섞였거든요.

구성 요소	영어 원문	쉽게 설명하면	주요 명령어
PV	Physical Volume	디스크나 파티션을 LVM 재료로 등록한 상태	pvcreate, pvs
VG	Volume Group	여러 PV를 묶어 만든 용량 풀	vgcreate, vgextend, vgs
LV	Logical Volume	VG에서 실제로 잘라서 쓰는 논리 디스크	lvcreate, lvextend, lvs
FS	File System	ext4, XFS 같은 실제 파일 저장 구조	resize2fs, xfs_growfs

여기서 중요한 포인트! 파일시스템과 LV 크기는 별개입니다. 예를 들어 LV만 늘렸다고 파일시스템이 자동으로 다 커지는 건 아니거든요. 반대로 축소도 파일시스템부터 안전하게 줄여야 하는 경우가 많습니다. 특히 ext4와 XFS는 동작 방식이 다릅니다.

• ext4: 확장 가능, 축소도 가능
• XFS: 확장은 가능, 일반적인 축소는 불가

이 차이를 모르고 들어가면 작업 중간에 멈춥니다. 제가 예전에 XFS 볼륨을 줄이려다가 "어? 왜 안 되지?" 하고 한참 삽질했었는데, 알고 보니 파일시스템 특성이더라고요. 그 뒤로는 축소 시나리오를 보면 제일 먼저 파일시스템 타입부터 확인합니다.

실전 시나리오 1: 디스크 확장 중심 LVM 마이그레이션

가장 흔한 케이스입니다. 기존 서버의 <code>/data 용량이 부족해서 새 디스크를 추가하고, 기존 마운트는 유지한 채로 공간만 늘리는 흐름이죠. 이건 운영 입장에서 꽤 깔끔합니다.

1. 현재 구조 확인
2. 새 디스크를 PV로 초기화
3. 기존 VG에 새 PV 추가
4. 대상 LV 확장
5. 파일시스템 확장
6. 결과 검증

1. 현재 상태 확인

lsblk
pvs
vgs
lvs -a -o +devices
df -hT

이 단계에서 반드시 확인할 것들이 있습니다.

• 대상 마운트 포인트가 어디인지
• 파일시스템이 ext4인지 XFS인지
• 여유 공간이 어느 VG에 있는지
• 새 디스크 이름이 무엇인지

2. 새 디스크를 LVM에 편입

pvcreate /dev/sdb
vgextend vgdata /dev/sdb

이렇게 하면 /dev/sdb가 vgdata의 용량 풀에 추가됩니다. 여기까지는 어렵지 않습니다. 진짜 중요한 건 그 다음이죠.

3. 논리 볼륨 확장

lvextend -L +200G /dev/vgdata/lvdata

또는 남은 공간을 전부 쓰고 싶다면 이렇게도 많이 씁니다.

lvextend -l +100%FREE /dev/vgdata/lvdata

여기서 -L은 크기를 직접 지정하고, -l은 extents(익스텐트, LVM 할당 단위) 기준입니다. 처음엔 이 차이가 낯설었는데, 실제로 해보니 운영 중에는 +100%FREE가 꽤 편하더라고요.

4. 파일시스템 확장

ext4라면:

resize2fs /dev/vgdata/lvdata

XFS라면 마운트된 경로 기준으로:

xfs_growfs /data

최근 배포판에서는 한 번에 처리하려고 아래처럼 쓰는 경우도 많습니다.

lvextend -r -l +100%FREE /dev/vgdata/lvdata

-r는 파일시스템 리사이즈까지 같이 시도합니다. 다만 저는 중요한 서버에서는 단계를 나눠서 보는 편입니다. 왜냐하면 중간 확인이 가능하거든요.

새 디스크를 붙이고 VG에 편입한 뒤 LV와 파일시스템을 확장하는 흐름을 보여주는 이미지입니다. 작업 순서를 시각적으로 이해하기 좋습니다.

실전 시나리오 2: 축소 후 더 작은 디스크로 이동하는 마이그레이션

이게 진짜 실전입니다. 확장은 보통 편한데, 축소는 절차를 틀리면 데이터 손상으로 이어질 수 있습니다. 특히 디스크 확장 축소 중 축소는 무조건 백업 먼저입니다. 저는 이 작업 전에 스냅샷(snapshot, 스냅샷)이나 백업 유무부터 확인합니다.

가정해보겠습니다.

• 기존 /data가 800G LV에 올라가 있음
• 실사용량은 250G 정도
• 더 작은 SSD로 옮기기 위해 300G 수준으로 축소 필요
• 파일시스템은 ext4

축소 작업 기본 순서

1. 백업 및 사용량 확인
2. 서비스 중지 또는 오프라인 전환
3. 파일시스템 검사
4. 파일시스템 축소
5. LV 축소
6. 새 디스크로 데이터 이동
7. 기존 PV 제거

1. 사용량 확인

df -hT /data
du -sh /data
lvs
pvs

축소 목표보다 실제 사용량이 작아야 합니다. 여유 공간 없이 딱 맞추면 위험합니다. 제가 해보니 최소 20~30% 정도 버퍼를 두는 게 마음 편하더라고요.

2. 파일시스템 검사 및 축소

먼저 마운트를 해제해야 합니다.

umount /data
e2fsck -f /dev/vgdata/lvdata
resize2fs /dev/vgdata/lvdata 280G

여기서 숫자는 LV 목표보다 조금 작게 잡습니다. 예를 들어 LV를 300G로 줄일 거면 파일시스템은 280G 정도로 먼저 줄여 여유를 확보하는 식입니다.

3. LV 축소

lvreduce -L 300G /dev/vgdata/lvdata

또는 확인 프롬프트 없이 하려면 -y를 붙이기도 하지만, 저는 웬만하면 인터랙션을 보고 진행합니다. 축소는 한 번 더 눈으로 확인하는 게 낫습니다.

4. 다시 마운트 후 확인

mount /dev/vgdata/lvdata /data
df -hT /data

이제 축소된 볼륨 상태로 정상 마운트가 되는지 확인합니다. 여기서 에러가 없어야 다음 단계로 넘어갑니다.

5. 새 디스크로 익스텐트 이동

새 디스크를 추가한 뒤에는 pvmove로 기존 PV의 데이터를 새 PV로 옮길 수 있습니다.

pvcreate /dev/sdc
vgextend vgdata /dev/sdc
pvmove /dev/sda2 /dev/sdc

이 명령은 꽤 강력합니다. LVM 마이그레이션이라는 키워드에 가장 잘 맞는 도구 중 하나죠. 서비스 영향도를 줄이면서 백엔드 저장 위치를 옮길 수 있으니까요.

6. 기존 PV 제거

vgreduce vgdata /dev/sda2
pvs
vgs
lvs -a -o +devices

드디어 여기까지 오면 기존 디스크를 VG에서 뺄 수 있습니다. 이 과정이 깔끔하게 끝나면 "드디어 됐다!" 하는 느낌이 옵니다. 저도 처음 성공했을 때 꽤 뿌듯했습니다.

축소 후 새 디스크로 데이터를 옮기는 실전 마이그레이션 흐름을 보여주는 이미지입니다. ext4 기반 축소와 pvmove 개념을 함께 떠올리면 이해가 쉽습니다.

⚠️ 주의사항과 트러블슈팅

이 섹션은 경험담 비중이 좀 큽니다. 문서만 보면 간단해 보이는데, 실제로는 여기서 많이 막히거든요.

1. XFS는 일반적인 축소가 어렵습니다

이거 정말 중요합니다. XFS(File System, 파일 시스템)는 보통 확장은 가능한데 축소는 지원하지 않는 방향으로 이해하시면 됩니다. 그래서 XFS 환경에서 용량을 줄여야 한다면, 새 LV를 만들고 rsync 같은 방식으로 데이터를 옮기는 우회 전략을 더 자주 씁니다.

mkfs.xfs /dev/vgdata/newlv
mount /dev/vgdata/newlv /mnt/newdata
rsync -aHAX --info=progress2 /data/ /mnt/newdata/

처음엔 번거로워 보여도, 오히려 이 방식이 더 안전한 경우가 많습니다.

2. 축소 순서를 반대로 하면 위험합니다

파일시스템보다 LV를 먼저 줄이면 데이터가 잘릴 수 있습니다. 순서는 보통 파일시스템 축소 → LV 축소입니다. 반대로 확장은 LV 확장 → 파일시스템 확장이죠. 이 순서 하나만 제대로 기억해도 사고 확률이 확 줄어듭니다.

3. 마운트 상태 확인을 자주 해야 합니다

실제 작업하다 보면 대상 장치가 어디에 마운트되어 있는지 헷갈릴 때가 있습니다. 특히 테스트 서버에서 장치 이름이 바뀌면 더 그렇습니다.

lsblk -f
findmnt
blkid

저도 한 번은 비슷한 이름의 LV를 착각해서 식은땀 흘린 적이 있습니다. 그 뒤로는 명령 한 번 더 치는 습관이 생겼습니다.

4. 백업과 복구 경로를 먼저 생각해야 합니다

• 스냅샷이나 백업이 있는지
• 복구용 라이브 환경이 준비되어 있는지
• 원격 작업이면 콘솔 접근이 가능한지
• /etc/fstab에 UUID 또는 장치명이 어떻게 기록되어 있는지

특히 부팅 디스크가 얽힌 경우는 더 조심해야 합니다. 데이터 디스크와 달리 부트 체인(boot chain, 부팅 경로) 이슈가 추가되거든요.

검증: 작업 후 무엇을 확인해야 하나

마이그레이션은 명령이 끝났다고 끝이 아닙니다. 검증이 핵심입니다. 저는 보통 아래 체크리스트를 순서대로 봅니다.

1. 마운트 포인트가 기존과 동일한지 확인
2. 파일시스템 용량이 기대값과 맞는지 확인
3. 애플리케이션이 정상 기동하는지 확인
4. LVM 메타데이터 상 디스크 배치가 의도대로 바뀌었는지 확인
5. 재부팅 후에도 동일하게 올라오는지 확인

df -hT
lvs -a -o +devices
vgs
pvs
findmnt
cat /etc/fstab

애플리케이션 레벨 검증도 필요합니다. 예를 들어 데이터베이스라면 실제 쓰기 테스트를 해보는 게 좋고, 파일 서버라면 새 파일 생성과 삭제까지 확인해보는 게 안전합니다.

마이그레이션 완료 후 용량, 마운트, 디바이스 배치를 검증하는 모습을 보여주는 이미지입니다. 결과 확인 단계의 체크 포인트를 시각화했습니다.

비교로 보는 확장과 축소 전략

항목	확장	축소
난이도	상대적으로 쉬움	상대적으로 까다로움
다운타임	파일시스템에 따라 최소화 가능	오프라인 작업이 필요한 경우 많음
주요 위험	장치 선택 실수	순서 오류로 인한 데이터 손상
핵심 명령어	vgextend, lvextend, xfs_growfs, resize2fs	e2fsck, resize2fs, lvreduce, pvmove
추천 전략	단계별 확장 후 검증	백업 후 축소 또는 신규 볼륨 이관

여기서 중요한 포인트! 축소는 가능하면 "줄이기"보다 "새로 만들고 옮기기" 전략도 같이 검토해보세요. 특히 XFS나 운영 중단이 민감한 서비스는 그쪽이 더 현실적일 때가 많습니다.

자주 묻는 질문 정리

Q1. LVM 마이그레이션 중 서비스 중단 없이 가능한가요?

경우에 따라 다릅니다. 확장은 비교적 무중단에 가깝게 가능한 편입니다. 다만 축소는 파일시스템 특성과 서비스 쓰기 패턴에 따라 오프라인 작업이 필요할 수 있습니다.

Q2. XFS를 쓰고 있는데 용량 축소가 필요하면 어떻게 하죠?

일반적인 축소 대신 새 LV를 만들고 데이터를 복사한 뒤 마운트 전환하는 방식이 더 현실적입니다. 저도 실제로는 이 방법을 더 자주 씁니다.

Q3. pvmove는 언제 유용한가요?

기존 디스크를 교체하거나, 특정 PV에 몰린 데이터를 다른 디스크로 옮기고 싶을 때 유용합니다. LVM 볼륨 관리에서 운영 친화적인 도구 중 하나입니다.

Q4. 작업 전에 꼭 확인할 것은 뭔가요?

백업, 파일시스템 종류, 마운트 상태, 실제 사용량, 복구 경로입니다. 이 다섯 가지는 체크하고 들어가셔야 합니다.

마무리: 안전한 디스크 확장 축소의 핵심

이번 글에서는 LVM 마이그레이션 관점에서 확장과 축소를 같이 봤습니다. 제가 직접 해보니 핵심은 화려한 명령어보다도 순서와 검증이더라고요. 확장은 보통 LV 먼저, 파일시스템 나중. 축소는 파일시스템 먼저, LV 나중. 그리고 XFS는 축소보다 이관 전략을 우선 고려. 이 세 가지만 머리에 남겨도 실전에서 훨씬 덜 흔들립니다.

혹시 지금 홈랩이나 운영 서버에서 리눅스 스토리지 재구성이 필요하신가요? 그러면 먼저 테스트 환경에서 같은 구조를 재현해보세요. 저도 처음엔 헷갈렸는데, 한 번 손으로 해보면 감이 확 옵니다. 다음 글에서는 rsync 기반 무중단 데이터 이관이나 fstab 전환 전략도 다뤄보려고 합니다. 이전 글에서 파일시스템 선택 기준을 정리해두셨다면 같이 보시면 더 이해가 잘 되실 겁니다.

확장과 축소 절차, ext4와 XFS 차이, 검증 포인트를 한 번에 요약한 인포그래픽 이미지입니다. 글 내용을 빠르게 복습할 때 유용합니다.

📚 함께 읽으면 좋은 글

• tmux 세션 관리 실패 사례: 복구 및 재발 방지 전략
• zsh vs bash: 쉘 스크립팅 생산성 1년 실측 비교
• 커널 튜닝 ext4 파일 시스템 성능 최적화 실전 사례
• 벡터 DB Qdrant vs Chroma: 1년 사용 후기 및 마이그레이션 고려사항
• AWS GCS vs Azure Blob Storage, 실제 사용 비교와 마이그레이션 전략