같은 서버에만 백업하면 안 되는 이유

랜섬웨어는 서버 내부 파일 시스템 전체를 암호화 대상으로 삼기 때문에, 백업 파일이 같은 서버·같은 볼륨에 있으면 원본과 함께 암호화됩니다. 물리적으로 분리된 원격지(다른 서버, 클라우드 스토리지, 오프사이트)에 백업이 있어야 실제로 복구 수단으로 쓸 수 있습니다.

3-2-1 백업 원칙을 실무에 적용하는 방법

백업 설계의 기본 원칙은 3-2-1로 요약됩니다.

• 3개 이상의 복사본 — 원본 포함 최소 3벌
• 2개 이상의 다른 저장 매체 — 예: 로컬 디스크 + 클라우드 스토리지
• 1개 이상은 원격지(오프사이트) — 물리적으로 분리된 장소

중소 규모 서버라면 다음과 같은 최소 구성이 실무적으로 합리적입니다.

1. 서버 내부 일일 백업(빠른 복구용, 단기 보관)
2. 원격 스토리지로 매일 자동 전송(중기 보관)
3. 주 1회 별도 오프사이트 보관(장기·재해 대비)

DB·파일 백업 스크립트 예시

# 데이터베이스 덤프 + 압축
mysqldump -u backup_user -p"$DB_PASS" --single-transaction dbname \
  | gzip > /backup/db_$(date +%Y%m%d).sql.gz

# 원격 스토리지로 전송 (예: rsync)
rsync -avz /backup/ remote_user@remote_host:/remote_backup/

# 오래된 로컬 백업 정리 (30일 이상)
find /backup -name "*.sql.gz" -mtime +30 -delete

덤프 시 --single-transaction 옵션을 쓰면 백업 중 쓰기 작업이 있어도 일관된 시점의 데이터를 안전하게 가져올 수 있습니다.

백업 주기와 보관 기간 설계 기준

복구 드릴: 백업이 있다는 것과 복구가 된다는 것은 다르다

백업 파일이 정상적으로 쌓이고 있어도, 실제 복구 시점에 다음과 같은 문제로 실패하는 사례가 많습니다.

• 백업 스크립트가 며칠 전부터 조용히 실패하고 있었는데 알아채지 못함
• 백업 파일 자체는 있지만 복구 절차를 아무도 문서화하지 않아 시간이 오래 걸림
• DB 버전·문자셋 불일치로 복원 시 오류 발생

이를 막기 위해 분기별 복구 드릴을 정기 일정으로 잡아 실제로 백업 파일을 별도 서버에 복원해보고 데이터 정합성을 확인해야 합니다.

복구 드릴 체크리스트

1. 최근 백업 파일을 테스트 서버에 실제로 복원
2. 복원된 DB의 최근 게시글·회원 수가 원본과 일치하는지 확인
3. 복원에 걸린 실제 시간 측정(RTO 목표 대비 비교)
4. 복구 절차 문서를 실제 수행자가 그대로 따라할 수 있는지 검증
5. 결과를 기록해 다음 드릴과 비교

랜섬웨어 감염 발견 시 초기 대응 순서

1. 감염이 의심되는 서버를 즉시 네트워크에서 격리(백업 확산 방지)
2. 가장 최근의 정상 상태였던 원격 백업 시점 확인
3. 깨끗한 환경에서 신규 서버 구성 후 백업 복원
4. 복원 후 취약점(감염 경로로 추정되는 지점) 점검 없이 재오픈하지 않음

감염된 서버에서 바로 복구를 시도하면 같은 취약점으로 재감염될 위험이 있어, 원인 파악 전 재오픈은 피해야 합니다.

백업 접근 권한을 서비스 계정과 분리해야 하는 이유

실서비스 서버 계정이 탈취되면, 그 계정으로 접근 가능한 백업 저장소도 함께 삭제·암호화될 위험이 있습니다. 이를 막으려면 백업 저장소에는 쓰기 전용(append-only) 권한을 가진 별도 계정만 접근하게 하고, 실제 서버 계정에는 삭제 권한을 부여하지 않는 구조가 안전합니다.

클라우드 스토리지를 쓴다면 버전 관리와 삭제 지연(soft delete) 옵션을 함께 켜두면, 실수나 공격으로 파일이 지워져도 일정 기간 내 복구할 수 있는 여지가 남습니다.

실무 정리

백업은 쌓이고 있다는 사실보다 복구가 실제로 되는지 검증하는 것이 핵심입니다. 서버 이전이나 대규모 개편을 앞두고 있다면 무중단 이관과 함께 사전 백업·롤백 계획을 세우는 것을 권장합니다. 백업·복구 체계 점검이 필요하면 무료 견적요청으로 현재 서버 환경을 알려주세요.