Mold - Incremental Backup 및 Restore

[Dajeong-Park]

추가 확인 필요사항

• 호스트 재부팅 후 체크포인트 유지 확인
• 스토리지 마이그레이션 시 체크포인트 확인

백업 테스트

• Incremental Backup Command 실행
• VM snapshot revert와 incremental 백업 충돌
• 체크 포인트 없는 경우 incremental 백업 동작 실패 확인
• 가상머신 마이그레이션시 체크포인트 상실
• VM 정지 상태에서 incremental 가능 여부 확인
• VM disk 변경 시 incremental chain 영향 확인
• volume resize 후 incremental 백업 가능 여부 확인
• checkpoint metadata 없이 incremental restore 가능 여부 확인

Incremental Backup Command 실행

• 백업 관련 디렉토리 생성

#mkdir -p /backup/i-2-999-VM
#mkdir -p /backup/i-2-299-VM/full
#mkdir -p /backup/i-2-299-VM/inc1
#mkdir -p /backup/i-2-299-VM/inc2
#mkdir -p /backup/i-2-299-VM/checkpoints

• 가상머신 볼륨 확인

#virsh domblklist i-2-299-VM --details >> sda /mnt/glue-gfs/96da846d-d731-4cc3-b752-85bf79d07dcc

• FULL 백업 진행

#vi backup-full.xml
<domainbackup mode='push'>
  <disks>
    <disk name='sda' type='file'>
      <target file='/backup/i-2-299-VM/full/root.full.qcow2'/>
      <driver type='qcow2'/>
    </disk>
  </disks>
</domainbackup>
#virsh backup-begin i-2-299-VM backup-full.xml
#virsh domjobinfo i-2-299-VM

• 체크포인트1 생성

#virsh checkpoint-create-as i-2-299-VM chk1

• 가상머신 내부 데이터 변경 작업 진행
• Incremental 백업 진행

#vi backup-inc1.xml
<domainbackup mode='push'>
  <incremental>chk1</incremental>
  <disks>
    <disk name='sda' type='file'>
      <target file='/backup/i-2-299-VM/inc1/root.inc1.qcow2'/>
      <driver type='qcow2'/>
    </disk>
  </disks>
</domainbackup>
#virsh checkpoint-list i-2-299-VM
#virsh backup-begin i-2-299-VM backup-inc1.xml
#virsh domjobinfo i-2-299-VM --completed

• 체크포인트2 생성

#virsh checkpoint-create-as i-2-299-VM chk2

• 가상머신 내부 데이터 변경 작업 진행
• Incremental 백업 진행

#vi backup-inc2.xml
<domainbackup mode='push'>
  <incremental>chk2</incremental>
  <disks>
    <disk name='sda' type='file'>
      <target file='/backup/i-2-299-VM/inc2/root.inc2.qcow2'/>
      <driver type='qcow2'/>
    </disk>
  </disks>
</domainbackup>
#virsh backup-begin i-2-299-VM backup-inc2.xml

• 체크포인트 메타데이터 저장

#virsh checkpoint-dumpxml i-2-299-VM chk1  > /backup/i-2-299-VM/checkpoints/chk1.xml
#virsh checkpoint-dumpxml i-2-299-VM chk2  > /backup/i-2-299-VM/checkpoints/chk2.xml

• 체크포인트 확인

#virsh checkpoint-list i-2-299-VM

VM snapshot revert와 incremental 백업 충돌

• VM snapshot 생성

#virsh snapshot-create-as i-2-299-VM snap1

• 가상머신 내부 데이터 변경 작업 진행
• VM snapshot 복원

#virsh snapshot-revert i-2-299-VM snap1
error: Failed to revert snapshot snap1 error: operation failed: load of internal snapshot 'snap1' job failed: Could not load snapshot 'snap1' on 'libvirt-2-format': Device has active dirty bitmaps
>> incremental backup을 위해 생성된 bitmap(checkpoint) 이 존재하고 있기 때문에 snapshot revert가 차단

• 체크포인트 삭제

#virsh checkpoint-delete i-2-299-VM chk1
#virsh checkpoint-delete i-2-299-VM chk2

• VM snapshot 복원 시 정상 확인

체크 포인트 없는 경우 incremental 백업 동작 실패 확인

• Incremental 백업

#virsh backup-begin i-2-299-VM backup-inc.xml
error: Domain checkpoint not found: Checkpoint 'chk' for incremental backup of disk 'sda' not found

가상머신 마이그레이션시 체크포인트 상실

• 체크포인트 확인

