목차
파일 두 개의 작은 복원 실습으로 범위 정하기
Ubuntu 또는 Linux/WSL 클라이언트의 Bash, GNU tar, sha256sum과 OpenSSH를 사용합니다. 서버용 명령은 한 서버 터미널에서, 클라이언트용은 별도 컴퓨터의 한 터미널에서 실행하세요. 변수가 유지되도록 각각 열린 상태로 두고 명령 오류가 나면 중단합니다.
홈 디렉터리에 일회용 파일 두 개를 만듭니다. Nginx, 방화벽과 운영 파일을 바꾸지 않으며 압축 해제에 root를 사용하지 않습니다. 먼저 실습 파일로 진행하세요. 선택 단계는 정적 HTTPS 배포 안내의 실제 파일 두 개로 사본만 바꿉니다.
전체 사이트에는 이미지, 리디렉션, 포함 설정, DNS와 다른 의존성 목록이 필요합니다. 이 예제는 시스템 전체나 완전한 애플리케이션 백업이 아닙니다.
운영 사이트를 건드리지 않고 실습 파일 준비하기
서버에서 접근이 제한된 실습 디렉터리를 생성합니다. 아래 Nginx 설정은 보관할 텍스트 파일이며 서비스에 활성화하지 않습니다.
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="ko"><title>복원 연습</title><h1>복원한 정적 페이지</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf '실습 디렉터리: %s\n' "$backup_lab"선택 사항: 안내에서 만든 실제 페이지와 서버 블록을 백업하려면 아래 명령으로 일회용 사본만 교체합니다. 계정이 원본 두 파일을 읽을 수 있어야 합니다. 설정에 비밀이 있는지 먼저 살피고 같은 배포 버전의 파일을 모으도록 수집 중 배포를 잠시 멈추세요. 실습 파일만 사용할 때는 이 블록을 건너뜁니다.
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"원본을 읽을 뿐 수정하지 않습니다. 인증서 개인 키나 전체 시스템 디렉터리도 복사하지 않습니다. 다른 파일이 필요하면 목록과 체크섬 매니페스트에 의도적으로 추가하세요.
아카이브와 두 단계 체크섬 만들기
서버에서 선택한 파일의 체크섬을 기록하고 상대 경로로 아카이브를 만든 뒤 아카이브 자체의 체크섬을 계산합니다. 이 동안 payload를 바꾸지 마세요.
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf '서버 내보내기 디렉터리: %s\n' "$backup_lab/export"목록에는 site/, nginx/, 선택한 두 파일과 SHA256SUMS가 있어야 합니다. 외부 체크섬은 전송한 아카이브의 변경을, 내부 매니페스트는 압축 해제한 파일을 검사합니다. 공격자가 데이터와 예상 체크섬을 둘 다 바꿀 수 있다면 어느 체크섬도 출처를 인증하지 못합니다.
별도 컴퓨터로 복사하기
클라이언트에서 remote_backup을 서버가 출력한 정확한 export 경로로 바꾸세요. 계정, 문서용 주소 203.0.113.10과 키 파일도 실제 SSH 값으로 바꿉니다. REPLACE는 실제 mktemp 접미사가 아니라 반드시 교체할 표시입니다.
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"새 서버의 SSH 지문은 신뢰하는 경로로 확인한 뒤 승인하세요. SSH 문제라면 접속 오류 진단을 사용하고 전송 성공을 위해 호스트 검증을 끄지 않습니다.
SCP는 SSH로 전송 구간을 보호합니다. tar.gz 자체는 압축 파일이지 암호화 파일이 아니므로 대상 계정·저장소를 보호하고 필요한 경우 저장 시 암호화를 적용하세요. 같은 VPS의 다른 폴더는 서버 외부 사본이 아닙니다.
새 빈 디렉터리에 복원하고 결과 검사하기
클라이언트에서 압축 해제 전 아카이브를 확인하고 sha256sum이 OK를 출력할 때만 진행하세요. 실패하면 원인을 찾거나 다시 전송해야 하며 예상 체크섬을 바꿔 오류를 숨기면 안 됩니다.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"신뢰한 아카이브를 새로 만든 디렉터리에 풉니다. keep-old-files는 기존 파일 교체를 거부하고 no-same-owner는 아카이브 소유권 복원을 피합니다. 대상을 /로 바꾸거나 sudo로 해제하지 마세요.
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"site/index.html과 nginx/first-site.conf 모두 OK인지, 복원한 페이지 제목이 맞는지 확인합니다. 이 결과는 선택한 파일의 내용 검증이며 운영 소유권, ACL, 서비스 가용성이나 모든 의존성까지 검증하지는 않습니다.
파일 복원과 서비스 복구 구분하기
복원한 설정은 아직 비활성 텍스트입니다. 별도 대체 서버에서 경로, Include, 모듈, 권한과 인증서를 검토하고 조합된 Nginx 설정을 검사한 뒤 다시 불러오세요. HTTP/HTTPS도 외부에서 확인합니다. 바꾸지 않은 운영 서버의 설정 검사는 이 복원본 검증이 아닙니다.
이 아카이브는 TLS 개인 키를 의도적으로 제외합니다. 인증서 재발급이나 별도로 보호한 인증서 백업을 계획하세요. 실행 중인 데이터베이스 파일을 이 tar 방식으로 복사하지 말고 해당 데이터베이스가 지원하는 일관된 백업과 복원 절차를 사용합니다.
제공업체 스냅샷은 머신 복구에 도움이 될 수 있지만 보관 기간, 장애 범위와 복원 절차를 확인하세요. 스냅샷이 존재한다고 내보낸 사이트 파일을 다른 호스트에서 복구할 수 있음이 입증되지는 않습니다.
복구 목표와 실제 결과 기록하기
RPO는 시간으로 표현한 허용 데이터 손실, RTO는 서비스 복구 목표 시간입니다. 작은 정적 안내 사이트에서 RPO 24시간, RTO 60분을 정할 수 있지만 이는 예시 목표이며 이번 실습의 측정 결과가 아닙니다. 매일 예약했다는 사실보다 사본 생성 성공과 복구 가능성이 중요합니다.
표를 가로로 움직이면 나머지 열을 볼 수 있습니다.
| 기록 | 확인하는 내용 |
|---|---|
| 백업 시각과 배포 식별자 | 복구할 수 있는 버전 |
| 독립 저장 위치와 보관 기간 | 사본이 살아남는 위치와 기간 |
| 아카이브·파일 체크섬 | 선택한 바이트의 복원 여부 |
| 복원 시작·종료 시각 | 정한 복원 단계에 걸린 시간 |
| 누락 파일·권한·의존성 | 서비스 복구에 남은 작업 |
| 대체 서버 외부 HTTPS 확인 | 사이트가 실제로 돌아왔는지 여부 |
접근 확보, 서버 생성, 설정, 인증서와 필요한 DNS 변경까지 전체 시간을 측정한 뒤 RTO 달성을 판단하세요. 빠른 로컬 압축 해제는 장애 복구 성능 시험이 아닙니다. 여러 적절한 복원 시점을 보관하고 실패한 백업을 확인하며 호스팅의 보관·복구 지원도 비교하세요.
실습 아카이브와 체크섬 절차는 Windows의 Git Bash GNU 도구로 로컬 검증되었습니다. Ubuntu 서버, 원격 SSH 전송, 인증서 복구나 Nginx 활성화까지 시험한 것은 아닙니다.
자주 묻는 질문
백업 검증을 위해 원본 사이트를 지워야 하나요?
삭제할 필요가 없습니다. 별도 빈 디렉터리와 매니페스트 검사로 사본을 확인하고 전체 서비스는 별도 대체 환경에서 테스트하세요.
체크섬이 맞으면 사이트 전체가 백업됐나요?
매니페스트에 있는 파일만 확인합니다. 누락된 데이터베이스, 비밀, 이미지나 DNS 설정은 찾아주지 않으므로 별도 목록과 기능 테스트가 필요합니다.
압축 파일은 암호화되어 있나요?
tar.gz는 압축 형식입니다. SCP의 전송 보호와 저장 파일의 보호는 별개이므로 데이터 성격에 맞게 계정 권한과 저장 암호화를 준비하세요.