LVM 스냅샷으로 물리 서버 데이터 볼륨 롤백하기

애플리케이션 업그레이드는 프로그램 교체에 그치지 않고 인덱스, 리소스 파일, 데이터 형식까지 바꿀 수 있습니다. 이전 설치 패키지만 보관해 두었다고 해서 데이터 볼륨을 되돌릴 수 있는 것은 아닙니다. 이미 LVM(논리 볼륨 관리)을 사용하는 물리 서버라면 쓰기를 중단한 뒤 단기 스냅샷을 만들고, 오프라인 병합으로 업그레이드 전 상태를 복원할 수 있습니다. 중요한 것은 스냅샷 명령의 성공 여부가 아니라 쓰기 중단 범위, 여유 용량, 복원 후 검증 절차를 빠짐없이 갖추는 것입니다.

1. 대상 볼륨과 롤백 범위부터 확인하기

이 글은 Debian 13, ext4 파일 시스템, 일반 LVM 데이터 볼륨을 기준으로 설명합니다. 루트 파일 시스템, 부팅 볼륨, 씬 풀은 다루지 않습니다. CloudUDP의 기본 구성은 1TB NVMe 두 개가 각각 직접 연결된 형태이며, 하드웨어 RAID는 없습니다. 그렇다고 시스템이 이미 LVM으로 구성되어 있다는 뜻은 아니므로 실제 스토리지 구성을 현장에서 확인해야 합니다.

먼저 마운트 소스, 파일 시스템 유형, 논리 볼륨 속성, 볼륨 그룹의 여유 공간을 기록합니다.

findmnt -T /srv/appdata -o SOURCE,TARGET,FSTYPE,OPTIONS
sudo lvs -a -o vg_name,lv_name,lv_attr,segtype,origin,data_percent
sudo vgs -o vg_name,vg_size,vg_free
sudo lsblk -f

대상이 일반 파티션이라면 이 절차를 적용하지 말고 즉시 중단합니다. 스냅샷을 만들기 위해 기존 데이터가 있는 영역을 포맷해서는 안 됩니다. 출력에 씬 볼륨, 캐시 계층 또는 그 밖의 복잡한 구성이 나타나면 해당 스토리지 구성에 맞는 절차를 사용해야 합니다.

이하에서는 실제 데이터 볼륨을 vgdata/appdata, 마운트 지점을 /srv/appdata, 관련 서비스를 app.service로 가정합니다. 이 이름은 반드시 실제 환경의 값으로 바꾸고, 중첩된 마운트나 다른 쓰기 주체가 없는지도 확인해야 합니다. 명령은 단계별로 실행해야 하며, 글 전체를 복사해 한꺼번에 실행하면 안 됩니다.

스냅샷은 백업이 아닙니다

일반 LVM 스냅샷은 쓰기 시 복사(Copy-on-Write) 방식으로 원본 볼륨의 블록이 변경되기 전 데이터를 보존하며, 원본 볼륨과 그 하위 스토리지에 의존합니다. 디스크 장애로부터 데이터를 분리해 보호하지 못하고, 볼륨 밖의 설정, 프로그램, 원격 데이터도 포함하지 않습니다.

스냅샷을 병합하면 스냅샷 생성 이후 볼륨 안에서 발생한 모든 쓰기가 취소됩니다. 업그레이드 후 이미 업무 요청을 처리했다면 보존해야 할 새 데이터를 먼저 내보내고, 해당 데이터가 이전 버전 프로그램과 호환되는지 확인해야 합니다. 이 확인 없이 바로 롤백해서는 안 됩니다.

2. 서비스 중지 후 일관된 복원 지점 만들기

업그레이드 전에 독립적인 백업을 준비하고 프로그램 버전, 설정 요약, 애플리케이션 상태를 기록합니다. 스냅샷이 보장하는 것은 지정한 볼륨의 블록 상태뿐입니다. 여러 볼륨이나 외부 데이터베이스가 연관되어 있다면 구성 요소 전체에 걸친 일관성 확보 범위를 별도로 설계해야 합니다.

