백업 및 복구 전략 완벽 가이드

메일 서버와 중요 데이터를 안전하게 보호하는 백업 전략을 알아봅니다. Maildir 백업부터 증분 백업, 오프사이트 백업, 그리고 재해 복구 계획까지 실무에서 바로 적용할 수 있는 내용을 담았습니다.

1. 백업 대상 식별

어느 날 김개발 씨의 회사에서 서버 장애가 발생했습니다. 다행히 큰 문제는 아니었지만, 팀장님이 긴급 회의를 소집했습니다.

"우리 백업 체계가 제대로 되어 있는 건가요? 정확히 뭘 백업하고 있죠?"

백업 대상 식별은 말 그대로 "무엇을 백업할 것인가"를 정하는 첫 번째 단계입니다. 마치 이사할 때 짐을 싸기 전에 무엇을 가져갈지 목록을 만드는 것과 같습니다.

메일 데이터, 설정 파일, 인증서 등 복구에 필요한 모든 항목을 빠짐없이 파악해야 합니다.

다음 코드를 살펴봅시다.

#!/bin/bash
# 백업 대상 디렉토리 정의
BACKUP_TARGETS=(
    "/var/vmail"              # 메일 데이터 (Maildir)
    "/etc/postfix"            # Postfix 설정
    "/etc/dovecot"            # Dovecot 설정
    "/etc/ssl/private"        # SSL 인증서 개인키
    "/etc/letsencrypt"        # Let's Encrypt 인증서
    "/etc/opendkim"           # DKIM 키
    "/var/lib/mysql"          # 메일 계정 DB
)

# 백업 대상 존재 여부 확인
for target in "${BACKUP_TARGETS[@]}"; do
    if [ -d "$target" ]; then
        echo "[OK] $target exists"
    else
        echo "[WARN] $target not found"
    fi
done

김개발 씨는 신입 시스템 관리자입니다. 팀장님의 질문에 선뜻 대답하지 못한 자신이 부끄러웠습니다.

옆자리의 박시니어 씨가 조용히 다가와 말했습니다. "백업의 첫 번째 원칙을 아세요?

뭘 백업해야 하는지 정확히 아는 거예요." 그렇다면 백업 대상 식별이란 정확히 무엇일까요? 쉽게 비유하자면, 이사할 때를 떠올려 보세요.

짐을 싸기 전에 먼저 무엇을 가져갈지 목록을 만들지 않나요? 귀중품, 가전제품, 옷가지 등을 하나하나 체크하면서요.

백업도 마찬가지입니다. 어떤 데이터가 중요하고, 어떤 파일이 복구에 필수적인지 먼저 파악해야 합니다.

메일 서버를 운영한다고 가정해봅시다. 가장 중요한 것은 당연히 메일 데이터입니다.

사용자들의 소중한 이메일이 담겨 있으니까요. 보통 /var/vmail이나 /home/vmail 같은 경로에 저장됩니다.

두 번째로 중요한 것은 설정 파일입니다. Postfix의 main.cf, Dovecot의 dovecot.conf 같은 파일들이죠.

이 설정 파일들이 없으면 서버를 처음부터 다시 구성해야 합니다. 수십 개의 옵션을 일일이 다시 설정한다고 생각해보세요.

끔찍하지 않나요? 세 번째는 SSL 인증서입니다.

요즘 메일 서버는 TLS 암호화가 필수입니다. 인증서가 없으면 이메일 송수신 자체가 안 될 수 있습니다.

Let's Encrypt를 사용한다면 /etc/letsencrypt 디렉토리 전체를 백업해야 합니다. 네 번째는 DKIM 키입니다.

이메일 인증에 사용되는 키인데, 이게 없으면 발송한 메일이 스팸으로 처리될 수 있습니다. /etc/opendkim 디렉토리에 보통 저장됩니다.

마지막으로 데이터베이스입니다. 메일 계정 정보, 별칭, 도메인 설정 등이 MySQL이나 PostgreSQL에 저장되어 있다면 이것도 백업 대상입니다.

위 코드를 살펴보면, 먼저 BACKUP_TARGETS 배열에 백업할 디렉토리들을 정의합니다. 그리고 for 루프를 돌면서 각 디렉토리가 실제로 존재하는지 확인합니다.

이렇게 하면 백업 전에 누락된 항목이 없는지 미리 체크할 수 있습니다. 실무에서는 이 목록을 문서화해두는 것이 좋습니다.

새로운 서비스가 추가될 때마다 백업 대상도 업데이트해야 하니까요. 박시니어 씨는 이렇게 덧붙였습니다.

"백업 대상 목록은 살아있는 문서예요. 시스템이 바뀔 때마다 함께 업데이트해야 합니다." 김개발 씨는 고개를 끄덕였습니다.

백업의 첫걸음은 거창한 기술이 아니라, 무엇이 중요한지 정확히 아는 것이었습니다.

실전 팁

💡 - 백업 대상 목록은 반드시 문서화하고 정기적으로 업데이트하세요

로그 파일은 보통 백업 대상에서 제외하지만, 감사 로그는 별도로 보관하세요
설정 파일 변경 시 버전 관리 시스템(Git)을 활용하면 더욱 안전합니다

2. Maildir 백업 전략

김개발 씨가 백업 대상을 정리하고 나니, 다음 질문이 떠올랐습니다. "메일 데이터가 가장 크고 중요한데, 이걸 어떻게 효율적으로 백업하지?" 박시니어 씨가 웃으며 대답했습니다.

"Maildir 형식의 장점을 알면 답이 보여요."

Maildir은 각 이메일을 개별 파일로 저장하는 메일 저장 형식입니다. 마치 서류철에 문서를 한 장씩 따로 보관하는 것과 같습니다.

이 구조 덕분에 파일 단위로 백업이 가능하고, 손상된 메일 하나가 전체에 영향을 주지 않습니다.

다음 코드를 살펴봅시다.

#!/bin/bash
# Maildir 백업 스크립트
MAIL_DIR="/var/vmail"
BACKUP_DIR="/backup/maildir"
DATE=$(date +%Y%m%d)

# 백업 디렉토리 생성
mkdir -p "$BACKUP_DIR/$DATE"

# rsync로 Maildir 백업 (삭제된 파일은 유지)
rsync -avz --progress \
    --exclude="dovecot.index*" \
    --exclude="dovecot-uidlist" \
    "$MAIL_DIR/" "$BACKUP_DIR/$DATE/"

# 백업 결과 확인
echo "Backup completed: $(du -sh $BACKUP_DIR/$DATE)"

# 30일 이상 된 백업 삭제
find "$BACKUP_DIR" -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;

박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "메일 저장 방식에는 크게 두 가지가 있어요.

mbox와 Maildir이죠." mbox 형식은 모든 이메일을 하나의 큰 파일에 저장합니다. 마치 두꺼운 노트 한 권에 모든 메모를 적는 것과 같죠.

간단해 보이지만, 문제가 있습니다. 파일이 손상되면 모든 메일을 잃을 수 있고, 백업 중에 새 메일이 오면 충돌이 발생할 수 있습니다.

반면 Maildir은 각 이메일을 별도의 파일로 저장합니다. 마치 서류철에 문서를 한 장씩 따로 보관하는 것처럼요.

