VPS 이전 완벽 가이드 2026: 서버 이사하기

이 글에는 제휴 링크(affiliate link)가 포함되어 있습니다. Vultr·Hetzner 가입 링크로 가입하시면 추가 비용 없이 크레딧 혜택을 받으실 수 있으며, 블로그 운영에 도움이 됩니다.

공급자 간 서버 이전은 새 서버를 먼저 만들고 rsync로 파일을, mysqldump로 데이터베이스를 옮긴 뒤, 미리 낮춰 둔 TTL을 이용해 A 레코드를 새 IP로 바꾸는 순서가 기본입니다. DigitalOcean 공식 문서는 스냅샷을 내려받을 수 없다고 밝히므로, 제공사를 바꿀 때는 파일과 데이터베이스 단위로 옮겨야 합니다.

VPS 이전 완벽 가이드 2026: 공급자 간(Vultr-DigitalOcean-Hetzner) 서버 이사하기 — 사진: Jordanhill School D&T Dept / flickr (BY)

VPS를 쓰다 보면 언젠가 다른 제공사로 옮기고 싶은 순간이 옵니다. 더 싼 곳을 찾았거나, 리전을 바꾸고 싶거나, 성능이 부족해서일 수 있습니다. 서버 이전은 잘못하면 다운타임과 데이터 유실로 이어지는 만큼, 체크리스트를 따라 순서대로 진행하는 게 안전합니다. 이 글에서는 Vultr·DigitalOcean·Hetzner처럼 서로 다른 제공사 사이에서 서버를 이사하는 절차를 정리합니다.

아직 첫 서버를 안 만들었다면 VPS 입문 완벽 가이드를, 어디로 옮길지 고민 중이라면 한국 사용자를 위한 VPS 선택 가이드를 먼저 참고하세요. 이전 후 백업 체계를 다시 잡고 싶다면 VPS 백업 자동화 가이드도 함께 보시면 좋습니다.

이전 전에 무엇을 준비해야 하나요?

새 서버부터 만들기: 기존 서버를 끄기 전에 새 서버를 먼저 생성해 병행 운영 기간을 확보합니다.
설치된 소프트웨어 목록 정리: dpkg --get-selections로 Ubuntu 기준 설치 패키지 목록을 뽑아 두면 새 서버에 무엇을 설치할지 파악하기 쉽습니다. 이 목록만으로 자동 설치되지는 않으며, 복원하려면 --set-selections와 apt-get dselect-upgrade 같은 도구가 따로 필요합니다(Debian dpkg 매뉴얼).
도메인/DNS 관리 권한 확인: DNS를 바꿀 수 있는 계정 접근 권한을 미리 확보해 둡니다.
TTL 미리 낮추기: 현재 TTL만큼 앞서(예: TTL이 이틀이면 이틀 전부터) DNS 레코드의 TTL을 300초 정도로 낮춰 두면 전환 시 반영이 빨라지고, 전환 뒤 안정되면 TTL을 다시 올립니다(AWS Route 53·Cloudflare 문서).

데이터를 옮기는 방법 3가지는 각각 언제 쓰나요?

방법	적합한 경우	다운타임
rsync로 파일 직접 복사	웹 파일, 정적 사이트	거의 없음
DB 덤프 후 복원(mysqldump)	워드프레스 등 DB 기반 서비스	덤프~복원 시간만큼
제공사 스냅샷/이미지 이전	같은 제공사 안에서 서버 전체를 옮길 때(제공사 간 이전에는 쓰기 어려움)	스냅샷 생성·복원 시간

가장 흔한 조합은 rsync로 파일을 옮기고, mysqldump로 DB를 덤프해 새 서버에 복원하는 방식입니다.

# 기존 서버 -> 새 서버로 파일 동기화
rsync -avz -e ssh /var/www/ user@새서버IP:/var/www/

# DB 덤프
mysqldump --single-transaction -u root -p 데이터베이스명 > backup.sql

# 새 서버에서 복원
mysql -u root -p 새데이터베이스명 < backup.sql

rsync로 파일은 어떻게 옮기나요?

rsync는 양쪽 서버에 설치돼 있어야 하고 원격 전송에는 보통 ssh를 씁니다. 공식 매뉴얼(2026년 10월 확인)에 따르면 -a 는 재귀 복사와 심볼릭 링크·권한·소유자 보존을 묶은 옵션이고 ACL(-A)·xattr(-X)·하드링크(-H)는 빠져 있습니다. 소유자 보존(-o)은 받는 쪽 rsync가 슈퍼유저일 때만 적용되므로 새 서버에서는 root로 받으세요. 소스 끝의 /는 “copy the contents of this directory”(폴더 내용을 복사)라는 뜻이라 위 예시의 /var/www/ 는 내용만 풀고, 슬래시를 빼면 www 폴더가 한 겹 더 생깁니다.

