실용적인 VPS 백업 전략 (3-2-1 규칙)

ApexVPS 팀 작성 • 최종 업데이트: 2026년 7월 • 7분 읽기

신뢰할 수 있는 VPS 백업 전략은 5분 안에 복구할 수 있게 하느냐, 아니면 매우 나쁜 한 주를 보내게 하느냐를 결정합니다. 서버는 실패하고, 디스크는 손상되며, 배포는 잘못되고, 한 번의 오타 명령으로 디렉토리를 지울 수 있습니다. Cloudflare 학습 센터와 대부분의 인프라 팀은 동일한 간단한 원칙을 지적합니다: 3-2-1 규칙. 이 가이드는 실제 가상 서버에 적용하는 방법, 사용할 도구, 그리고 필요한 모든 일정과 테스트를 구성하여 실제로 복구가 작동하도록 하는 방법을 보여줍니다.

3-2-1 규칙의 의미

3-2-1 규칙은 수십 년 된 백업 원칙으로, 서버가 어디에 있든 변하지 않습니다:

VPS에서 이는 일반적으로 실행 중인 서버, 로컬 백업 저장소, 그리고 다른 위치의 원격 스토리지에 푸시된 암호화된 복사본을 의미합니다. 핵심은 단일 공유 장애 지점 없이 중복을 제공하는 것입니다.

VPS에서 무엇을 백업해야 하나?

전체 디스크를 블록 단위로 백업하는 것은 낭비적이고 느립니다. 좋은 백업 계획은 재생성하기 어려운 세 가지 항목을 대상으로 합니다.

애플리케이션 데이터 및 파일

업로드된 파일, 웹사이트 루트, 컨테이너 볼륨 및 사용자가 생성한 모든 것. 일반적인 경로는 /var/www, /srv, /home 및 Docker 볼륨 디렉터리를 포함합니다. 파일 서버나 위키와 같은 앱을 자체 호스팅하는 경우, 이곳에 대체할 수 없는 콘텐츠가 있습니다. 이러한 디렉터리가 일반적으로 어떻게 구성되는지에 대한 자세한 내용은 자가 호스팅을 위한 VPS 운영 가이드를 참조하세요.

데이터베이스

서비스가 실행 중일 때 라이브 데이터베이스 파일을 복사하면 반쯤 쓰여진 손상된 상태를 캡처할 수 있으므로, 일관된 덤프를 내보내야 합니다. MySQL 또는 MariaDB의 경우:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

--single-transaction 플래그는 테이블을 잠그지 않고 InnoDB 테이블의 일관된 스냅샷을 제공합니다. PostgreSQL의 경우 pg_dump를 대신 사용하세요:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

시스템 및 서비스 구성

서버를 고유하게 만드는 파일: /etc (nginx, systemd 유닛, cron, SSH 구성), 패키지 목록, TLS 인증서 및 방화벽 규칙. 장애 후 메모리에서 이들을 재구성하는 것은 백업이 피하려는 지루한 작업입니다.

백업 도구 선택

세 가지 도구가 거의 모든 VPS 사례를 다룹니다. 중복 제거와 암호화를 얼마나 중요하게 여기는지에 따라 선택하세요.

restic — 암호화 및 중복 제거 스냅샷

restic은 기본적으로 암호화와 중복 제거를 수행하는 현대적인 단일 바이너리 백업 도구입니다. 저장소를 한 번 초기화한 다음 백업을 실행하세요:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — 중복 제거 아카이브

BorgBackup은 약간 다른 워크플로우로 유사한 중복 제거 및 압축을 제공합니다:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — 단순 파일 미러링

다른 호스트로 파일을 빠르게 미러링해야 하는 경우, SSH를 통한 rsync이 강력합니다:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

-aAX 플래그는 권한, ACL 및 확장 속성을 보존하고, --delete는 미러를 소스와 동기화합니다. rsync만으로는 버전 기록이 없으므로 많은 팀이 restic 또는 borg와 함께 사용합니다.

cron으로 일정 자동화

실행해야 한다고 기억해야 하는 백업은 실행되지 않을 백업입니다. 단계를 스크립트에 넣고 실행 권한을 부여한 다음 cron으로 예약하세요. crontab을 편집하려면:

crontab -e

그런 다음 다음 줄을 추가하세요:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

출력을 기록하고 실패 시 스크립트가 0이 아닌 종료 코드를 반환하도록 하여 모니터링 및 알림 기능과 연결할 수 있게 하세요. 조용한 백업 실패는 백업이 없는 것보다 나쁩니다. 안전하다고 느끼게 만들기 때문입니다.

실제 오프사이트 복사본 유지

