Eric's Garden🌳

Proxmox 마이그레이션

10 min read

1. 개요

홈랩 환경을 운영하면서 Radxa X4가 너무 작아, 보다 큰 미니 PC를 구입했습니다. 사용하던 LXC들을 새로운 서버로 마이그레이션하는 작업이 필요했다. 처음에는 단순히 백업 파일을 옮겨 ‘Restore’ 버튼만 누르면 모든 게 끝날 줄 알았다.

하지만 막상 Restore 하려니 헤드리스이니 WireGuard를 통해서 서버를 접근하는 문제와 기존에 돌아가고 있던 LXC 번호와 겹치는 문제부터, 경고, 그리고 헷갈리는 스토리지 용량 표기까지 다양한 의문점들이 있었다. 이 글은 그 과정에서 마주친 문제들과, 해결을 위해 고민했던 내 생각의 흐름을 정리한 기록이다.

2. 안전한 이사를 위한 마이그레이션 절차 (Action Plan)

단순히 백업 본을 옮기는 것을 넘어, 서비스 간의 의존성을 고려하여 내가 직접 수행한 6단계 루틴이다.

2-1. [사전 준비] WireGuard DNS 수정

가장 먼저 외부 접속의 길목인 WireGuard의 DNS 설정을 수정했다. Pi-hole을 사용하는데 LXC를 중지 시켜야하는데 Pi-hole LXC를 종료하면 VPN 연결에 문제가 생길거라고 판단했다. Pi-hole을 바라보던 DNS 주소를 1.1.1.1(Cloud flare)로 설정하고 진행했다.

2-2. [정지] 의존성을 고려한 LXC 순차 종료

무작정 모든 전원을 끄는 것이 아니라, 서비스 간의 연결 고리를 생각하며 정지했다.

  1. 응용 프로그램(App): 가장 바깥쪽 서비스들을 먼저 꺼서 데이터 요청을 중단한다.
    • 운영중인 서비스가 담긴 Docker LXC들과 Grafana, Prometheus LXC
  2. 데이터베이스(DB): 앱이 꺼진 후 남은 데이터를 안전하게 저장하며 종료한다.
    • MySQL, PostgreSQL, Redis, Minio, Meilisearch
  3. 인프라/네트워크: 마지막으로 DNS 서버나 프록시 관련 LXC를 정지한다.
    • Cloudflared, Pi-hole, NPM

2-3. [백업 및 전송] 이삿짐 싸기와 푸시(Push)

  • 백업: 데이터 정합성을 위해 ‘정지(Stop)’ 모드로 백업 파일을 생성했다.

  • 전송: scp 명령어를 사용해 백업본을 새 서버의 /var/lib/vz/dump/ 경로로 전송했다. 보안을 위해 IP 주소와 핑거프린트 등은 생략하고 실제 과정만 간략히 재현하면 다음과 같다.

scp [백업_파일_경로] [사용자]@[새_서버_IP]:[대상_경로]
  • 화면은 다음과 같이 나온다.
# 새로운 Proxmox 서버로 백업 파일 전송
$ scp /var/lib/vz/dump/vzdump-lxc-121-2026_04_08.tar.zst root@192.168.0.xxx:/var/lib/vz/dump/
 
# 처음 연결 시 나타나는 보안 확인 (Fingerprint)
The authenticity of host '192.168.0.xxx (192.168.0.xxx)' cant be established.
ED25519 key fingerprint is SHA256:AbCdEfG12345...[생략]...XyZ.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
 
Warning: Permanently added '192.168.0.xxx' (ED25519) to the list of known hosts.
 
# 새 서버 비밀번호 입력 후 전송 진행
root@192.168.0.xxx Password: 
vzdump-lxc-121-2026_04_08.tar.zst          100% 1.2GB  85.4MB/s   00:14
  • 전송이 완료되면 마이그레이션 할 서버에 백업본이 노출된다.

2-4. [복원 및 기동] 입주와 순차 가동

새 서버에서 local storage 화면에 복원을 진행한 후, 정지의 역순(인프라 → DB → App) 으로 서비스를 깨웠다. 통로를 먼저 열고, 데이터를 준비시킨 뒤, 최종 서비스를 띄우는 안정적인 방식이다.

3. 핵심 내용: 시행착오

3-1. 복원과 LXC 번호(VMID)의 딜레마

