클라우드 백업과 3-2-1 규칙: 실전 가이드

백업은 왜 실패하는가 (그리고 3-2-1 규칙이 이를 어떻게 해결하는가)

대부분의 데이터 손실 사고는 예방 가능한 원인에서 비롯됩니다. 실수로 실행한 삭제 명령, 전원 장애 이후의 데이터베이스 손상, 랜섬웨어 암호화, 또는 조용히 진행되는 디스크 고장 등이 그렇습니다. 공통점은 백업이 아예 존재하지 않거나, 동일한 시스템에 보관되어 있거나, 한 번도 테스트된 적이 없다는 것입니다.

3-2-1 규칙은 간결한 프레임워크를 제공합니다.

• 데이터 사본 3개 (원본 + 백업 2개)
• 서로 다른 저장 매체 또는 기술 2가지
• 오프사이트(off-site)에 보관하는 사본 1개

이 방식은 하드웨어 장애, 사람의 실수, 멀웨어 등 어떤 단일 장애도 모든 사본을 동시에 없애 버릴 수 없도록 보장합니다.

3-2-1을 실제 인프라에 매핑하기

웹 애플리케이션이나 이메일 워크로드를 위한 실전 구현 예시는 다음과 같습니다.

이 구성은 세 가지 숫자를 모두 충족합니다. 서로 다른 사본 3개, 서로 다른 기술 2가지, 그리고 지리적으로 분리된 위치 1곳입니다.

1단계: 스냅샷 — 빠르지만 그것만으로는 부족하다

스냅샷은 특정 시점에 서버 볼륨 전체를 캡처하여, 배포 실패나 잘못된 업그레이드로부터 몇 분 안에 신속하게 복구할 수 있게 해 줍니다. 그러나 기본 공급자에 함께 저장된 스냅샷은 백업 #2에 해당할 뿐, 오프사이트 보호 수단은 아닙니다. 스냅샷은 실수를 막아 주지만, 계정 수준이나 리전 수준의 사고로부터는 보호해 주지 못합니다.

2단계: 애플리케이션 정합성을 갖춘 데이터베이스 덤프

스냅샷은 크래시 정합성(crash-consistency)은 제공하지만, 애플리케이션 정합성(application-consistency)까지 보장하지는 않습니다. 데이터베이스는 서버 전체를 롤백하지 않고도 개별 테이블을 복원하려면 적절한 논리적 덤프가 필요합니다.

MySQL/MariaDB의 경우:

mysqldump --single-transaction --quick --routines --triggers \
  --all-databases | gzip > /var/backups/db-$(date +%F).sql.gz

PostgreSQL의 경우:

pg_dumpall -U postgres | gzip > /var/backups/pg-$(date +%F).sql.gz

--single-transaction 플래그는 쓰기를 차단하지 않으면서 정합성 있는 InnoDB 스냅샷을 보장합니다. 이러한 덤프는 오프사이트 백업 프로세스가 접근할 디렉터리에 저장하세요.

3단계: restic과 오브젝트 스토리지를 이용한 오프사이트 사본

이 구성 요소가 진정한 복원력을 만들어 냅니다. restic은 중복 제거(deduplication), 압축, 그리고 데이터가 서버를 떠나기 전에 수행되는 클라이언트 측 암호화를 갖춘 오픈소스 백업 도구입니다. 스토리지 공급자는 결코 평문 데이터에 접근하지 못합니다.

설치 및 초기화:

# Install restic (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y restic

# Point restic at your in-Kingdom object storage bucket
export RESTIC_REPOSITORY="s3:https://objects.example-region.com/my-backup-bucket"
export AWS_ACCESS_KEY_ID="<your-access-key>"
export AWS_SECRET_ACCESS_KEY="<your-secret-key>"
export RESTIC_PASSWORD="<a-long-random-passphrase>"

# Initialize the repository once
restic init

최초 백업 실행:

restic backup /var/www /etc /var/backups

이후의 백업은 변경된 블록만 전송하므로 빠르고 비용 효율적입니다.

자동화 및 프루닝(prune)

저장소가 무한정 커지는 것을 방지하기 위해 보존 정책을 적용한 일일 cron 작업을 만드세요.

# /etc/cron.d/restic-backup
30 2 * * * root /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
# /usr/local/bin/restic-backup.sh
set -euo pipefail
source /root/.restic-env

restic backup /var/www /etc /var/backups --tag daily
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

이 정책은 일일 복원 시점 7개, 주간 4개, 월간 6개를 유지하여 복구 세분성과 스토리지 비용 사이의 균형을 맞춥니다.

4단계: 랜섬웨어에 대비해 강화하기

공격자들은 점점 더 백업 저장소를 표적으로 삼고 있습니다. 다음은 두 가지 실용적인 방어책입니다.

• 자격 증명 분리: 오브젝트 스토리지 접근 권한을 추가(append)/쓰기 전용으로 구성하여 삭제를 허용하지 않도록 하세요. restic prune은 보다 안전한 환경에서 실행합니다.
• 불변성(Immutability) / 오브젝트 락(object lock): 지원되는 경우 WORM(write-once-read-many, 한 번 쓰면 여러 번 읽기) 보존을 활성화하여, 만료 전 덮어쓰기나 삭제를 방지하세요.

이러한 조치는 오프사이트 사본을 진정한 최후의 방어선 보호 수단으로 탈바꿈시킵니다.

5단계: 복원 테스트 — 모두가 건너뛰는 단계

테스트되지 않은 백업은 계획이 아니라 막연한 기대일 뿐입니다. 정기적인 복원 훈련을 일정에 포함하세요.

# List available snapshots
restic snapshots

# Restore a specific snapshot into a scratch directory
restic restore <snapshot-id> --target /tmp/restore-test

# Verify repository integrity
restic check

복원된 데이터베이스가 실제로 임포트되는지, 그리고 애플리케이션이 정상적으로 구동되는지 확인하세요. 매월 테스트하도록 캘린더에 알림을 설정해 두면, 실제 비상 상황에서 백업 실패를 뒤늦게 발견하는 일을 막을 수 있습니다.

인-킹덤(국내) 저장이 중요한 이유

사우디아라비아에 있는 사람들의 개인 데이터를 처리하는 조직은, 적법한 국외 이전 근거가 없는 한 백업을 인-킹덤(국내)에 저장하도록 하는 규제상의 기대를 받게 됩니다. 오프사이트 사본도 이러한 프레임워크 하에서는 개인 데이터에 해당합니다. 국내 클라우드 공급자는 인-킹덤 데이터 거주성(residency), S3 호환 오브젝트 스토리지, 그리고 사고 발생 시 모국어 지원을 제공합니다.

시작하기

클라우드 서버, 스냅샷, 그리고 인-킹덤 오브젝트 스토리지로 구성된 완전한 3-2-1 구현은, 적절한 계획만 있으면 몇 분 만에 배포할 수 있습니다.