동기화 전에는 항상 –dry-run (-n) 으로 실제 변경 없이 목록부터 확인하세요. 옛 서버에서 지운 파일까지 맞추는 –delete 는 매뉴얼이 잘못 쓰면 위험하다며 –dry-run 선행을 권하고, dir/* 같은 와일드카드가 아니라 디렉터리 전체를 보내야 동작합니다.

rsync -avz –dry-run /var/www/ root@새서버IP:/var/www/: 목록을 확인한 뒤 –dry-run 을 빼고 1차 동기화를 실행합니다.
rsync -avz –delete –dry-run /var/www/ root@새서버IP:/var/www/: 점검 모드로 바꾼 뒤 삭제 대상을 확인하고, 맞으면 –dry-run 을 빼 실행합니다.

데이터베이스는 어떻게 옮기나요?

MySQL 8.4 공식 mysqldump 문서 기준입니다(MariaDB는 버전별 옵션 지원을 확인하세요). –single-transaction 은 격리 수준을 REPEATABLE READ 로 정하고 START TRANSACTION 을 보낸 뒤 덤프해, 서비스를 막지 않고 그 시점의 일관된 데이터를 받습니다. InnoDB 같은 트랜잭션 테이블에서만 유용하고 덤프 중 다른 연결에서 ALTER TABLE·DROP TABLE·TRUNCATE TABLE 같은 문을 쓰면 안 되므로, 플러그인 업데이트는 덤프 뒤에 하세요.

명령은 mysqldump –single-transaction -u root -p 데이터베이스명 > backup.sql 이고, 복원은 공식 문서대로 기본 데이터베이스를 지정하며 없으면 먼저 만들어야 합니다.

워드프레스는 공식 이전 문서에 따라 도메인과 URL이 그대로면 파일과 데이터베이스 복사로 끝나고, 새 서버에 같은 DB 이름과 같은 로그인 정보의 사용자를 만들면 가장 쉽습니다. 이름이 달라지면 wp-config.php 를 고치세요. DNS 전환 전에 IP로 열어 테스트하려면 siteurl 과 home 을 임시로 바꿔야 하지만 hosts 파일 방식이면 필요 없습니다. 환경 구성은 Vultr 워드프레스 튜토리얼을 참고하세요.

스냅샷으로 다른 제공사에 통째로 옮길 수 있나요?

같은 제공사 안에서는 편하지만 제공사를 바꿀 때는 막힙니다. DigitalOcean 공식 문서는 스냅샷을 내려받을 수 없다고 밝히고 대안으로 rsync나 SFTP를 안내합니다.

“No, you cannot currently download DigitalOcean backups or snapshots.”

— 출처: DigitalOcean 문서, Can I download a backup or snapshot?(확인일 2026-10-04)

Vultr와 Hetzner 공식 FAQ가 설명하는 스냅샷 활용(리전 간 복제, 원하는 위치에 새 서버 생성)도 같은 제공사 안의 이야기입니다. 제공사가 바뀌면 rsync와 데이터베이스 덤프가 기본 경로이며, 어디로 옮길지는 세 제공사 비교 글을 참고하세요.

무중단에 가깝게 전환하려면 어떤 순서로 하나요?

새 서버에 동일 환경 구축: 웹서버(Nginx/Apache), 언어 런타임, DB를 기존과 같은 버전으로 맞춥니다.
데이터 1차 동기화: 서비스가 켜진 상태에서 rsync로 기존 서버의 데이터를 먼저 옮겨 둡니다.
점검 모드 전환 후 최종 동기화: 짧게 서비스를 점검 모드로 걸어두고, 그 사이 변경분만 다시 rsync로 반영합니다.
새 서버에서 정상 동작 확인: 새 서버의 IP로 hosts 파일을 임시로 걸어 직접 접속 테스트를 합니다.
DNS 전환: A 레코드를 새 서버 IP로 변경합니다. 미리 낮춰 둔 TTL 덕분에 대부분의 방문자가 비교적 빨리 새 서버로 전환됩니다(사용자 DNS 캐시 때문에 5분보다 더 걸릴 수 있습니다, Cloudflare 문서).
기존 서버는 며칠 유지 후 삭제: DNS 전파가 늦은 일부 방문자·캐시를 고려해 3~7일 정도는 기존 서버를 살려둔 채로 지켜봅니다.

DNS 전환은 언제 어떻게 하나요?

TTL은 레코드가 캐시에 머무는 시간이라 Cloudflare 공식 문서는 TTL이 길수록 변경 반영이 늦어진다고 설명합니다. Route 53 문서는 이미 쓰는 도메인을 바꿀 때 짧은 값을 먼저 지정하라고 안내합니다.

“specify a shorter value first, such as 300 seconds, and increase the value after you confirm that the new settings are correct.”

— 출처: Amazon Route 53 문서, TTL (seconds)(확인일 2026-10-04)

캐시된 옛 값은 그 TTL이 지나야 사라지므로 낮춘 뒤 낮추기 전 TTL 이상 기다려야 하는데, Route 53 문서는 긴 TTL의 예로 172800초(이틀)를, Cloudflare 문서는 DNS 전용 레코드의 TTL 범위로 60초(Enterprise 제외)부터 1일을 듭니다. 그러니 위 체크리스트의 “하루 전”은 현재 TTL이 하루 이하일 때만 맞습니다. 프록시 상태의 Cloudflare 레코드는 TTL이 Auto(300초)로 고정이고, 문서는 사용자 PC의 DNS 캐시 때문에 5분보다 더 걸릴 수 있다고 덧붙입니다(Cloudflare CDN 설정 가이드).

새 서버에 IPv6가 있으면 AAAA 레코드도 바꾸고, 옛 AAAA가 남지 않게 하세요. 전환 뒤 안정되면 TTL을 원래 값으로 올립니다.

SSL 인증서는 언제 다시 발급받나요?

Let’s Encrypt의 HTTP-01 방식은 도메인 주소의 /.well-known/acme-challenge/ 경로 파일을 80번 포트로 확인하므로(공식 문서), DNS가 옛 서버를 가리키는 동안 새 서버에서 발급하면 검증 요청이 옛 서버로 갑니다. 전환 직후 발급하거나 _acme-challenge TXT 레코드로 확인하는 DNS-01로 미리 발급하세요. 시험은 certbot certonly 에 –dry-run 을 붙여 스테이징 서버로 하고(Certbot 문서), 같은 도메인 조합은 7일에 5장까지만 발급되니(발급 한도) 설치를 반복하지 마세요. 발급 뒤에는 certbot renew –dry-run 과 systemctl list-timers 로 갱신도 확인합니다(Let’s Encrypt SSL 튜토리얼).

제공사가 달라지면 무엇을 주의해야 하나요?

Vultr에서 Hetzner로, 혹은 반대로 옮길 때는 이미지·부팅 방식의 차이를 제공사 문서에서 확인해야 합니다. 방화벽 설정도 제공사 대시보드에서 별도로 관리하는 경우가 있어, 새 서버에서 ufw 같은 OS 레벨 방화벽을 다시 한번 확인하는 게 안전합니다.

옮긴 뒤에는 무엇을 확인해야 하나요?

화면과 기능: 로그인, 검색, 이미지 업로드를 눌러 보고, 워드프레스는 공식 이전 문서 안내대로 고유주소 화면에서 퍼머링크를 다시 저장합니다.
권한과 빠진 설정: 업로드·캐시 폴더에 웹 서버 계정이 쓸 수 있는지 확인하고, rsync는 지정한 폴더만 복사하므로 crontab, systemd 서비스, 웹 서버 설정 파일은 따로 옮깁니다.
방화벽·허용 IP: 제공사 방화벽과 ufw를 다시 적용하고(VPS 보안 가이드), 외부 서비스에 등록한 옛 IP를 새 IP로 바꿉니다.
백업·모니터링: 백업과 모니터링을 새 서버에 다시 설정하고, 옛 서버 접속 로그에 요청이 없을 때 삭제합니다.

자주 묻는 질문 (FAQ)

Q1. 서버 이전 중에 사이트가 완전히 멈추나요?

체크리스트대로 병행 운영 기간을 두면 실제 다운타임은 DNS 전환 오차 시간(TTL을 낮춰 뒀더라도 사용자 DNS 캐시에 따라 몇 분 이상 걸릴 수 있습니다) 정도로 줄일 수 있습니다.

Q2. 실패하면 기존 서버로 되돌릴 수 있나요?

기존 서버를 바로 삭제하지 않고 며칠 유지하면, DNS를 다시 기존 IP로 돌리는 것만으로 롤백이 가능합니다.

Q3. IP가 바뀌는데 SSL 인증서도 다시 받아야 하나요?

Let’s Encrypt처럼 도메인 기반 인증서는 새 서버에서 도메인 소유권을 다시 확인하면 됩니다. HTTP-01 방식은 DNS가 새 서버를 가리킨 뒤에야 통과합니다. 도메인 이름용 인증서는 IP와 무관하지만, IP 주소용 인증서를 쓴다면 IP가 바뀔 때 다시 받아야 합니다(Let’s Encrypt 문서).