cur, new, tmp 세 개의 디렉토리로 구성되어 있습니다. new 디렉토리에는 아직 읽지 않은 새 메일이 들어옵니다.

사용자가 메일을 읽으면 cur 디렉토리로 이동합니다. tmp는 메일을 임시로 저장하는 공간입니다.

이 구조 덕분에 파일 잠금 없이도 안전하게 메일을 처리할 수 있습니다. 위 코드를 살펴봅시다.

rsync 명령어를 사용하는데, 이것이 핵심입니다. rsync는 변경된 파일만 복사하므로 전체 복사보다 훨씬 빠릅니다.

-a 옵션은 아카이브 모드로 권한과 타임스탬프를 보존합니다. -v는 상세 출력, -z는 전송 중 압축을 의미합니다.

주목할 점은 exclude 옵션입니다. dovecot.index와 dovecot-uidlist는 Dovecot이 자동으로 생성하는 인덱스 파일입니다.

이 파일들은 백업할 필요가 없습니다. 복구 후 Dovecot이 알아서 다시 만들어주니까요.

오히려 백업에 포함하면 용량만 차지하고 복구 시 문제가 될 수 있습니다. 마지막 줄의 find 명령어는 30일이 지난 오래된 백업을 자동으로 삭제합니다.

백업 용량이 무한정 늘어나는 것을 방지하는 중요한 부분입니다. 실무에서 주의할 점이 있습니다.

백업 중에도 메일 서버는 계속 동작합니다. Maildir 형식이라 대부분 문제가 없지만, 매우 큰 첨부 파일을 받는 중이라면 해당 파일이 불완전하게 백업될 수 있습니다.

이런 경우를 대비해 백업을 트래픽이 적은 새벽 시간에 실행하는 것이 좋습니다. 김개발 씨가 질문했습니다.

"그럼 매일 전체를 복사하는 건가요?" 박시니어 씨가 고개를 저었습니다. "아니요, 그건 증분 백업으로 해결합니다.

다음에 알려드릴게요."

실전 팁

💡 - rsync의 --delete 옵션은 신중하게 사용하세요. 실수로 원본을 삭제하면 백업에서도 사라집니다

백업 실행 시간은 메일 트래픽이 적은 새벽 시간대를 권장합니다
백업 완료 후 파일 개수와 용량을 로그로 남겨 이상 징후를 감지하세요

3. 증분 백업 구현

다음 날, 김개발 씨가 백업 용량 보고서를 보고 깜짝 놀랐습니다. "100GB 메일 데이터를 매일 백업하면 한 달에 3TB가 넘잖아요!" 박시니어 씨가 웃으며 말했습니다.

"그래서 증분 백업이 필요한 거예요."

증분 백업은 이전 백업 이후 변경된 파일만 백업하는 방식입니다. 마치 일기를 쓸 때 이미 쓴 부분은 그대로 두고 오늘 있었던 일만 추가로 적는 것과 같습니다.

저장 공간을 크게 절약하면서도 완전한 복구가 가능합니다.

다음 코드를 살펴봅시다.

#!/bin/bash
# 증분 백업 스크립트 (하드링크 활용)
MAIL_DIR="/var/vmail"
BACKUP_BASE="/backup/maildir"
DATE=$(date +%Y%m%d_%H%M%S)
LATEST="$BACKUP_BASE/latest"

# 이전 백업이 있으면 하드링크로 증분 백업
if [ -d "$LATEST" ]; then
    rsync -avz --delete \
        --link-dest="$LATEST" \
        --exclude="dovecot.index*" \
        "$MAIL_DIR/" "$BACKUP_BASE/$DATE/"
else
    # 첫 백업은 전체 백업
    rsync -avz "$MAIL_DIR/" "$BACKUP_BASE/$DATE/"
fi

# latest 심볼릭 링크 업데이트
rm -f "$LATEST"
ln -s "$BACKUP_BASE/$DATE" "$LATEST"

echo "Incremental backup completed: $DATE"

김개발 씨는 증분 백업이라는 말은 들어봤지만, 정확히 어떻게 동작하는지 몰랐습니다. 박시니어 씨가 설명을 시작했습니다.

"백업에는 세 가지 종류가 있어요. 전체 백업, 차등 백업, 증분 백업입니다." 전체 백업은 말 그대로 모든 데이터를 매번 복사합니다.

단순하지만 시간과 공간이 많이 필요합니다. 차등 백업은 마지막 전체 백업 이후 변경된 모든 파일을 백업합니다.

증분 백업은 마지막 백업(전체든 증분이든) 이후 변경된 파일만 백업합니다. 비유를 들어볼까요?

전체 백업은 매일 일기장을 처음부터 끝까지 다시 베껴 쓰는 것입니다. 증분 백업은 오늘 새로 쓴 페이지만 복사하는 것이죠.

어느 쪽이 효율적인지는 명확합니다. 위 코드의 핵심은 --link-dest 옵션입니다.

이 옵션은 rsync의 마법 같은 기능입니다. 변경되지 않은 파일은 복사하지 않고 이전 백업의 파일에 하드링크를 생성합니다.

하드링크가 뭘까요? 파일 시스템에서 같은 데이터를 가리키는 또 다른 이름입니다.

실제 데이터는 하나인데 이름이 여러 개인 셈이죠. 덕분에 디스크 공간을 추가로 사용하지 않으면서도, 각 백업 디렉토리는 완전한 스냅샷처럼 보입니다.

예를 들어 100GB 메일 데이터 중 오늘 1GB만 변경되었다고 합시다. 증분 백업을 실행하면 실제로는 1GB만 새로 저장됩니다.

하지만 백업 디렉토리를 보면 100GB 전체가 있는 것처럼 보입니다. 99GB는 하드링크로 이전 백업을 가리키고 있기 때문입니다.

코드에서 LATEST 변수는 가장 최근 백업을 가리키는 심볼릭 링크입니다. 새 백업이 완료되면 이 링크를 업데이트합니다.

다음 백업 시 이 링크를 참조하여 증분 백업을 수행합니다. 주의할 점이 있습니다.

--delete 옵션을 사용하면 원본에서 삭제된 파일이 새 백업에도 반영됩니다. 하지만 이전 백업에는 그 파일이 여전히 남아있습니다.

하드링크 덕분이죠. 실수로 파일을 삭제해도 이전 백업에서 복구할 수 있습니다.

김개발 씨가 감탄했습니다. "하드링크라니, 정말 똑똑한 방법이네요!" 박시니어 씨가 덧붙였습니다.

"대신 하드링크는 같은 파일 시스템 내에서만 동작해요. 다른 디스크로 백업하려면 다른 방법이 필요합니다."

실전 팁

💡 - 하드링크 기반 증분 백업은 반드시 같은 파일 시스템 내에서 사용하세요

주 1회 전체 백업 + 매일 증분 백업 조합이 일반적입니다
백업 보관 정책을 명확히 정하고 자동 삭제 스크립트를 함께 운영하세요

4. 오프사이트 백업

어느 날 김개발 씨가 뉴스를 보다가 깜짝 놀랐습니다. 모 회사 데이터센터에 화재가 발생해서 서버와 백업 디스크가 모두 소실되었다는 기사였습니다.