3-2-1 규칙에서 "1"이 대부분 빠지는 부분입니다. 보호하는 서버와 같은 곳에 있는 백업은 그 서버와 함께 사라집니다. 암호화된 복사본을 독립된 위치(객체 스토리지, 원격 SFTP 상자, 또는 다른 제공업체)로 푸시하세요. restic과 borg는 모두 예를 들어 SFTP를 통해 원격 저장소에 직접 쓸 수 있습니다:

restic -r sftp:[email protected]:/backups/restic backup /var/www

restic과 borg는 데이터가 VPS를 떠나기 전에 암호화하므로 원격 호스트는 평문을 볼 수 없습니다. 스토리지가 무한정 커지지 않도록 정책에 따라 오래된 스냅샷을 정리하세요:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

복원 테스트 — 항상

테스트되지 않은 백업은 소문에 불과합니다. 정기적으로 임시 위치에 복원을 예약하고 파일과 데이터베이스가 온전하게 돌아오는지 확인하세요:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

복원이 성공하고 데이터가 일치한다면 전략을 가진 것입니다. 그렇지 않다면, 실제 장애가 아닌 화요일 오후에 그것을 배운 것입니다.

스냅샷은 한 층일 뿐, 전체 전략이 아닙니다.

모든 ApexVPS 요금제에는 자동 백업이 포함되어 있습니다 — Starter Pro는 일일 스냅샷, Business는 시간별 스냅샷 — 그리고 나쁜 배포나 실수로 인한 삭제 후 빠른 롤백에 실질적으로 유용합니다. 하지만 그것들이 무엇인지 솔직하게 인식하세요: 우리 플랫폼에 있는 편리한 첫 번째 층입니다. 그것들은 3-2-1 규칙이 요구하는 오프사이트, 독립적으로 검증된 사본을 대체하지 않습니다. 플랫폼 스냅샷을 빠른 로컬 복원 지점으로 취급하고, 오프사이트 및 테스트 복원 요구 사항을 충족하기 위해 자체 restic 또는 borg 작업을 실행하십시오. 이 계층적 접근 방식은 희망적인 설정과 탄력적인 설정을 구분짓습니다. Nextcloud와 같은 앱을 자체 호스팅하든 운영 데이터베이스를 실행하든 마찬가지입니다.

VPS 백업 전략 체크리스트

조각을 모으면 가상 서버를 위한 완전한 백업 전략은 다음과 같습니다. 한 번 실행하고 스크립트화한 다음 cron이 계속 유지하게 하세요:

이 여섯 가지를 수행하면 3-2-1 규칙은 이론이 아니라 인프라가 의지할 수 있는 습관이 됩니다. 사고 중에 유일한 복사본이 죽은 디스크에 있었다는 것을 발견하는 비용에 비해 초기 설정의 한 시간은 사소합니다.

이 작업을 위해 완전히 제어할 수 있는 서버가 필요하신가요? ApexVPS는 39개 데이터 센터에서 전체 루트 액세스, NVMe 스토리지, 전용 리소스를 제공합니다 — 카드 없이 KYC 없는 암호화폐 전용 결제. 전용 VPS 요금제 비교 →

자주 묻는 질문

공급자 스냅샷이 백업 전략으로 간주됩니까?

스냅샷은 유용한 한 층이지만 완전한 전략은 아닙니다. 우리의 일일 및 시간별 스냅샷은 대부분의 단기 실수로부터 보호하지만, 서버와 같은 플랫폼에 있습니다. 완전한 3-2-1 백업 전략은 여전히 독립적인 오프사이트 사본과 실제 테스트된 복원이 필요합니다.

VPS를 얼마나 자주 백업해야 합니까?

잃을 수 있는 데이터 양에 따라 빈도를 맞추세요. 정적 파일과 구성은 매일, 활성 데이터베이스는 시간별 덤프가 정당합니다. cron으로 일정을 자동화하여 백업이 기억에 의존하지 않게 하세요.

VPS 백업에 가장 좋은 도구는 무엇입니까?

restic과 BorgBackup은 모두 훌륭합니다: 중복 제거, 압축, 암호화를 지원하고 오프사이트 저장소를 지원합니다. rsync는 단순 파일 미러링에 적합하고, mysqldump나 pg_dump는 데이터베이스 내보내기를 처리합니다. 많은 설정이 데이터베이스 덤프와 restic 또는 borg 실행을 결합합니다.

백업이 실제로 작동하는지 어떻게 알 수 있습니까?

일정에 따라 복원을 테스트하세요. 임시 디렉토리에 복원하고 파일 내용과 체크섬을 확인하고 데이터베이스 덤프를 스크래치 데이터베이스로 가져오세요. 복원한 적이 없는 백업은 희망적인 추측일 뿐, 복구 계획이 아닙니다.