서비스를 중지하기 전에 유입 요청, 큐 소비자, 예약 작업을 일시 중지하여 서비스가 멈춘 뒤에도 다른 프로세스가 데이터를 변경하지 못하게 합니다. 다음 명령에서는 정상적인 마운트 해제 성공을 쓰기가 멈췄다는 판단 기준으로 삼으며, 강제 마운트 해제나 지연 마운트 해제는 사용하지 않습니다.

sudo systemctl stop app.service
sudo fuser -vm /srv/appdata
sudo sync
sudo umount /srv/appdata

마운트 해제 시 사용 중이라는 오류가 발생하면 현재 작업 디렉터리, 열린 파일, 다른 서비스를 확인합니다. 쓰기 주체를 모두 제거하기 전에는 다음 단계로 진행하지 않습니다. 이후 스냅샷을 만듭니다.

sudo lvcreate --snapshot --size 20G \
  --name preupgrade /dev/vgdata/appdata
sudo lvs -o lv_name,lv_attr,origin,data_percent vgdata
sudo mount /srv/appdata

여기서 20G는 예제용 스냅샷 공간이며, 제품 사양이나 모든 환경에 적용되는 권장값이 아닙니다. 실행 전에 볼륨 그룹에 충분한 여유 공간이 있고 preupgrade가 아직 존재하지 않는지 확인합니다. 스냅샷 용량은 롤백 관찰 기간에 변경될 데이터 블록의 양을 기준으로 산정해야 하며, 원본 볼륨 전체 용량의 일정 비율로 기계적으로 정해서는 안 됩니다.

원본 볼륨을 다시 마운트한 뒤 먼저 작은 검증용 파일을 만들고, 통제된 상태에서 업그레이드를 진행합니다. 이때도 실제 업무 쓰기는 계속 차단해야 합니다. 그렇지 않으면 나중에 롤백할 때 별도의 데이터 인계 절차가 필요합니다.

3. 스냅샷을 읽기 전용으로 확인하고 사용량 감시하기

스냅샷 생성에 성공한 뒤에는 내용을 읽을 수 있는지 반드시 검증해야 합니다. 다음 옵션은 이 글의 ext4 예제에만 해당합니다. ro는 읽기 전용을 뜻하고, noload는 마운트 시 저널 재생을 막습니다. 다른 파일 시스템에 그대로 적용해서는 안 됩니다.

sudo mkdir -p /mnt/app-preupgrade
sudo mount -t ext4 -o ro,noload \
  /dev/vgdata/preupgrade /mnt/app-preupgrade
sudo sha256sum /mnt/app-preupgrade/manifest.json \
  | sudo tee /root/app-preupgrade.sha256
sudo umount /mnt/app-preupgrade

manifest.json은 실제로 선정한, 내용이 안정적으로 유지되는 업무 파일을 가리킵니다. 미리 파일이 존재하는지, 검증 대상으로 의미가 있는지 확인해야 합니다. 체크섬 목록은 대상 볼륨 밖에 저장하며, 롤백 후에는 마운트 경로가 아니라 파일 체크섬 필드만 비교합니다.

변경량을 기준으로 위험 판단하기

sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata
sudo vgs -o vg_name,vg_free

Data%는 일반 LVM 스냅샷 공간의 사용 비율이며, 원본 볼륨의 파일 시스템 사용률이 아닙니다. 업그레이드 전후로 지속해서 값을 수집하고 증가 속도를 관찰해야 합니다. 인덱스의 대량 재구축이나 대용량 파일 덮어쓰기 같은 작업은 공간을 빠르게 소모할 수 있습니다.

미리 정한 경계 수준에 가까워지면 추가 쓰기를 일시 중지하고 용량 확장을 검토합니다. 볼륨 그룹에 여유 공간이 있고 스냅샷이 유효한 상태라면 검토 결과에 따라 용량을 늘릴 수 있습니다.

sudo lvextend -L +10G /dev/vgdata/preupgrade

공간을 늘려도 업무상 허용된 롤백 기한이 연장되지는 않습니다. 스냅샷이 이미 무효화되었다면 용량 확장을 복구 수단으로 간주해서는 안 되며, 독립 백업에서 복원하는 절차로 전환해야 합니다. 알림을 받을 곳과 대응 절차가 없는 스냅샷 모니터링은 신뢰할 수 있는 보호 수단이 아닙니다.