"우리 백업도 같은 서버실에 있는데..." 박시니어 씨가 진지하게 말했습니다. "그래서 오프사이트 백업이 필수입니다."

오프사이트 백업은 물리적으로 다른 위치에 백업을 저장하는 것입니다. 마치 중요한 문서 사본을 집과 사무실 두 곳에 보관하는 것과 같습니다.

서버실에 재해가 발생해도 원격지의 백업으로 복구할 수 있습니다.

다음 코드를 살펴봅시다.

#!/bin/bash
# S3 오프사이트 백업 스크립트
BACKUP_DIR="/backup/maildir/latest"
S3_BUCKET="s3://company-backup/mailserver"
DATE=$(date +%Y%m%d)

# AWS CLI로 S3 동기화 (변경된 파일만 업로드)
aws s3 sync "$BACKUP_DIR" "$S3_BUCKET/$DATE/" \
    --storage-class STANDARD_IA \
    --exclude "*.log" \
    --delete

# 90일 이상 된 S3 백업 삭제 (수명 주기 정책 권장)
aws s3 ls "$S3_BUCKET/" | while read -r line; do
    backup_date=$(echo "$line" | awk '{print $2}' | tr -d '/')
    if [[ "$backup_date" < $(date -d '90 days ago' +%Y%m%d) ]]; then
        aws s3 rm "$S3_BUCKET/$backup_date" --recursive
    fi
done

echo "Offsite backup to S3 completed"

박시니어 씨가 말을 이었습니다. "백업의 황금률을 아세요?

3-2-1 규칙이라고 합니다." 3-2-1 규칙은 이렇습니다. 최소 3개의 데이터 사본을 유지하고, 2가지 다른 저장 매체를 사용하며, 1개는 반드시 오프사이트에 보관합니다.

이 규칙을 지키면 대부분의 재해 상황에서 데이터를 복구할 수 있습니다. 오프사이트 백업의 대표적인 방법은 클라우드 스토리지입니다.

AWS S3, Google Cloud Storage, Azure Blob Storage 등이 있죠. 그중에서도 AWS S3는 99.999999999%의 내구성을 자랑합니다.

숫자가 너무 길어서 실감이 안 나시죠? 1억 개의 파일을 저장해도 10만 년에 하나 정도만 손실될 확률입니다.

위 코드를 살펴봅시다. aws s3 sync 명령어는 로컬과 S3 간에 변경된 파일만 동기화합니다.

rsync와 비슷한 개념이죠. --storage-class STANDARD_IA는 비용 절약을 위한 옵션입니다.

IA는 Infrequent Access의 약자로, 자주 접근하지 않는 데이터에 적합합니다. 백업 데이터가 딱 이 경우에 해당하죠.

클라우드 말고 다른 방법도 있습니다. rsync over SSH를 사용하면 다른 서버로 백업할 수 있습니다.

bash rsync -avz -e ssh /backup/maildir/ user@remote-server:/backup/ 이 방법은 직접 관리하는 서버가 여러 대 있을 때 유용합니다. 클라우드 비용도 절약할 수 있고요.

다만 원격 서버도 관리해야 하는 부담이 있습니다. 실무에서 주의할 점이 있습니다.

오프사이트 백업은 네트워크를 통해 전송되므로 암호화가 필수입니다. S3는 기본적으로 전송 중 암호화(TLS)를 지원하고, 저장 시 암호화(SSE-S3, SSE-KMS)도 설정할 수 있습니다.

또한 대역폭을 고려해야 합니다. 첫 번째 전체 백업은 데이터 양이 많아 시간이 오래 걸릴 수 있습니다.

100GB를 100Mbps 회선으로 전송하면 약 2시간이 걸립니다. 업무 시간을 피해 실행하거나, 대역폭 제한 옵션을 사용하세요.

김개발 씨가 물었습니다. "S3 비용은 어느 정도인가요?" 박시니어 씨가 대답했습니다.

"STANDARD_IA 기준으로 GB당 월 0.0125달러 정도입니다. 100GB면 한 달에 1.25달러예요.

데이터의 가치를 생각하면 정말 저렴하죠."

실전 팁

💡 - S3 버킷에 버전 관리를 활성화하면 실수로 덮어쓴 파일도 복구할 수 있습니다

S3 Glacier를 사용하면 장기 보관 비용을 더욱 절약할 수 있습니다
오프사이트 전송 시 반드시 암호화를 사용하고, 접근 권한을 최소화하세요

5. 복구 테스트 절차

한 달 뒤, 팀 회의에서 팀장님이 질문했습니다. "백업은 잘 되고 있는 것 같은데, 복구는 해봤나요?" 김개발 씨와 박시니어 씨가 서로 눈치를 봤습니다.

백업만 하고 복구 테스트는 한 번도 안 해본 것이었습니다.

복구 테스트는 백업이 실제로 작동하는지 검증하는 과정입니다. 마치 소화기가 제대로 작동하는지 정기적으로 점검하는 것과 같습니다.

테스트하지 않은 백업은 백업이 아닙니다. 실제 복구 상황에서 문제를 발견하면 이미 늦습니다.

다음 코드를 살펴봅시다.

#!/bin/bash
# 복구 테스트 스크립트
TEST_DIR="/tmp/recovery_test"
BACKUP_SOURCE="/backup/maildir/latest"
TEST_USER="testuser@example.com"

# 테스트 환경 준비
rm -rf "$TEST_DIR"
mkdir -p "$TEST_DIR"

# 특정 사용자 메일 복구 테스트
echo "Restoring $TEST_USER mailbox..."
rsync -avz "$BACKUP_SOURCE/example.com/$TEST_USER/" "$TEST_DIR/"

# 복구된 데이터 검증
MAIL_COUNT=$(find "$TEST_DIR" -type f -name "*." | wc -l)
echo "Recovered mail count: $MAIL_COUNT"

# 무결성 검사 (파일 손상 확인)
CORRUPTED=0
for mail in "$TEST_DIR/cur/"*; do
    if ! head -1 "$mail" | grep -q "^From:\|^Return-Path:\|^Delivered-To:"; then
        echo "Possibly corrupted: $mail"
        ((CORRUPTED++))
    fi
done

echo "Test completed. Corrupted files: $CORRUPTED"
rm -rf "$TEST_DIR"

박시니어 씨가 무거운 목소리로 말했습니다. "업계에서 유명한 이야기가 있어요.

모 회사가 10년간 백업을 성실히 했는데, 정작 복구가 필요할 때 테이프가 모두 불량이었다는 거죠. 백업 시스템은 잘 돌아갔지만, 테이프 드라이브가 고장 난 줄 몰랐던 겁니다." 충격적인 이야기지만, 생각보다 흔한 일입니다.

테스트하지 않은 백업은 백업이 아닙니다. 이 문장을 꼭 기억하세요. 복구 테스트는 크게 세 가지를 검증합니다.

첫째, 백업 데이터의 완전성. 모든 파일이 제대로 백업되었는지 확인합니다.

둘째, 데이터 무결성. 파일이 손상되지 않았는지 검사합니다.

셋째, 복구 절차의 유효성. 실제로 복구가 가능한지 확인합니다.

