TIL - 20260525

juni·2026년 5월 24일

TIL

목록 보기

361/468

0525 웹 마스터 실전 (9/N): 백업과 복구 전략

✅ 1. 백업이란 무엇인가?

백업(Backup)이란 서버 파일, 데이터베이스, 설정 파일, 이미지, 로그 등 중요한 데이터를 별도의 위치에 복사해두는 작업입니다.
웹사이트 운영에서 백업은 선택이 아니라 필수입니다.
장애, 해킹, 실수, 서버 삭제, DB 손상, 배포 실패 같은 상황이 발생했을 때 백업이 없으면 복구가 거의 불가능할 수 있습니다.

➕ 1-1. 백업이 중요한 이유

데이터 손실 방지
- 사용자의 상담 신청 내역, 주문 정보, 회원 정보, 관리자 데이터가 사라지는 것을 방지할 수 있습니다.
장애 복구 가능
- 서버 장애나 배포 실패가 발생했을 때 이전 정상 상태로 되돌릴 수 있습니다.
랜섬웨어/해킹 대응
- 공격자가 서버 파일이나 DB를 삭제하거나 암호화해도, 안전한 백업본이 있으면 복구할 수 있습니다.
운영 실수 대응
- 관리자 실수로 데이터를 삭제하거나, 잘못된 쿼리로 DB가 변경된 경우에도 백업이 있으면 복구 가능성이 생깁니다.

✅ 2. 백업해야 하는 주요 대상

➕ 2-1. 데이터베이스 백업

웹서비스에서 가장 중요한 백업 대상은 보통 데이터베이스(DB)입니다.
회원 정보, 주문 정보, 상담 신청 정보, 상품 정보, 게시글, 관리자 설정 등이 DB에 저장됩니다.
백업 대상 예시
- MySQL
- MariaDB
- PostgreSQL
- MongoDB
- Redis 일부 데이터
주의할 점
- DB 백업은 단순히 파일을 복사하는 것보다 DB 전용 백업 명령어를 사용하는 것이 안전합니다.
- 운영 중인 DB를 잘못 백업하면 데이터가 깨지거나 일부만 저장될 수 있습니다.

# MySQL / MariaDB 백업 예시
mysqldump -u root -p database_name > backup.sql

# PostgreSQL 백업 예시
pg_dump -U username database_name > backup.sql

➕ 2-2. 업로드 파일 백업

사용자가 업로드한 이미지, 첨부파일, 상품 이미지, 이벤트 배너 등도 반드시 백업해야 합니다.
DB만 백업하고 업로드 파일을 백업하지 않으면, 복구 후 데이터는 있어도 이미지나 파일이 깨질 수 있습니다.
백업 대상 예시
- 상품 이미지
- 이벤트 배너
- 첨부파일
- 프로필 이미지
- 계약서/신청서 파일
- 관리자에서 업로드한 리소스

# uploads 디렉토리 압축 백업 예시
tar -czvf uploads_backup.tar.gz /var/www/app/uploads

➕ 2-3. 서버 설정 파일 백업

서버 설정 파일은 장애 복구 시 매우 중요합니다.
코드와 DB만 있어도 서버 설정이 없으면 서비스가 바로 정상 동작하지 않을 수 있습니다.
백업 대상 예시
- Nginx 설정 파일
- Apache 설정 파일
- PM2 ecosystem 파일
- Docker Compose 파일
- SSL 인증서 설정
- crontab 스케줄
- 환경변수 예시 파일
- 배포 스크립트

# Nginx 설정 백업 예시
sudo cp /etc/nginx/sites-available/default ./nginx_default_backup.conf

# crontab 백업 예시
crontab -l > crontab_backup.txt

➕ 2-4. 소스코드 백업

소스코드는 GitHub, GitLab, Bitbucket 같은 원격 저장소에 관리하는 것이 기본입니다.
하지만 .env, 인증서, 서버 설정, 업로드 파일은 Git에 올리지 않는 경우가 많으므로 별도 관리가 필요합니다.
주의할 점
- 비밀번호, API 키, DB 접속 정보가 들어있는 .env 파일은 공개 저장소에 올리면 안 됩니다.
- 대신 .env.example 파일로 필요한 환경변수 목록만 문서화하는 것이 좋습니다.

