네이버 블로그나 티스토리 블로그를 쓰다가 개인 블로그를 직접 구축해보니, 가장 두려운 것이 데이터 손실이었다. (나는 나보다 네이버나 티스토리 선생님들의 전문성을 믿기 때문에...) 그래서, 맨날 '제대로 된 내 블로그 운영은 DB 백업 구축하고나서 해야지..' 하면서 미뤄왔는데, 지금에서야 완료했다.

지금부터 EC2에서 Docker Compose로 운영 중인 PostgreSQL의 자동 백업 시스템을 구축한 경험을 공유한다.

현재 환경

서버: AWS EC2 (Amazon Linux 2023, t4g.small)

컨테이너: Docker Compose로 관리

데이터베이스: PostgreSQL 15 (Docker 컨테이너)

스토리지: 로컬 + AWS S3

백업 시스템의 요구사항

(클로드 왈) 내가 구축할 백업 시스템은 다음과 같은 요구사항을 만족해야 한다.

자동화: 매일 정해진 시간에 자동 백업

이중화: 로컬과 클라우드(S3) 모두에 백업 파일 저장

공간 효율성: 압축을 통한 용량 절약

자동 정리: 오래된 백업 파일 자동 삭제

에러 처리: 백업 실패 시 로그 기록 및 복구 가능

백업 전략

1. 백업 주기 결정하기

개인 블로그의 특성상 데이터 변경이 빈번하지 않으므로 일일 백업으로 충분하다고 판단했다. 새벽 2시에 백업을 실행하여 서비스 영향을 최소화했다.

2. 보관 정책 설정하기

ec2 내 로컬 백업: 7일분 보관 (디스크 용량 절약)

S3 백업: 30일분 보관 (장기 복구 대비)

이전에 모니터링 툴인 Prometheus의 Metric들을 무기한 쌓았다가 메모리가 부족해서 도커 인스턴스가 종료된 적이 있다. 내가 쓰는 ec2 스펙인 t4g.small은 매우 작디작고 소듕하다는 것을 명심하고, ec2 내 로컬 백업은 7일로 제한했다.

3. 파일 구조 설계하기

/home/ec2-user/
├── backups/ # 로컬 백업 저장소
├── postgres_backup.sh # 백업 스크립트
└── bumang-blog-backend/ # 애플리케이션 코드

S3에는 backups/ 폴더 하위에 저장하여 기존 이미지 파일들과 분리한다.

백업 스크립트 작성

사실 원문을 다 보여줘도 괜찮을거 같긴한데 혹시나 보안적으로 백업스크립트를 다 보여주면 안 될거 같기도 해서.. 일단 어떤 차례로 실행되는지만 적어놓았다. 클로드 선생님이 이런 쉘스크립트 하나는 기가 막히게 짜주시니 대강 의사 코드 본다는 느낌으로 리딩하며 세부적으로 추가 세팅해달라 하면 잘 해주신다.

#!/bin/bash
set -euo pipefail # 에러 발생시 즉시 종료

# 환경 설정
CONTAINER_NAME="your-container-name"
S3_BUCKET="your-bucket-name"
BACKUP_DIR="/home/ec2-user/backups"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")

# 백업 실행
log "=== 백업 시작 ==="
log "백업 파일명: ${BACKUP_NAME}.sql.gz"
...

# PostgreSQL 연결 테스트
if ! docker exec $CONTAINER_NAME pg_isready -U $POSTGRES_USER -d $POSTGRES_DB > /dev/null 2>&1; then
log "ERROR: PostgreSQL 연결 실패"
exit 1
fi

# 백업 실행
log "PostgreSQL 백업 중..."
if docker exec $CONTAINER_NAME pg_dump -U $POSTGRES_USER $POSTGRES_DB | gzip > ${BACKUP_DIR}/${BACKUP_NAME}.sql.gz; then
...

# 오래된 파일 정리
log "오래된 백업 파일 정리 중..."
DELETED_FILES=$(find $BACKUP_DIR -name "blog_backup_*.sql.gz" -mtime +$RETENTION_DAYS -print)
...

# 백업 파일 목록
BACKUP_COUNT=$(find $BACKUP_DIR -name "blog_backup_*.sql.gz" | wc -l)
log "현재 백업 파일 개수: $BACKUP_COUNT"
...

log "=== 백업 완료 ==="