위 코드는 간단한 복구 테스트 스크립트입니다. 먼저 임시 디렉토리를 만들고, 백업에서 특정 사용자의 메일함을 복구합니다.

그리고 복구된 메일 파일의 개수를 세고, 각 파일의 헤더를 검사하여 손상 여부를 확인합니다. 더 철저한 테스트를 원한다면, 별도의 테스트 서버를 준비하는 것이 좋습니다.

백업에서 전체 메일 시스템을 복구하고, 실제로 메일을 주고받아 보는 것이죠. 이렇게 하면 설정 파일의 정확성까지 검증할 수 있습니다.

복구 테스트 주기는 어떻게 정할까요? 최소한 월 1회는 자동화된 테스트를 실행하고, 분기 1회는 수동으로 전체 복구 테스트를 수행하는 것이 좋습니다.

중요한 변경이 있을 때마다 추가 테스트도 필요합니다. 테스트 결과는 반드시 기록으로 남겨야 합니다.

언제 테스트했는지, 결과가 어땠는지, 문제가 있었다면 어떻게 해결했는지를 문서화합니다. 감사나 컴플라이언스 요구사항을 충족하는 데에도 필요합니다.

김개발 씨가 다짐하듯 말했습니다. "이번 달부터 복구 테스트 일정을 달력에 넣어야겠어요." 박시니어 씨가 고개를 끄덕였습니다.

"좋은 생각이에요. 그리고 테스트 실패 시 알림을 보내는 기능도 추가하면 더 좋겠죠."

실전 팁

💡 - 복구 테스트는 자동화하고 결과를 모니터링 시스템에 연동하세요

전체 복구뿐 아니라 개별 파일 복구도 테스트하세요
복구에 걸리는 시간을 측정하여 RTO(복구 목표 시간) 충족 여부를 확인하세요

6. 재해 복구 계획 수립

팀장님이 마지막으로 질문했습니다. "만약 내일 서버실이 통째로 사라진다면, 서비스를 복구하는 데 얼마나 걸릴까요?" 아무도 대답하지 못했습니다.

그제서야 모두가 깨달았습니다. 백업만으로는 부족하다는 것을.

**재해 복구 계획(DRP)**은 재해 상황에서 시스템을 복구하기 위한 전체 절차를 문서화한 것입니다. 마치 비행기의 비상 탈출 매뉴얼처럼, 위기 상황에서 침착하게 따라할 수 있는 단계별 가이드입니다.

계획 없이는 혼란 속에서 소중한 시간을 낭비하게 됩니다.

다음 코드를 살펴봅시다.

#!/bin/bash
# 재해 복구 실행 스크립트 (예시)
# 이 스크립트는 새 서버에서 실행합니다

S3_BUCKET="s3://company-backup/mailserver"
LATEST_BACKUP=$(aws s3 ls "$S3_BUCKET/" | tail -1 | awk '{print $2}')

echo "=== Disaster Recovery Started ==="
echo "Recovering from: $LATEST_BACKUP"

# 1. 필수 패키지 설치
apt-get update && apt-get install -y postfix dovecot-core dovecot-imapd

# 2. 설정 파일 복구
aws s3 sync "$S3_BUCKET/$LATEST_BACKUP/etc/" /etc/

# 3. 메일 데이터 복구
aws s3 sync "$S3_BUCKET/$LATEST_BACKUP/vmail/" /var/vmail/

# 4. 권한 설정
chown -R vmail:vmail /var/vmail

# 5. 서비스 시작 및 검증
systemctl start postfix dovecot
systemctl status postfix dovecot

echo "=== Recovery completed. Verify mail functionality ==="

박시니어 씨가 말했습니다. "재해 복구 계획을 세우려면 먼저 두 가지 지표를 정해야 해요.

RPO와 RTO입니다." **RPO(Recovery Point Objective)**는 "얼마나 많은 데이터 손실을 감수할 수 있는가"입니다. RPO가 1시간이라면, 최악의 경우 1시간 동안의 데이터를 잃을 수 있다는 뜻입니다.

백업 주기가 RPO를 결정합니다. **RTO(Recovery Time Objective)**는 "얼마나 빨리 복구해야 하는가"입니다.

RTO가 4시간이라면, 재해 발생 후 4시간 이내에 서비스가 복구되어야 합니다. 이 두 지표는 비즈니스 요구사항에 따라 결정됩니다.

이메일 서비스라면 RPO 1시간, RTO 4시간 정도가 일반적입니다. 금융 시스템이라면 훨씬 엄격한 기준이 필요하겠죠.

재해 복구 계획에는 반드시 포함되어야 할 내용이 있습니다. 비상 연락망, 복구 절차, 역할 분담, 우선순위, 검증 체크리스트 등입니다.

위 코드는 재해 복구의 기술적인 부분을 보여줍니다. 새 서버에서 실행하여 백업으로부터 메일 시스템을 복구합니다.

하지만 실제 상황에서는 이것만으로 부족합니다. 누가 복구를 담당하는지, DNS를 어떻게 전환하는지, 사용자들에게 어떻게 공지하는지, 복구 후 어떻게 검증하는지 등이 모두 계획에 포함되어야 합니다.

재해 복구 계획은 문서로만 남겨두면 안 됩니다. 정기적으로 모의 훈련을 실시해야 합니다.

1년에 최소 1회, 전체 팀이 참여하여 가상의 재해 시나리오를 연습합니다. 그래야 실제 상황에서 당황하지 않습니다.

김개발 씨가 결심한 듯 말했습니다. "재해 복구 계획서를 작성해서 팀에 공유하겠습니다." 박시니어 씨가 격려했습니다.

"좋아요. 그리고 그 계획을 가지고 분기별로 테이블탑 훈련을 하면 더 좋겠죠.

회의실에 모여서 시나리오대로 역할극을 하는 거예요." 몇 달 후, 실제로 서버 장애가 발생했습니다. 하지만 김개발 씨의 팀은 당황하지 않았습니다.

미리 준비한 계획대로 차분하게 복구를 진행했고, RTO 목표인 4시간보다 빠른 2시간 만에 서비스를 정상화했습니다. 팀장님이 말했습니다.

"준비가 되어 있으니까 위기가 와도 두렵지 않네요."

실전 팁

💡 - 재해 복구 계획서는 접근하기 쉬운 곳에 보관하세요. 서버에만 있으면 재해 시 볼 수 없습니다

RPO와 RTO는 비즈니스 팀과 협의하여 현실적으로 설정하세요
연 1회 이상 모의 훈련을 실시하고, 발견된 문제점을 계획에 반영하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Bash#Backup#Recovery#Maildir#rsync#S3#DisasterRecovery#Backup,Recovery

백업 및 복구 전략 완벽 가이드