4. 오프라인으로 병합하고 복원 결과 검증하기

롤백하기로 결정했다면 먼저 업무 요청 유입을 차단하고, 실패 원인을 확인할 자료와 반드시 보존해야 할 새 데이터를 저장합니다. 볼륨 밖의 프로그램과 설정도 서로 맞는 버전으로 복원해야 합니다. 데이터 볼륨만 되돌리면 이전 데이터와 새 프로그램이 잘못 조합될 수 있습니다.

스냅샷이 유효하고 스냅샷 마운트 지점이 해제된 상태인지 확인한 다음, 관련 서비스를 모두 중지하고 원본 볼륨의 마운트를 해제합니다. 다음 작업은 데이터를 변경하므로 실행 전에 볼륨 이름을 다시 확인합니다.

sudo systemctl stop app.service
sudo umount /srv/appdata
sudo lvchange -an /dev/vgdata/appdata
sudo lvconvert --merge /dev/vgdata/preupgrade
sudo lvchange -ay /dev/vgdata/appdata
sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata

병합이 다음 활성화 시점에 실행되도록 예약되었다면, 완료될 때까지 상태를 관찰해야 합니다. 명령이 성공을 반환했다는 이유만으로 업무 서비스를 시작해서는 안 됩니다. 병합에 성공하면 스냅샷 볼륨은 사라집니다. 그다음 원본 볼륨을 다시 마운트하고 확인합니다.

sudo mount /srv/appdata
sudo sha256sum /srv/appdata/manifest.json
sudo cat /root/app-preupgrade.sha256

파일 체크섬은 기준값과 같아야 하고, 스냅샷 생성 후 만든 검증용 파일은 사라져야 합니다. 다만 이것으로 입증할 수 있는 것은 지정한 파일이 이전 상태로 돌아갔다는 사실뿐이며, 애플리케이션이 올바르게 동작한다는 뜻은 아닙니다. 프로그램 버전, 주요 레코드 수, 읽기 결과, 통제된 쓰기 작업 한 번까지 확인한 다음 서비스를 시작하고 로그를 점검해야 합니다.

5. 리허설 결과를 업그레이드 체크리스트로 정리하기

먼저 운영 데이터를 담지 않은 데이터 볼륨에서 전체 절차를 한 번 연습하고, 스냅샷 생성, 용량 증가, 병합 상태, 애플리케이션 점검 결과를 기록합니다. 운영 환경을 업그레이드하기 전에는 최소한 다음을 확인해야 합니다.

• 대상이 기존 일반 LVM 데이터 볼륨이며, 마운트 소스와 볼륨 이름이 서로 일치합니다.
• 모든 쓰기 주체를 중지할 수 있고, 원본 볼륨을 정상적으로 마운트 해제할 수 있으며, 독립 백업의 검증이 끝났습니다.
• 스냅샷 공간을 변경량에 근거해 산정했고, 볼륨 그룹에 확장용 여유 공간이 있습니다.
• 이전 버전 프로그램, 볼륨 밖의 설정, 복원 체크리스트를 모두 확보할 수 있습니다.
• 새로 기록한 데이터를 보존하는 방법과 업무 재개 조건이 명확합니다.

업그레이드 검증을 통과하고 롤백 관찰 기간이 끝나면 스냅샷이 마운트되어 있지 않은지 확인한 뒤, lvremove /dev/vgdata/preupgrade로 아직 남아 있는 스냅샷을 정리합니다. 이미 병합한 스냅샷은 다시 삭제할 필요가 없습니다.

최종 결과물은 볼륨 구성, 복원 지점, 용량 기록, 업무 검증 결과를 담은 작업 기록이어야 합니다. 스냅샷은 단기 롤백 도구일 뿐입니다. 신뢰성은 볼륨 이름 하나를 더 남겨 두는 데서가 아니라, 반복해서 실행할 수 있는 복원 절차에서 나옵니다.

자주 묻는 질문