백업 실행 과정

사전 검증: Docker 컨테이너 상태 및 PostgreSQL 연결 확인

데이터 덤프:pg_dump를 사용한 SQL 덤프 생성

압축: gzip을 사용한 파일 압축

S3 업로드: AWS CLI를 사용한 클라우드 업로드

정리: 오래된 백업 파일 자동 삭제

에러 처리

cleanup() {
if [[ -f "${BACKUP_DIR}/${BACKUP_NAME}.sql" ]]; then
rm -f "${BACKUP_DIR}/${BACKUP_NAME}.sql"
log "임시 파일 정리: ${BACKUP_NAME}.sql"
fi
}
trap cleanup ERR

백업 과정에서 오류가 발생하면 임시 파일을 정리하고 로그를 남긴다.

이 작업을 하며 만났던 문제들

1. 메모리 부족 문제

t4g.small 인스턴스(2GB RAM)에서 여러 Docker 서비스를 운영하다 보니 OOM(Out of Memory) 킬이 발생했다. t4g.small에 지금 도커로 말아올린 컨테이너가 8개다.

로깅 및 모니터링: `prometheus`, `grafana`, `node-exporter`, `postgres-exporter`

백엔드 앱 및 DB: `app(Nest.js)`, `db(postgresql)`

리버스 프록시 및 인증서: `nginx`, `certbot`

그 중 prometheus 이놈을 15초마다 메트릭을 계속 쏘면서 90일 동안 로깅을 하도록 했더니... OOM이 났던 것이다.

해결책:

각 컨테이너에 메모리 제한 설정

Prometheus 메트릭 수집 간격을 300초로 조정

메트릭 보관 기간을 7일로 단축

deploy:
resources:
limits:
memory: 200M
reservations:
memory: 100M

2. AWS IAM 권한 설정

처음에는 S3 업로드만 가능한 권한으로 설정되어 있어서 파일 목록 조회가 실패했다.

글 작성 시 이미지 업로드하면 반환되는 url을 통해 접근했지 실제로 s3내 파일 목록 조회할 일은 없어서 추가하지 않았던 것이다.

해결책:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:DeleteObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
]
}
]
}

s3:ListBucket 권한을 추가하여 파일 목록 조회 및 정리 기능을 구현했다.

3. crontab 설치

Amazon Linux 2023에는 기본적으로 cron이 설치되어 있지 않았다. 말 그대로 ec2 내에서 cron잡을 하기위해 쓴다.

sudo yum install -y cronie
sudo systemctl enable crond
sudo systemctl start crond

자동화 설정 과정

cron 스케줄링

crontab -e

# 매일 새벽 2시 백업 실행
0 2 * * * /home/ec2-user/postgres_backup.sh >> /var/log/backup.log 2>&1

로그 관리

백업 실행 결과를 /var/log/backup.log에 기록하여 문제 발생 시 추적이 가능하다.

log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

백업 검증 및 복구

백업 파일 확인

# 로컬 백업 파일 목록
ls -la ~/backups/

# S3 백업 파일 목록
aws s3 ls s3://bucket-name/backups/

복구 과정

# S3에서 백업 파일 다운로드
aws s3 cp s3://bucket-name/backups/backup_file.sql.gz ./

# 압축 해제
gunzip backup_file.sql.gz

# 데이터베이스 복구 (주의: 기존 데이터 덮어쓰임)
docker exec -i container_name psql -U username -d database < backup_file.sql

성능 및 용량 최적화

압축 효과

PostgreSQL 덤프 파일을 gzip으로 압축하면 보통 80-90% 용량을 절약할 수 있다고 한다. 클로드 선생님의 권고로 압축까지 진행했다. 그 결과 내 경우 8KB 정도의 압축 파일이 생성된다.

모니터링 최적화

개인 블로그의 특성을 고려하여 모니터링 설정을 최적화했다:

메트릭 수집 간격: 15초 → 300초 (5분)

데이터 보관 기간: 15일 → 7일

메모리 제한: 각 서비스별 제한 설정

후기

나는 나를 믿기보단 컴퓨터를 믿는다. 매일 새벽 2시 백업 설정이 돌아가게 해놓고, 2시 경에 들어가서 확인해보니 제대로 돌아가고 있단 것을 봤을 때의 편안함이란... 역시 백업은 중요하다.