#virsh checkpoint-list i-2-299-VM
Name   Creation Time
-----------------------------------
 chk1   2026-03-16 11:03:44 +0900
 chk2   2026-03-16 11:04:49 +0900

• 다른 호스트로 가상머신 마이그레이션
• 다른호스트에서 체크포인트 확인

#virsh checkpoint-list i-2-299-VM
 Name   Creation Time
-----------------------

• 다시 기존 호스트로 가상머신 마이그레이션해도 체크포인트 없음 확인
• 기존 호스트에서 체크포인트 생성시 migration 과정에서 libvirt checkpoint metadata 는 사라졌지만 qcow2 내부 persistent dirty bitmap chk1 는 남아 있음
  error: internal error: unable to execute QEMU command 'transaction': Bitmap already exists: chk1
• 가상머신 비트맵 삭제

#qemu-img info -U /mnt/glue-gfs/96da846d-d731-4cc3-b752-85bf79d07dcc
#qemu-img bitmap --remove /mnt/glue-gfs/96da846d-d731-4cc3-b752-85bf79d07dcc chk1
#qemu-img bitmap --remove /mnt/glue-gfs/96da846d-d731-4cc3-b752-85bf79d07dcc chk2

• 체크포인트 생성시 정상 확인

메타데이터를 checkpoint-dumpxml 로 저장한 후 마이그레이션 후 checkpoint-create 로 복구 필요해보임

VM 정지 상태에서 incremental 가능 여부 확인

• 가상머신 종료
• 가상머신 Incremental 백업 실행

#virsh backup-begin i-2-299-VM backup-inc1.xml
error: failed to get domain 'i-2-299-VM'

VM disk 변경 시 incremental chain 영향 확인

• 루트 볼륨 FULL 백업 후 체크포인트1 생성, 내부 데이터 작업 진행 후 incremental 백업 후 체크포인트2 생성 후 리스트 확인

# virsh checkpoint-list i-2-299-VM
 Name   Creation Time
-----------------------------------
 chk1   2026-03-16 13:40:43 +0900
 chk2   2026-03-16 13:43:31 +0900

• 데이터 디스크 연결 후 체크포인트 리스트 확인

# virsh checkpoint-list i-2-299-VM
 Name   Creation Time
-----------------------

디스크 topology 변경(attach/detach) 시 checkpoint chain이 무효화됨 확인

volume resize 후 incremental 백업 가능 여부 확인

• 루트 볼륨 FULL 백업 후 체크포인트1 생성, 내부 데이터 작업 진행 후 incremental 백업 후 체크포인트2 생성 후 리스트 확인

# virsh checkpoint-list i-2-299-VM
 Name   Creation Time
-----------------------------------
 chk1   2026-03-16 13:40:43 +0900
 chk2   2026-03-16 13:43:31 +0900

• 디스크 크기 변경 후 incremental 백업 후 작업 결과 확인 시

# virsh domjobinfo i-2-299-VM --completed
Job type:         Completed
Operation:        Backup
Time elapsed:     680          ms
File processed:   100.058 GiB
File remaining:   0.000 B
File total:       100.058 GiB

resize 후 incremental이 아니라 사실상 Full 수준으로 백업이 수행된 상황이며, libvirt 공식 권장은 resize 발생 시 체인 reset 후 full backup 수행

checkpoint metadata 없이 incremental restore 가능 여부 확인

• 체크포인트 XML 저장

#virsh checkpoint-dumpxml i-2-299-VM chk1 > chk1.xml

• 체크포인트 삭제

#virsh checkpoint-delete i-2-299-VM chk1

• XML로 체크포인트 재추가

#virsh checkpoint-create VM chk1.xml

• incremental 백업 실행

checkpoint xml만 복구하면 incremental chain 유지 가능 확인

[Dajeong-Park]

복원 테스트

• Incremental Restore Command 실행
• 잘못된 체인 조합 복원 방지 (증분백업 백킹파일로 rsync 시 가상머신 부팅 실패 확인)
• 크로스-호스트 복원 (복원 후 다른 호스트에서 가상머신 실행 시 정상동작 확인)
• restore 후 backup 재동작 검증 (체크포인트 새로 생성하여 증분백업 실행 시 정상동작 확인)
• guest consistency (write 중 백업 후 복원 시 정상동작 확인)

Incremental Restore Command 실행

• 사전작업 후 다음 환경에서 시작