# .env.example 예시
DATABASE_HOST=
DATABASE_PORT=
DATABASE_USER=
DATABASE_PASSWORD=
DATABASE_NAME=
JWT_SECRET=
AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=

✅ 3. 백업 저장 위치

백업은 “같은 서버 안에만” 저장하면 위험합니다.
서버 자체가 삭제되거나 디스크가 손상되면 백업 파일도 함께 사라질 수 있기 때문입니다.

➕ 3-1. 로컬 서버 백업

가장 간단한 방식은 서버 내부의 특정 디렉토리에 백업 파일을 저장하는 것입니다.
장점
- 구현이 간단함
- 복구 속도가 빠름
단점
- 서버 디스크 장애 시 백업도 같이 손실될 수 있음
- 해킹당하면 백업 파일도 삭제될 수 있음
- 장기 보관에는 적합하지 않음

mkdir -p /backup/db
mysqldump -u root -p database_name > /backup/db/backup_20260525.sql

➕ 3-2. 외부 스토리지 백업

실무에서는 백업 파일을 서버 외부에 저장하는 것이 안전합니다.
AWS를 사용한다면 S3에 백업하는 방식이 많이 사용됩니다.
외부 저장소 예시
- AWS S3
- Google Cloud Storage
- Azure Blob Storage
- NAS
- 별도 백업 서버

# AWS S3로 백업 파일 업로드 예시
aws s3 cp backup_20260525.sql s3://my-backup-bucket/db/

주의할 점
- 백업 버킷은 외부에 공개되면 안 됩니다.
- 접근 권한을 최소화해야 합니다.
- 중요한 백업 파일은 암호화해서 저장하는 것이 좋습니다.

✅ 4. 백업 주기와 보관 정책

백업은 한 번만 해두는 것이 아니라, 정해진 주기로 자동 실행되어야 합니다.
또한 백업 파일이 계속 쌓이면 용량 문제가 생기므로 보관 기간도 정해야 합니다.

➕ 4-1. 백업 주기

서비스 중요도에 따라 백업 주기는 달라집니다.
예시
- 상담 신청/주문 데이터: 매일 또는 몇 시간 단위
- 상품/이벤트 이미지: 변경 시 또는 매일
- 서버 설정 파일: 변경 시마다
- 소스코드: Git push 기준
- 로그 파일: 필요에 따라 일별 보관

➕ 4-2. 보관 정책

모든 백업 파일을 영구 보관하면 저장 공간과 비용이 증가합니다.
보통 최근 백업은 촘촘하게 보관하고, 오래된 백업은 간격을 넓혀 보관합니다.
보관 정책 예시
- 최근 7일: 매일 백업 보관
- 최근 4주: 주 1회 백업 보관
- 최근 6개월: 월 1회 백업 보관
- 그 이후: 필요 시 삭제

✅ 5. 자동 백업 구성

백업은 사람이 수동으로 하면 빼먹기 쉽습니다.
실무에서는 cron, 배포 스크립트, CI/CD, 클라우드 백업 기능 등을 사용해 자동화해야 합니다.

➕ 5-1. cron을 이용한 자동 백업

리눅스 서버에서는 cron을 사용해 정해진 시간마다 백업 명령어를 실행할 수 있습니다.

# crontab 편집
crontab -e

# 매일 새벽 3시에 DB 백업 실행
0 3 * * * /home/ubuntu/scripts/db_backup.sh

➕ 5-2. 백업 스크립트 예시

#!/bin/bash

DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backup/db"
DB_NAME="database_name"
DB_USER="root"

mkdir -p $BACKUP_DIR

mysqldump -u $DB_USER -p $DB_NAME > $BACKUP_DIR/db_backup_$DATE.sql

aws s3 cp $BACKUP_DIR/db_backup_$DATE.sql s3://my-backup-bucket/db/

find $BACKUP_DIR -type f -name "*.sql" -mtime +7 -delete