# 백업 및 복구 전략 완벽 가이드 메일 서버와 중요 데이터를 안전하게 보호하는 백업 전략을 알아봅니다. Maildir 백업부터 증분 백업, 오프사이트 백업, 그리고 재해 복구 계획까지 실무에서 바로 적용할 수 있는 내용을 담았습니다. --- ## 목차 1. [백업_대상_식별](#백업-대상-식별) 2. [Maildir_백업_전략](#maildir-백업-전략) 3. [증분_백업_구현](#증분-백업-구현) 4. [오프사이트_백업](#오프사이트-백업) 5. [복구_테스트_절차](#복구-테스트-절차) 6. [재해_복구_계획_수립](#재해-복구-계획-수립) --- ## 1. 백업_대상_식별 어느 날 김개발 씨의 회사에서 서버 장애가 발생했습니다. 다행히 큰 문제는 아니었지만, 팀장님이 긴급 회의를 소집했습니다. "우리 백업 체계가 제대로 되어 있는 건가요? 정확히 뭘 백업하고 있죠?" **백업 대상 식별**은 말 그대로 "무엇을 백업할 것인가"를 정하는 첫 번째 단계입니다. 마치 이사할 때 짐을 싸기 전에 무엇을 가져갈지 목록을 만드는 것과 같습니다. 메일 데이터, 설정 파일, 인증서 등 복구에 필요한 모든 항목을 빠짐없이 파악해야 합니다. 다음 코드를 살펴봅시다. ```bash #!/bin/bash # 백업 대상 디렉토리 정의 BACKUP_TARGETS=( "/var/vmail" # 메일 데이터 (Maildir) "/etc/postfix" # Postfix 설정 "/etc/dovecot" # Dovecot 설정 "/etc/ssl/private" # SSL 인증서 개인키 "/etc/letsencrypt" # Let's Encrypt 인증서 "/etc/opendkim" # DKIM 키 "/var/lib/mysql" # 메일 계정 DB ) # 백업 대상 존재 여부 확인 for target in "${BACKUP_TARGETS[@]}"; do if [ -d "$target" ]; then echo "[OK] $target exists" else echo "[WARN] $target not found" fi done ``` 김개발 씨는 신입 시스템 관리자입니다. 팀장님의 질문에 선뜻 대답하지 못한 자신이 부끄러웠습니다. 옆자리의 박시니어 씨가 조용히 다가와 말했습니다. "백업의 첫 번째 원칙을 아세요? 뭘 백업해야 하는지 정확히 아는 거예요." 그렇다면 백업 대상 식별이란 정확히 무엇일까요? 쉽게 비유하자면, 이사할 때를 떠올려 보세요. 짐을 싸기 전에 먼저 무엇을 가져갈지 목록을 만들지 않나요? 귀중품, 가전제품, 옷가지 등을 하나하나 체크하면서요. 백업도 마찬가지입니다. 어떤 데이터가 중요하고, 어떤 파일이 복구에 필수적인지 먼저 파악해야 합니다. 메일 서버를 운영한다고 가정해봅시다. 가장 중요한 것은 당연히 **메일 데이터**입니다. 사용자들의 소중한 이메일이 담겨 있으니까요. 보통 /var/vmail이나 /home/vmail 같은 경로에 저장됩니다. 두 번째로 중요한 것은 **설정 파일**입니다. Postfix의 main.cf, Dovecot의 dovecot.conf 같은 파일들이죠. 이 설정 파일들이 없으면 서버를 처음부터 다시 구성해야 합니다. 수십 개의 옵션을 일일이 다시 설정한다고 생각해보세요. 끔찍하지 않나요? 세 번째는 **SSL 인증서**입니다. 요즘 메일 서버는 TLS 암호화가 필수입니다. 인증서가 없으면 이메일 송수신 자체가 안 될 수 있습니다. Let's Encrypt를 사용한다면 /etc/letsencrypt 디렉토리 전체를 백업해야 합니다. 네 번째는 **DKIM 키**입니다. 이메일 인증에 사용되는 키인데, 이게 없으면 발송한 메일이 스팸으로 처리될 수 있습니다. /etc/opendkim 디렉토리에 보통 저장됩니다. 마지막으로 **데이터베이스**입니다. 메일 계정 정보, 별칭, 도메인 설정 등이 MySQL이나 PostgreSQL에 저장되어 있다면 이것도 백업 대상입니다. 위 코드를 살펴보면, 먼저 BACKUP_TARGETS 배열에 백업할 디렉토리들을 정의합니다. 그리고 for 루프를 돌면서 각 디렉토리가 실제로 존재하는지 확인합니다. 이렇게 하면 백업 전에 누락된 항목이 없는지 미리 체크할 수 있습니다. 실무에서는 이 목록을 문서화해두는 것이 좋습니다. 새로운 서비스가 추가될 때마다 백업 대상도 업데이트해야 하니까요. 박시니어 씨는 이렇게 덧붙였습니다. "백업 대상 목록은 살아있는 문서예요. 시스템이 바뀔 때마다 함께 업데이트해야 합니다." 김개발 씨는 고개를 끄덕였습니다. 백업의 첫걸음은 거창한 기술이 아니라, 무엇이 중요한지 정확히 아는 것이었습니다. **실전 팁** 💡 - 백업 대상 목록은 반드시 문서화하고 정기적으로 업데이트하세요 - 로그 파일은 보통 백업 대상에서 제외하지만, 감사 로그는 별도로 보관하세요 - 설정 파일 변경 시 버전 관리 시스템(Git)을 활용하면 더욱 안전합니다 --- ## 2. Maildir_백업_전략 김개발 씨가 백업 대상을 정리하고 나니, 다음 질문이 떠올랐습니다. "메일 데이터가 가장 크고 중요한데, 이걸 어떻게 효율적으로 백업하지?" 박시니어 씨가 웃으며 대답했습니다. "Maildir 형식의 장점을 알면 답이 보여요." **Maildir**은 각 이메일을 개별 파일로 저장하는 메일 저장 형식입니다. 마치 서류철에 문서를 한 장씩 따로 보관하는 것과 같습니다. 이 구조 덕분에 파일 단위로 백업이 가능하고, 손상된 메일 하나가 전체에 영향을 주지 않습니다. 다음 코드를 살펴봅시다. ```bash #!/bin/bash # Maildir 백업 스크립트 MAIL_DIR="/var/vmail" BACKUP_DIR="/backup/maildir" DATE=$(date +%Y%m%d) # 백업 디렉토리 생성 mkdir -p "$BACKUP_DIR/$DATE" # rsync로 Maildir 백업 (삭제된 파일은 유지) rsync -avz --progress \ --exclude="dovecot.index*" \ --exclude="dovecot-uidlist" \ "$MAIL_DIR/" "$BACKUP_DIR/$DATE/" # 백업 결과 확인 echo "Backup completed: $(du -sh $BACKUP_DIR/$DATE)" # 30일 이상 된 백업 삭제 find "$BACKUP_DIR" -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \; ``` 박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "메일 저장 방식에는 크게 두 가지가 있어요. mbox와 Maildir이죠." mbox 형식은 모든 이메일을 하나의 큰 파일에 저장합니다. 마치 두꺼운 노트 한 권에 모든 메모를 적는 것과 같죠. 간단해 보이지만, 문제가 있습니다. 파일이 손상되면 모든 메일을 잃을 수 있고, 백업 중에 새 메일이 오면 충돌이 발생할 수 있습니다. 반면 **Maildir**은 각 이메일을 별도의 파일로 저장합니다. 마치 서류철에 문서를 한 장씩 따로 보관하는 것처럼요. cur, new, tmp 세 개의 디렉토리로 구성되어 있습니다. **new** 디렉토리에는 아직 읽지 않은 새 메일이 들어옵니다. 사용자가 메일을 읽으면 **cur** 디렉토리로 이동합니다. **tmp**는 메일을 임시로 저장하는 공간입니다. 이 구조 덕분에 파일 잠금 없이도 안전하게 메일을 처리할 수 있습니다. 위 코드를 살펴봅시다. rsync 명령어를 사용하는데, 이것이 핵심입니다. rsync는 변경된 파일만 복사하므로 전체 복사보다 훨씬 빠릅니다. -a 옵션은 아카이브 모드로 권한과 타임스탬프를 보존합니다. -v는 상세 출력, -z는 전송 중 압축을 의미합니다. 주목할 점은 exclude 옵션입니다. dovecot.index와 dovecot-uidlist는 Dovecot이 자동으로 생성하는 인덱스 파일입니다. 이 파일들은 백업할 필요가 없습니다. 복구 후 Dovecot이 알아서 다시 만들어주니까요. 오히려 백업에 포함하면 용량만 차지하고 복구 시 문제가 될 수 있습니다. 마지막 줄의 find 명령어는 30일이 지난 오래된 백업을 자동으로 삭제합니다. 백업 용량이 무한정 늘어나는 것을 방지하는 중요한 부분입니다. 실무에서 주의할 점이 있습니다. 백업 중에도 메일 서버는 계속 동작합니다. Maildir 형식이라 대부분 문제가 없지만, 매우 큰 첨부 파일을 받는 중이라면 해당 파일이 불완전하게 백업될 수 있습니다. 이런 경우를 대비해 백업을 트래픽이 적은 새벽 시간에 실행하는 것이 좋습니다. 김개발 씨가 질문했습니다. "그럼 매일 전체를 복사하는 건가요?" 박시니어 씨가 고개를 저었습니다. "아니요, 그건 증분 백업으로 해결합니다. 다음에 알려드릴게요." **실전 팁** 💡 - rsync의 --delete 옵션은 신중하게 사용하세요. 실수로 원본을 삭제하면 백업에서도 사라집니다 - 백업 실행 시간은 메일 트래픽이 적은 새벽 시간대를 권장합니다 - 백업 완료 후 파일 개수와 용량을 로그로 남겨 이상 징후를 감지하세요 --- ## 3. 증분_백업_구현 다음 날, 김개발 씨가 백업 용량 보고서를 보고 깜짝 놀랐습니다. "100GB 메일 데이터를 매일 백업하면 한 달에 3TB가 넘잖아요!" 박시니어 씨가 웃으며 말했습니다. "그래서 증분 백업이 필요한 거예요." **증분 백업**은 이전 백업 이후 변경된 파일만 백업하는 방식입니다. 마치 일기를 쓸 때 이미 쓴 부분은 그대로 두고 오늘 있었던 일만 추가로 적는 것과 같습니다. 저장 공간을 크게 절약하면서도 완전한 복구가 가능합니다. 다음 코드를 살펴봅시다. ```bash #!/bin/bash # 증분 백업 스크립트 (하드링크 활용) MAIL_DIR="/var/vmail" BACKUP_BASE="/backup/maildir" DATE=$(date +%Y%m%d_%H%M%S) LATEST="$BACKUP_BASE/latest" # 이전 백업이 있으면 하드링크로 증분 백업 if [ -d "$LATEST" ]; then rsync -avz --delete \ --link-dest="$LATEST" \ --exclude="dovecot.index*" \ "$MAIL_DIR/" "$BACKUP_BASE/$DATE/" else # 첫 백업은 전체 백업 rsync -avz "$MAIL_DIR/" "$BACKUP_BASE/$DATE/" fi # latest 심볼릭 링크 업데이트 rm -f "$LATEST" ln -s "$BACKUP_BASE/$DATE" "$LATEST" echo "Incremental backup completed: $DATE" ``` 김개발 씨는 증분 백업이라는 말은 들어봤지만, 정확히 어떻게 동작하는지 몰랐습니다. 박시니어 씨가 설명을 시작했습니다. "백업에는 세 가지 종류가 있어요. **전체 백업**, **차등 백업**, **증분 백업**입니다." 전체 백업은 말 그대로 모든 데이터를 매번 복사합니다. 단순하지만 시간과 공간이 많이 필요합니다. 차등 백업은 마지막 전체 백업 이후 변경된 모든 파일을 백업합니다. 증분 백업은 마지막 백업(전체든 증분이든) 이후 변경된 파일만 백업합니다. 비유를 들어볼까요? 전체 백업은 매일 일기장을 처음부터 끝까지 다시 베껴 쓰는 것입니다. 증분 백업은 오늘 새로 쓴 페이지만 복사하는 것이죠. 어느 쪽이 효율적인지는 명확합니다. 위 코드의 핵심은 **--link-dest** 옵션입니다. 이 옵션은 rsync의 마법 같은 기능입니다. 변경되지 않은 파일은 복사하지 않고 이전 백업의 파일에 **하드링크**를 생성합니다. 하드링크가 뭘까요? 파일 시스템에서 같은 데이터를 가리키는 또 다른 이름입니다. 실제 데이터는 하나인데 이름이 여러 개인 셈이죠. 덕분에 디스크 공간을 추가로 사용하지 않으면서도, 각 백업 디렉토리는 완전한 스냅샷처럼 보입니다. 예를 들어 100GB 메일 데이터 중 오늘 1GB만 변경되었다고 합시다. 증분 백업을 실행하면 실제로는 1GB만 새로 저장됩니다. 하지만 백업 디렉토리를 보면 100GB 전체가 있는 것처럼 보입니다. 99GB는 하드링크로 이전 백업을 가리키고 있기 때문입니다. 코드에서 LATEST 변수는 가장 최근 백업을 가리키는 심볼릭 링크입니다. 새 백업이 완료되면 이 링크를 업데이트합니다. 다음 백업 시 이 링크를 참조하여 증분 백업을 수행합니다. 주의할 점이 있습니다. --delete 옵션을 사용하면 원본에서 삭제된 파일이 새 백업에도 반영됩니다. 하지만 이전 백업에는 그 파일이 여전히 남아있습니다. 하드링크 덕분이죠. 실수로 파일을 삭제해도 이전 백업에서 복구할 수 있습니다. 김개발 씨가 감탄했습니다. "하드링크라니, 정말 똑똑한 방법이네요!" 박시니어 씨가 덧붙였습니다. "대신 하드링크는 같은 파일 시스템 내에서만 동작해요. 다른 디스크로 백업하려면 다른 방법이 필요합니다." **실전 팁** 💡 - 하드링크 기반 증분 백업은 반드시 같은 파일 시스템 내에서 사용하세요 - 주 1회 전체 백업 + 매일 증분 백업 조합이 일반적입니다 - 백업 보관 정책을 명확히 정하고 자동 삭제 스크립트를 함께 운영하세요 --- ## 4. 오프사이트_백업 어느 날 김개발 씨가 뉴스를 보다가 깜짝 놀랐습니다. 모 회사 데이터센터에 화재가 발생해서 서버와 백업 디스크가 모두 소실되었다는 기사였습니다. "우리 백업도 같은 서버실에 있는데..." 박시니어 씨가 진지하게 말했습니다. "그래서 오프사이트 백업이 필수입니다." **오프사이트 백업**은 물리적으로 다른 위치에 백업을 저장하는 것입니다. 마치 중요한 문서 사본을 집과 사무실 두 곳에 보관하는 것과 같습니다. 서버실에 재해가 발생해도 원격지의 백업으로 복구할 수 있습니다. 다음 코드를 살펴봅시다. ```bash #!/bin/bash # S3 오프사이트 백업 스크립트 BACKUP_DIR="/backup/maildir/latest" S3_BUCKET="s3://company-backup/mailserver" DATE=$(date +%Y%m%d) # AWS CLI로 S3 동기화 (변경된 파일만 업로드) aws s3 sync "$BACKUP_DIR" "$S3_BUCKET/$DATE/" \ --storage-class STANDARD_IA \ --exclude "*.log" \ --delete # 90일 이상 된 S3 백업 삭제 (수명 주기 정책 권장) aws s3 ls "$S3_BUCKET/" | while read -r line; do backup_date=$(echo "$line" | awk '{print $2}' | tr -d '/') if [[ "$backup_date" < $(date -d '90 days ago' +%Y%m%d) ]]; then aws s3 rm "$S3_BUCKET/$backup_date" --recursive fi done echo "Offsite backup to S3 completed" ``` 박시니어 씨가 말을 이었습니다. "백업의 황금률을 아세요? **3-2-1 규칙**이라고 합니다." 3-2-1 규칙은 이렇습니다. 최소 **3개**의 데이터 사본을 유지하고, **2가지** 다른 저장 매체를 사용하며, **1개**는 반드시 오프사이트에 보관합니다. 이 규칙을 지키면 대부분의 재해 상황에서 데이터를 복구할 수 있습니다. 오프사이트 백업의 대표적인 방법은 **클라우드 스토리지**입니다. AWS S3, Google Cloud Storage, Azure Blob Storage 등이 있죠. 그중에서도 AWS S3는 99.999999999%의 내구성을 자랑합니다. 숫자가 너무 길어서 실감이 안 나시죠? 1억 개의 파일을 저장해도 10만 년에 하나 정도만 손실될 확률입니다. 위 코드를 살펴봅시다. aws s3 sync 명령어는 로컬과 S3 간에 변경된 파일만 동기화합니다. rsync와 비슷한 개념이죠. --storage-class STANDARD_IA는 비용 절약을 위한 옵션입니다. IA는 Infrequent Access의 약자로, 자주 접근하지 않는 데이터에 적합합니다. 백업 데이터가 딱 이 경우에 해당하죠. 클라우드 말고 다른 방법도 있습니다. **rsync over SSH**를 사용하면 다른 서버로 백업할 수 있습니다. ```bash rsync -avz -e ssh /backup/maildir/ user@remote-server:/backup/ ``` 이 방법은 직접 관리하는 서버가 여러 대 있을 때 유용합니다. 클라우드 비용도 절약할 수 있고요. 다만 원격 서버도 관리해야 하는 부담이 있습니다. 실무에서 주의할 점이 있습니다. 오프사이트 백업은 네트워크를 통해 전송되므로 **암호화**가 필수입니다. S3는 기본적으로 전송 중 암호화(TLS)를 지원하고, 저장 시 암호화(SSE-S3, SSE-KMS)도 설정할 수 있습니다. 또한 **대역폭**을 고려해야 합니다. 첫 번째 전체 백업은 데이터 양이 많아 시간이 오래 걸릴 수 있습니다. 100GB를 100Mbps 회선으로 전송하면 약 2시간이 걸립니다. 업무 시간을 피해 실행하거나, 대역폭 제한 옵션을 사용하세요. 김개발 씨가 물었습니다. "S3 비용은 어느 정도인가요?" 박시니어 씨가 대답했습니다. "STANDARD_IA 기준으로 GB당 월 0.0125달러 정도입니다. 100GB면 한 달에 1.25달러예요. 데이터의 가치를 생각하면 정말 저렴하죠." **실전 팁** 💡 - S3 버킷에 버전 관리를 활성화하면 실수로 덮어쓴 파일도 복구할 수 있습니다 - S3 Glacier를 사용하면 장기 보관 비용을 더욱 절약할 수 있습니다 - 오프사이트 전송 시 반드시 암호화를 사용하고, 접근 권한을 최소화하세요 --- ## 5. 복구_테스트_절차 한 달 뒤, 팀 회의에서 팀장님이 질문했습니다. "백업은 잘 되고 있는 것 같은데, 복구는 해봤나요?" 김개발 씨와 박시니어 씨가 서로 눈치를 봤습니다. 백업만 하고 복구 테스트는 한 번도 안 해본 것이었습니다. **복구 테스트**는 백업이 실제로 작동하는지 검증하는 과정입니다. 마치 소화기가 제대로 작동하는지 정기적으로 점검하는 것과 같습니다. 테스트하지 않은 백업은 백업이 아닙니다. 실제 복구 상황에서 문제를 발견하면 이미 늦습니다. 다음 코드를 살펴봅시다. ```bash #!/bin/bash # 복구 테스트 스크립트 TEST_DIR="/tmp/recovery_test" BACKUP_SOURCE="/backup/maildir/latest" TEST_USER="testuser@example.com" # 테스트 환경 준비 rm -rf "$TEST_DIR" mkdir -p "$TEST_DIR" # 특정 사용자 메일 복구 테스트 echo "Restoring $TEST_USER mailbox..." rsync -avz "$BACKUP_SOURCE/example.com/$TEST_USER/" "$TEST_DIR/" # 복구된 데이터 검증 MAIL_COUNT=$(find "$TEST_DIR" -type f -name "*." | wc -l) echo "Recovered mail count: $MAIL_COUNT" # 무결성 검사 (파일 손상 확인) CORRUPTED=0 for mail in "$TEST_DIR/cur/"*; do if ! head -1 "$mail" | grep -q "^From:\|^Return-Path:\|^Delivered-To:"; then echo "Possibly corrupted: $mail" ((CORRUPTED++)) fi done echo "Test completed. Corrupted files: $CORRUPTED" rm -rf "$TEST_DIR" ``` 박시니어 씨가 무거운 목소리로 말했습니다. "업계에서 유명한 이야기가 있어요. 모 회사가 10년간 백업을 성실히 했는데, 정작 복구가 필요할 때 테이프가 모두 불량이었다는 거죠. 백업 시스템은 잘 돌아갔지만, 테이프 드라이브가 고장 난 줄 몰랐던 겁니다." 충격적인 이야기지만, 생각보다 흔한 일입니다. **테스트하지 않은 백업은 백업이 아닙니다.** 이 문장을 꼭 기억하세요. 복구 테스트는 크게 세 가지를 검증합니다. 첫째, **백업 데이터의 완전성**. 모든 파일이 제대로 백업되었는지 확인합니다. 둘째, **데이터 무결성**. 파일이 손상되지 않았는지 검사합니다. 셋째, **복구 절차의 유효성**. 실제로 복구가 가능한지 확인합니다. 위 코드는 간단한 복구 테스트 스크립트입니다. 먼저 임시 디렉토리를 만들고, 백업에서 특정 사용자의 메일함을 복구합니다. 그리고 복구된 메일 파일의 개수를 세고, 각 파일의 헤더를 검사하여 손상 여부를 확인합니다. 더 철저한 테스트를 원한다면, 별도의 테스트 서버를 준비하는 것이 좋습니다. 백업에서 전체 메일 시스템을 복구하고, 실제로 메일을 주고받아 보는 것이죠. 이렇게 하면 설정 파일의 정확성까지 검증할 수 있습니다. 복구 테스트 주기는 어떻게 정할까요? 최소한 **월 1회**는 자동화된 테스트를 실행하고, **분기 1회**는 수동으로 전체 복구 테스트를 수행하는 것이 좋습니다. 중요한 변경이 있을 때마다 추가 테스트도 필요합니다. 테스트 결과는 반드시 기록으로 남겨야 합니다. 언제 테스트했는지, 결과가 어땠는지, 문제가 있었다면 어떻게 해결했는지를 문서화합니다. 감사나 컴플라이언스 요구사항을 충족하는 데에도 필요합니다. 김개발 씨가 다짐하듯 말했습니다. "이번 달부터 복구 테스트 일정을 달력에 넣어야겠어요." 박시니어 씨가 고개를 끄덕였습니다. "좋은 생각이에요. 그리고 테스트 실패 시 알림을 보내는 기능도 추가하면 더 좋겠죠." **실전 팁** 💡 - 복구 테스트는 자동화하고 결과를 모니터링 시스템에 연동하세요 - 전체 복구뿐 아니라 개별 파일 복구도 테스트하세요 - 복구에 걸리는 시간을 측정하여 RTO(복구 목표 시간) 충족 여부를 확인하세요 --- ## 6. 재해_복구_계획_수립 팀장님이 마지막으로 질문했습니다. "만약 내일 서버실이 통째로 사라진다면, 서비스를 복구하는 데 얼마나 걸릴까요?" 아무도 대답하지 못했습니다. 그제서야 모두가 깨달았습니다. 백업만으로는 부족하다는 것을. **재해 복구 계획(DRP)**은 재해 상황에서 시스템을 복구하기 위한 전체 절차를 문서화한 것입니다. 마치 비행기의 비상 탈출 매뉴얼처럼, 위기 상황에서 침착하게 따라할 수 있는 단계별 가이드입니다. 계획 없이는 혼란 속에서 소중한 시간을 낭비하게 됩니다. 다음 코드를 살펴봅시다. ```bash #!/bin/bash # 재해 복구 실행 스크립트 (예시) # 이 스크립트는 새 서버에서 실행합니다 S3_BUCKET="s3://company-backup/mailserver" LATEST_BACKUP=$(aws s3 ls "$S3_BUCKET/" | tail -1 | awk '{print $2}') echo "=== Disaster Recovery Started ===" echo "Recovering from: $LATEST_BACKUP" # 1. 필수 패키지 설치 apt-get update && apt-get install -y postfix dovecot-core dovecot-imapd # 2. 설정 파일 복구 aws s3 sync "$S3_BUCKET/$LATEST_BACKUP/etc/" /etc/ # 3. 메일 데이터 복구 aws s3 sync "$S3_BUCKET/$LATEST_BACKUP/vmail/" /var/vmail/ # 4. 권한 설정 chown -R vmail:vmail /var/vmail # 5. 서비스 시작 및 검증 systemctl start postfix dovecot systemctl status postfix dovecot echo "=== Recovery completed. Verify mail functionality ===" ``` 박시니어 씨가 말했습니다. "재해 복구 계획을 세우려면 먼저 두 가지 지표를 정해야 해요. **RPO**와 **RTO**입니다." **RPO(Recovery Point Objective)**는 "얼마나 많은 데이터 손실을 감수할 수 있는가"입니다. RPO가 1시간이라면, 최악의 경우 1시간 동안의 데이터를 잃을 수 있다는 뜻입니다. 백업 주기가 RPO를 결정합니다. **RTO(Recovery Time Objective)**는 "얼마나 빨리 복구해야 하는가"입니다. RTO가 4시간이라면, 재해 발생 후 4시간 이내에 서비스가 복구되어야 합니다. 이 두 지표는 비즈니스 요구사항에 따라 결정됩니다. 이메일 서비스라면 RPO 1시간, RTO 4시간 정도가 일반적입니다. 금융 시스템이라면 훨씬 엄격한 기준이 필요하겠죠. 재해 복구 계획에는 반드시 포함되어야 할 내용이 있습니다. **비상 연락망**, **복구 절차**, **역할 분담**, **우선순위**, **검증 체크리스트** 등입니다. 위 코드는 재해 복구의 기술적인 부분을 보여줍니다. 새 서버에서 실행하여 백업으로부터 메일 시스템을 복구합니다. 하지만 실제 상황에서는 이것만으로 부족합니다. 누가 복구를 담당하는지, DNS를 어떻게 전환하는지, 사용자들에게 어떻게 공지하는지, 복구 후 어떻게 검증하는지 등이 모두 계획에 포함되어야 합니다. 재해 복구 계획은 문서로만 남겨두면 안 됩니다. 정기적으로 **모의 훈련**을 실시해야 합니다. 1년에 최소 1회, 전체 팀이 참여하여 가상의 재해 시나리오를 연습합니다. 그래야 실제 상황에서 당황하지 않습니다. 김개발 씨가 결심한 듯 말했습니다. "재해 복구 계획서를 작성해서 팀에 공유하겠습니다." 박시니어 씨가 격려했습니다. "좋아요. 그리고 그 계획을 가지고 분기별로 테이블탑 훈련을 하면 더 좋겠죠. 회의실에 모여서 시나리오대로 역할극을 하는 거예요." 몇 달 후, 실제로 서버 장애가 발생했습니다. 하지만 김개발 씨의 팀은 당황하지 않았습니다. 미리 준비한 계획대로 차분하게 복구를 진행했고, RTO 목표인 4시간보다 빠른 2시간 만에 서비스를 정상화했습니다. 팀장님이 말했습니다. "준비가 되어 있으니까 위기가 와도 두렵지 않네요." **실전 팁** 💡 - 재해 복구 계획서는 접근하기 쉬운 곳에 보관하세요. 서버에만 있으면 재해 시 볼 수 없습니다 - RPO와 RTO는 비즈니스 팀과 협의하여 현실적으로 설정하세요 - 연 1회 이상 모의 훈련을 실시하고, 발견된 문제점을 계획에 반영하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: Backup,Recovery

언어: Bash

태그: Bash, Backup, Recovery, Maildir, rsync, S3, DisasterRecovery, Backup,Recovery

작성자: AI Generated

CodeDeck

백업 및 복구 전략 완벽 가이드

목차

1. 백업 대상 식별

2. Maildir 백업 전략

3. 증분 백업 구현

4. 오프사이트 백업

5. 복구 테스트 절차

6. 재해 복구 계획 수립

댓글 (0)

함께 보면 좋은 카드 뉴스

SSL/TLS 인증서 설정 완벽 가이드 (Let's Encrypt)

Dovecot으로 IMAP/POP3 메일 서버 구축하기

SMTP 서버 구성 Postfix 완벽 가이드

Docker 환경 준비 및 docker-mailserver 설치

Docker 보안 베스트 프랙티스 완벽 가이드