Windows 10 OS 환경
/backup/i-2-288-VM/full/root.full.qcow2
/backup/i-2-288-VM/inc1/root.inc1.qcow2
/backup/i-2-288-VM/inc2/root.inc2.qcow2
/backup/i-2-288-VM/checkpoints/chk1.xml
/backup/i-2-288-VM/checkpoints/chk2.xml
FULL 시점 기준 작업 없음
Inc1 시점 기준 바탕화면 폴더 test1 생성
Inc2 시점 기준 바탕화면 폴더 test2 생성

• 복원1 (백킹파일 없는 경우-풀백업)
• 가상머신 정지
• rsync

#rsync -az /backup/i-2-288-VM/full/root.full.qcow2 /mnt/glue-gfs/8d2fb894-7832-4bd9-9aca-b8b3661ab3f3

• 가상머신 시작
• 내부 데이터 검증 (폴더없음 확인)
• 복원2 (백킹파일 있는 경우-증분백업) >> 참고 : 특정 시점까지 복원 가능 확인
• 가상머신 정지
• flatten

>> 참고 : inc로만 resync 사용 시 backing chain 깨짐, 가상머신 부팅 실패 확인
#qemu-img convert -f qcow2 -O qcow2 /backup/i-2-288-VM/inc1/root.inc1.qcow2 /tmp/restore-inc1.qcow2
#rsync -az /tmp/restore-inc1.qcow2 /mnt/glue-gfs/8d2fb894-7832-4bd9-9aca-b8b3661ab3f3

• 가상머신 시작
• 내부 데이터 검증 (폴더 test1 확인)
• 복원3 (백킹파일 있는 경우-증분백업)
• 가상머신 정지
• flatten

#qemu-img convert -f qcow2 -O qcow2 /backup/i-2-288-VM/inc2/root.inc2.qcow2 /tmp/restore-inc2.qcow2
#rsync -az /tmp/restore-inc2.qcow2 /mnt/glue-gfs/8d2fb894-7832-4bd9-9aca-b8b3661ab3f3

• 가상머신 시작
• 내부 데이터 검증 (폴더 test1, test2 확인)

incremental 스냅샷 복원시 qemu-img convert 로 합쳐서 복원본을 만드는 방식과 동일하며, 복원 후에는 기존 incremental chain을 이어서 쓰지 않고 새 chain을 시작하는 방식을 동일하게 적용해야 함 (복원 수행 -> 체크포인트 및 비트맵 전부 삭제 -> 다음 백업은 풀백업 강제 -> 이후 incremental 재개)

• 복원 후 체크포인트 확인 시 없음

#virsh checkpoint-list i-2-288-VM

• 신규 체크포인트 생성

#virsh checkpoint-create-as i-2-288-VM chk-new

• 내부 데이터 작업 (chk-new 시점 기준 바탕화면 폴더 test3 생성)
• incremental 백업

#virsh backup-begin i-2-288-VM backup-inc.xml

• 내부 데이터 작업 (chk-new 시점 기준 바탕화면 폴더 전체 삭제)
• 가상머신 정지
• flatten

#qemu-img convert -f qcow2 -O qcow2 /backup/i-2-288-VM/inc/root.inc.qcow2 /tmp/restore-inc.qcow2
#rsync -az /tmp/restore-inc.qcow2 /mnt/glue-gfs/8d2fb894-7832-4bd9-9aca-b8b3661ab3f3

• 가상머신 시작
• 내부 데이터 검증 (폴더 test1, test2, test3 확인)

복원 후에는 반드시 신규 체크포인트를 생성해야 함

guest consistency

• 사전작업 : 풀 백업, 증분백업1 생성 및 체크포인트 생성
• 내부 데이터 작업 (cmd 파일에 text 쓰기 진행(loop))
• incremental 백업2
• 내부 데이터 작업 (cmd 종료 및 파일 text 처음 date 확인시 10시7분00초, 마지막 date 확인시 10시8분09초)
• 가상머신 종료
• incremental 백업2 시점으로 복원 진행
• 가상머신 시작
• 내부 데이터 검증 (파일 text 마지막 date 확인시 10시7분12초 확인)

파일깨짐없이 도중 백업 시점까지 정상 복원됨을 확인

[Dajeong-Park]

테스트 결과에 따라 적용해야할 사항

• 체크포인트가 상실된 경우(가상머신 마이그레이션, 디스크 토폴리지 변경 시) : 풀백업 강제 후 비트맵 cleanup
• 정지중인 가상머신의 증분 백업 : dummy VM 사용 (증분 snapshot 방식과 동일)
• VM snapshot과 증분 백업 우선 순위 또는 차단 방식 : 공존 할 수 없도록 예외처리