주의할 점
- 스크립트 안에 DB 비밀번호를 그대로 적는 것은 위험합니다.
- 백업 성공/실패 결과를 로그로 남겨야 합니다.
- 실패했을 때 알림을 받을 수 있어야 합니다.

✅ 6. 복구 전략

백업보다 더 중요한 것은 복구가 실제로 가능한지 확인하는 것입니다.
백업 파일이 있어도 복구 테스트를 해보지 않았다면, 장애 상황에서 사용할 수 없는 백업일 수 있습니다.

➕ 6-1. 복구 테스트

정기적으로 테스트 서버나 로컬 환경에서 백업 파일을 복구해봐야 합니다.

# MySQL 복구 예시
mysql -u root -p database_name < backup.sql

확인할 항목
- DB 테이블이 정상적으로 생성되는가?
- 데이터가 누락되지 않았는가?
- 한글이 깨지지 않는가?
- 이미지 경로가 정상적으로 연결되는가?
- 애플리케이션이 복구된 DB로 정상 실행되는가?

➕ 6-2. RTO와 RPO

복구 전략을 세울 때는 RTO와 RPO를 이해해야 합니다.
RTO(Recovery Time Objective)
- 장애가 발생했을 때 서비스를 몇 시간 안에 복구해야 하는지를 의미합니다.
- 예를 들어 RTO가 1시간이면, 장애 발생 후 1시간 안에 서비스를 복구하는 것이 목표입니다.
RPO(Recovery Point Objective)
- 장애가 발생했을 때 최대 얼마 전 데이터까지 손실을 허용할 수 있는지를 의미합니다.
- 예를 들어 RPO가 24시간이면, 최악의 경우 하루치 데이터 손실까지 허용한다는 뜻입니다.
실무 예시
- 상담 신청 데이터가 중요한 사이트라면 RPO를 짧게 잡아야 합니다.
- 하루에 한 번만 백업하면 최악의 경우 하루치 상담 신청 데이터가 사라질 수 있습니다.
- 매출과 직접 연결되는 서비스라면 백업 주기를 더 촘촘하게 가져가야 합니다.

✅ 7. AWS 환경에서의 백업 관리

➕ 7-1. S3 백업

AWS S3는 백업 파일을 저장하기 좋은 객체 스토리지입니다.
정적 파일, DB 덤프 파일, 로그 아카이브 등을 저장할 수 있습니다.
활용 방법
- DB 백업 파일 업로드
- 업로드 이미지 백업
- 로그 파일 장기 보관
- 버전 관리 활성화
- 수명 주기 정책으로 오래된 백업 자동 삭제

➕ 7-2. RDS 자동 백업

AWS RDS를 사용한다면 자동 백업과 스냅샷 기능을 활용할 수 있습니다.
RDS 자동 백업은 특정 시점으로 복구할 수 있어 운영 DB 관리에 유용합니다.
확인할 항목
- 자동 백업 활성화 여부
- 백업 보존 기간
- 스냅샷 생성 여부
- 복구 테스트 여부
- 백업 시간대가 서비스 피크 시간과 겹치지 않는지

➕ 7-3. EC2 스냅샷

EC2 서버의 EBS 볼륨을 스냅샷으로 백업할 수 있습니다.
서버 설정, 업로드 파일, 일부 애플리케이션 파일을 통째로 복구할 때 유용합니다.
주의할 점
- EC2 스냅샷만 믿고 DB 백업을 생략하면 안 됩니다.
- DB는 DB 전용 백업 또는 RDS 백업 기능을 함께 사용하는 것이 안전합니다.

✅ 8. 백업 보안

백업 파일에는 운영 DB 데이터, 개인정보, 관리자 정보, API 키 등이 포함될 수 있습니다.
따라서 백업 파일은 원본 데이터만큼이나 강하게 보호해야 합니다.

➕ 8-1. 백업 보안 수칙

백업 파일을 공개 URL에 두지 않는다.
S3 버킷 퍼블릭 액세스를 차단한다.
백업 접근 권한을 최소 인원에게만 부여한다.
개인정보가 포함된 백업은 암호화한다.
오래된 백업은 정책에 따라 삭제한다.
백업 다운로드 기록을 확인할 수 있게 한다.
운영 DB 백업 파일을 개인 PC에 무분별하게 저장하지 않는다.