가장 먼저 부딪힌 문제는 “가져온 백업본의 LXC 번호(예: 101번)가 새 서버에 이미 존재할 때, 그냥 덮어씌워도 될까?” 였다.

결론부터 말하자면 절대 안 된다. Proxmox에서 LXC 번호는 ‘아파트 동호수’와 같다. 같은 번호로 복원을 때려버리면 101호에 살고 있던 기존 세입자(데이터)를 완전히 쫓아내고 백업본으로 덮어씌우게 된다.

“기존 애들을 다른 번호로 이사시키고 빈자리에 복원할까?” 고민도 했지만, Proxmox에는 클릭 한 번으로 번호를 바꾸는 기능이 없었다(Clone 후 삭제 방식만 가능).

최종 결정: 굳이 수고를 들여 옛날 번호를 고집하기보다, 현재 상태를 유지한 채 백업본에 새 번호를 부여하여 복원하는 방식으로 타협했다.

3-2. 부팅과 동시에 마주친 경고: Systemd 252

어찌저찌 복원을 마치고 121번 LXC를 실행했는데, 터미널에 묘한 경고 문구가 떴다.

WARN: Systemd 252 detected. You may need to enable nesting.
TASK WARNINGS: 1

이유는 이 방에 입주한 ‘젊은 집사(Systemd 252)’ 가 너무 똑똑했기 때문이다. Meilisearch는 고성능 검색 엔진인 만큼 자원을 정밀하게 관리해야 하는데, 이 집사는 작업을 위해 방 안에 자신만의 ‘작은 텐트(작업대)’ 를 치고 싶어 했다. 이것이 바로 Nesting(중첩) 기능이다.

하지만 Proxmox(건물주)는 기본적으로 보안을 위해 방 안에서 또 다른 구조물을 만드는 행위를 금지한다. 결국 작업을 시작하려던 집사가 ‘정밀 도구가 없어서 일을 못 하겠다’라고 불평한 것이 경고의 정체였다.

  • 해결 방법: 해당 LXC의 [Options] - [Features] 메뉴에서 ‘nesting’ 항목을 체크해주었다. 이는 집사에게 작업대를 만들어도 좋다고 공식 허가증을 내준 것과 같으며, 이후 경고는 사라졌다.

3-3. 내 백업본은 어디로 갔을까? 스토리지 구조의 이해

복원된 디스크는 local-lvm:vm-121-disk-0 처럼 local-zfs 공간에 잘 안착했다. 하지만 “SSD는 2개인데 왜 목록은 3개고, pve 노드는 왜 2GB만 쓰고 있을까?” 라는 의문이 남았다.

알고 보니 Proxmox 스토리지 목록은 ‘물리 디스크 개수’가 아니라 ‘용도별 가상 구역’ 이었다.

  • local (pve): 서버 운영체제용 ‘관리사무소’. 시스템용이라 2~3GB만 쓰는 게 정상이다.

  • local-zfs: 첫 번째 SSD의 나머지 공간. 세입자가 사는 ‘메인 아파트’.

  • samsung980: 추가로 장착한 두 번째 SSD를 통째로 할당한 ‘제2 아파트 단지’. 공간을 분리해두어야 세입자 짐이 꽉 차더라도 관리사무소(OS)가 뻗어버리는 대참사를 막을 수 있다는 정석적인 설계를 이해하게 되었다.

3-4. LXC 폴더링에 대한 미련

리스트가 너무 길어져서 Pool 기능을 검토했지만, 치명적인 단점이 있었다. 바로 서버의 핵심 정보(노드 상태, 스토리지 등)를 볼 수 없는 [Pool View] 모드로 시야가 제한된다는 점이다. 최종 결정: 결국 Pool 기능은 쓰지 않기로 했다. 대신 기본 뷰를 유지하면서, LXC에 ‘태그(Tags)’ 를 달아 색깔별로 구분하고, 방 번호(VMID) 대역을 규칙적으로 나누는 방식으로 리스트를 관리하기로 했다.

4. 마무리

클릭 몇 번이면 끝날 줄 알았던 마이그레이션이었지만, WireGuard의 길목을 다듬고 서비스 간의 질서를 부여하며 Proxmox라는 시스템의 뼈대를 공부할 수 있었던 소중한 경험이었다. 번거롭더라도 무작정 따라치기보단 “왜 이렇게 작동하는가?”를 파고들었던 과정이 앞으로의 홈서버 운영의 밑거름이 될 것 같다.

최신글

그래프 뷰