백업 전 VM snapshot 목록 확인하여 VM 스냅샷이 있는 경우 예외처리
VM snpahost 생성 시 백업 목록 조회하여 백업 체인이 있는 경우 예외처리

• 스토리지 타입에 따른 증분 백업 방식

GFS 의 경우 libvirt checkpoint + qemu persistent dirty bitmap 기반 incremental
RBD 의 경우 rbd snap create + rbd export-diff / rbd import-diff 기반 incremental

• 디스크 resize 후 증분 백업 시 Full 수준으로 증분 백업이 수행된 상황에 대한 처리
  참고) libvirt 공식 권장은 resize 발생 시 체인 reset 후 풀 백업 수행이며, 증분 백업 전 디스크가 resize 되었는지 판단하여 처리 필요
• 고려사항1) : Multi-disk consistency 모든 디스크가 동일 checkpoint 기준으로 incremental 되어야 함
  참고) VM 데이터 consistency가 깨지는 문제로 모든 디스크 incremental 성공 → commit, 하나라도 실패 → 전체 full fallback
• 고려사항2) : 체인 관리 문제 Checkpoint / Bitmap / Metadata 불일치
  참고) Mold DB, KVM libvirt checkpoint metadata, qcow2 dirty bitmap 3개 계층 통일성 유지 실패 시 cleanup 및 full backup
• backup.delta.max 은 얼마로 유지해서 체인이 해당 값이 넘어간 경우 풀백업으로 강제하도록 할지 (libvirt 최대 200개, 체인이 많은 경우 복원 시 성능 저하로 10개 이하가 적절해보이며 cloudstack의 snapshot.delta.max 값은 16)
• rbd diff 체인의 경우 기본 max7 많아도 10개 이하

[Dajeong-Park]

RBD snapshot + export-diff 기반 incremental

• 가상머신 내부 데이터 작업
• 스냅샷 생성

#rbd snap create rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c@snap-full-1

• Full export

#rbd export-diff rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c@snap-full-1 /backup/full-1.diff

• diff

#rbd diff rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c@snap-full-1

• 가상머신 내부 데이터 작업
• 스냅샷 생성

#rbd snap create rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c@snap-inc1-1

• Incremental export

#rbd export-diff rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c@snap-inc-1 /backup/inc-1.diff

• 가상머신 내부 데이터 작업
• 스냅샷 생성2

#rbd snap create rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c@snap-inc-2

• Incremental export2

#rbd export-diff rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c@snap-inc-2 /backup/inc-2.diff

• 스냅샷 목록 확인

#rbd snap ls rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c
SNAPID  NAME         SIZE     PROTECTED  TIMESTAMP
    11  snap-full-1  100 GiB             Tue Mar 24 09:21:05 2026
    12  snap-inc-1   100 GiB             Tue Mar 24 09:23:31 2026
    13  snap-inc-2   100 GiB             Tue Mar 24 09:24:04 2026

• 가상머신 정지
• 초기상태로 롤백

#rbd snap rollback rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c@snap-full-1

• incremental 적용

#rbd import-diff /backup/inc-1.diff rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c
#rbd import-diff /backup/inc-2.diff rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c
* 에러발생 
대상 이미지를 full로 rollbackup했지만 snap-inc-1과 snap-inc-2가 남아서 발생하며, rollback은 현재 데이터를 과거 시점으로 되돌릴 뿐, 뒤에 만들어진 스냅샷 이름 자체를 자동으로 지우지 않는다.
* 해결
#rbd snap rm rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c@snap-inc-2
#rbd snap rm rbd/48289d34-5b4e-43f6-a4a1-385a8987eb1c@snap-inc-1
>> 해당 방법은 기존 이미지에 남아 있는 snapshot metadata 때문에 계속 꼬일 수 있어서 덮어쓰기방식보다는 새 이미지를 생성하여 import하는 방식으로 한 후 volume swap 적용해야함

• RBD feature 확인
• 동시 작업 충돌(snapshot) 방지 필요 : 가상머신에 대한 동시 작업 방지 (볼륨 스냅샷, VM 스냅샷, 백업, 복원, 마이그레이션, 연결/분리 등)
• 스냅샷 삭제/정리 충돌 방지 필요 : 스냅샷과 경로 충돌나지않도록 스냅샷 이름공간 완전 분리
• 복원 후 체인 충돌 방지 필요 : snapshot이든 backup chain 이든 복원 후 새 기준점부터 다시 시작하도록
• restore 후 chain reset 강제