가상서버를 쓰다 보면 “스냅샷 떠놨으니 괜찮겠지” 하고 넘어가는 순간이 옵니다. 그런데 정작 장애가 크게 났을 때 스냅샷으로 못 살리는 경우가 생각보다 많아요. 스냅샷과 백업은 이름만 비슷할 뿐 쓰임새가 다르기 때문입니다.
스냅샷이 잘하는 일과 못하는 일
스냅샷은 특정 시점의 VM 상태를 아주 빠르게 저장해두는 기능이에요. 커널 업데이트나 애플리케이션 패치처럼 되돌릴 가능성이 있는 작업 직전에 찍어두면 몇 초 만에 원래 상태로 복귀할 수 있어서 정말 편합니다.
문제는 복구 구조예요. 스냅샷으로 되돌리려면 원본 가상 디스크 파일과 스냅샷 파일이 둘 다 살아 있어야 합니다. 스토리지가 깨지거나 원본이 손상되는 진짜 장애 상황에서는 스냅샷도 같이 날아가서 아무 소용이 없어요. 그래서 스냅샷은 백업의 대체재가 아니라 “되돌리기 버튼”에 가깝습니다.
오래 남겨두면 오히려 느려져요
스냅샷을 찍은 뒤에는 변경된 데이터가 계속 별도 파일에 쌓입니다. 이 상태가 길어질수록 디스크 사용량이 늘고 입출력 경로가 복잡해져서 VM 성능이 눈에 띄게 떨어질 수 있어요. 보통 하루이틀, 길어도 사흘 안에는 정리하는 걸 권장합니다.
“나중에 지워야지” 하고 쌓아둔 스냅샷이 몇 주씩 남아 디스크를 꽉 채우는 사고도 흔해요. KVM 환경이라면 virsh snapshot-list로 주기적으로 확인하고, 역할이 끝난 스냅샷은 바로 삭제하는 습관이 필요합니다.
진짜 백업은 따로 있어야 합니다
백업의 핵심은 원본과 물리적으로 분리된 복사본이에요. 같은 서버, 같은 스토리지 안에만 있으면 그 장비가 죽는 순간 전부 같이 사라집니다. 다른 스토리지나 다른 지역으로 한 벌 더 빼두는 게 기본이에요.
주기도 중요합니다. 데이터가 자주 바뀌는 서비스라면 일 단위로는 부족할 수 있고, 반대로 변화가 거의 없는 서버에 매시간 백업을 돌리는 건 낭비예요. 얼마까지의 데이터 손실을 감당할 수 있는지를 먼저 정하면 주기가 자연스럽게 나옵니다.
복구 테스트까지 해봐야 끝
가장 많이 빠뜨리는 게 복구 훈련이에요. 백업 파일이 매일 잘 생성되고 있어도, 막상 복구해보면 용량이 부족하거나 설정이 어긋나서 시간이 한참 걸리는 경우가 있습니다. 분기에 한 번이라도 실제로 복원해보는 것이 백업 정책의 마지막 단계예요.
참고로 입출력 병목이 심하면 스냅샷·백업 작업 자체가 서비스에 영향을 줍니다. NVMe 기반 스토리지를 쓰면 이런 부담이 훨씬 줄어들어요. 백업 설계와 운영까지 함께 챙기고 싶다면 클라우드 VM·서버 관리 서비스를 살펴보셔도 좋습니다.