➕ 8-2. 백업 파일 암호화 예시

# 백업 파일 압축 및 암호화 예시
zip -e db_backup_20260525.zip db_backup_20260525.sql

단순 zip 암호화보다 더 강한 보안이 필요하다면 GPG, KMS, S3 Server-Side Encryption 등을 고려해야 합니다.

✅ 9. 실무 백업 체크리스트

➕ 9-1. 매일 확인할 항목

DB 백업이 정상적으로 생성되었는가?
백업 파일 크기가 비정상적으로 작지 않은가?
S3 또는 외부 저장소 업로드가 성공했는가?
백업 스크립트 에러 로그가 없는가?
디스크 용량이 부족하지 않은가?

➕ 9-2. 매주 확인할 항목

백업 파일을 실제로 다운로드할 수 있는가?
최근 백업 파일로 테스트 복구가 가능한가?
오래된 백업이 정책대로 삭제되고 있는가?
백업 권한이 불필요하게 넓게 열려 있지 않은가?
백업 알림이 정상적으로 오고 있는가?

➕ 9-3. 배포 전 확인할 항목

DB 구조 변경 전 백업을 생성했는가?
대량 데이터 수정 전 백업을 생성했는가?
롤백 가능한 상태인가?
마이그레이션 실패 시 복구 절차가 있는가?
운영 DB에 직접 쿼리를 실행하기 전 백업 여부를 확인했는가?

📌 요약

백업은 장애, 해킹, 실수, 데이터 손상에 대비해 중요한 데이터를 별도 위치에 복사해두는 작업입니다.
웹사이트 운영에서는 DB, 업로드 파일, 서버 설정 파일, 소스코드, 환경변수 구조를 함께 관리해야 합니다.
백업 파일은 같은 서버 안에만 두지 말고, AWS S3 같은 외부 저장소에도 보관하는 것이 안전합니다.
백업은 수동보다 자동화가 중요하며, cron, 백업 스크립트, RDS 자동 백업, EC2 스냅샷 등을 활용할 수 있습니다.
백업만큼 중요한 것은 복구 테스트입니다. 실제로 복구해보지 않은 백업은 장애 상황에서 믿기 어렵습니다.
RTO는 복구까지 걸리는 목표 시간, RPO는 허용 가능한 데이터 손실 범위를 의미합니다.
백업 파일에는 민감한 정보가 포함될 수 있으므로 접근 권한, 암호화, 보관 기간을 철저히 관리해야 합니다.

juni

이전 포스트

TIL - 20260524

다음 포스트

TIL - 20260525

TIL

0525 웹 마스터 실전 (9/N): 백업과 복구 전략

✅ 1. 백업이란 무엇인가?

➕ 1-1. 백업이 중요한 이유

✅ 2. 백업해야 하는 주요 대상

➕ 2-1. 데이터베이스 백업

➕ 2-2. 업로드 파일 백업

➕ 2-3. 서버 설정 파일 백업

➕ 2-4. 소스코드 백업

✅ 3. 백업 저장 위치

➕ 3-1. 로컬 서버 백업

➕ 3-2. 외부 스토리지 백업

✅ 4. 백업 주기와 보관 정책

➕ 4-1. 백업 주기

➕ 4-2. 보관 정책

✅ 5. 자동 백업 구성

➕ 5-1. cron을 이용한 자동 백업

➕ 5-2. 백업 스크립트 예시

✅ 6. 복구 전략

➕ 6-1. 복구 테스트

➕ 6-2. RTO와 RPO

✅ 7. AWS 환경에서의 백업 관리

➕ 7-1. S3 백업

➕ 7-2. RDS 자동 백업

➕ 7-3. EC2 스냅샷

✅ 8. 백업 보안

➕ 8-1. 백업 보안 수칙

➕ 8-2. 백업 파일 암호화 예시

✅ 9. 실무 백업 체크리스트

➕ 9-1. 매일 확인할 항목

➕ 9-2. 매주 확인할 항목

➕ 9-3. 배포 전 확인할 항목

📌 요약

TIL - 20260524

TIL - 20260526

0개의 댓글