정기 백업을 효과적으로 모니터링하는 방법

Source: Dev.to

위의 소스 링크에 포함된 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 기술 용어는 그대로 유지됩니다.)

시나리오

다음 상황을 상상해 보세요: 프로덕션 데이터베이스(예: 온라인 스토어)를 백업하기 위해 Bash 스크립트를 작성했습니다. 스크립트를 crontab에 추가한 후에는 모든 것이 완벽히 작동했습니다. 한 달 뒤 데이터베이스가 손상되었습니다—아마도 결함이 있는 플러그인을 설치했기 때문일 수 있습니다. “가장 최신” 백업으로 복원하려고 시도했지만, 가장 최근 백업이 두 주 전 것이라는 사실을 알게 됩니다.

무슨 일이 일어난 걸까요?
백업 스크립트가 조용히 작동을 멈췄습니다. 이 악몽은 생각보다 흔하며 다음과 같은 원인으로 발생할 수 있습니다:

• 디스크 용량 부족
• 권한 변경
• 네트워크 타임아웃
• 인증 정보 만료
• 급하게 수정하면서 발생한 오타

모니터링되지 않은 백업의 문제

전통적인 cron 작업에는 근본적인 결함이 있습니다: 작업이 실행되지 않을 때만 오류를 보고합니다. 백업 스크립트는

• 오류를 반환하지만 cron 입장에서는 “성공”으로 간주됨
• 빈 파일이나 손상된 파일을 생성함
• 예상보다 훨씬 오래 걸림 (근본적인 문제의 신호)
• 권한 문제로 테이블을 건너뛰음

눈치채기도 전에 보존 기간이 만료되고 사용 가능한 백업이 없게 됩니다.

백업 스크립트 모니터링

해결 방법은 간단합니다: 백업 스크립트가 상태를 외부 모니터에 적극적으로 보고하도록 합니다. 아래는 **CronMonitor**와 데이터베이스 백업을 연동하는 가이드입니다.

MySQL / MariaDB 백업 예시

#!/bin/bash

MONITOR_URL="https://cronmonitor.app/api/ping/your-unique-id"
BACKUP_DIR="/backups/mysql"
DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="production"

# Signal start
curl -s "${MONITOR_URL}/start"

# Perform backup
mysqldump --single-transaction \
    --routines \
    --triggers \
    "$DB_NAME" | gzip > "${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz"

# Verify backup succeeded and file is not empty
if [ $? -eq 0 ] && [ -s "${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz" ]; then
    # Keep only the last 7 days
    find "$BACKUP_DIR" -name "*.sql.gz" -mtime +7 -delete

    # Signal success
    curl -s "${MONITOR_URL}/complete"
else
    # Signal failure
    curl -s "${MONITOR_URL}/fail"
    exit 1
fi

PostgreSQL 백업 예시

#!/bin/bash

MONITOR_URL="https://cronmonitor.app/api/ping/your-unique-id"
BACKUP_DIR="/backups/postgres"
DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="production"

# Signal start
curl -s "${MONITOR_URL}/start"

# Perform backup (custom format for flexibility)
pg_dump -Fc "$DB_NAME" > "${BACKUP_DIR}/${DB_NAME}_${DATE}.dump"

# Verify backup succeeded and file is not empty
if [ $? -eq 0 ] && [ -s "${BACKUP_DIR}/${DB_NAME}_${DATE}.dump" ]; then
    # Verify integrity
    pg_restore --list "${BACKUP_DIR}/${DB_NAME}_${DATE}.dump" > /dev/null 2>&1
    if [ $? -eq 0 ]; then
        curl -s "${MONITOR_URL}/complete"
    else
        curl -s "${MONITOR_URL}/fail"
        exit 1
    fi
else
    curl -s "${MONITOR_URL}/fail"
    exit 1
fi

다중 데이터베이스 백업 및 크기 보고

#!/bin/bash

MONITOR_URL="https://cronmonitor.app/api/ping/your-unique-id"
BACKUP_DIR="/backups"
DATE=$(date +%Y%m%d)
DATABASES="app_production analytics users"

# Signal start
curl -s "${MONITOR_URL}/start"

FAILED=0
TOTAL_SIZE=0

for DB in $DATABASES; do
    mysqldump --single-transaction "$DB" | gzip > "${BACKUP_DIR}/${DB}_${DATE}.sql.gz"

    if [ $? -ne 0 ] || [ ! -s "${BACKUP_DIR}/${DB}_${DATE}.sql.gz" ]; then
        FAILED=1
        echo "Backup failed for: $DB"
    else
        # Get file size (compatible with macOS and Linux)
        SIZE=$(stat -f%z "${BACKUP_DIR}/${DB}_${DATE}.sql.gz" 2>/dev/null || stat -c%s "${BACKUP_DIR}/${DB}_${DATE}.sql.gz")
        TOTAL_SIZE=$((TOTAL_SIZE + SIZE))
    fi
done

if [ $FAILED -eq 0 ]; then
    # Report success with total size metadata
    curl -s "${MONITOR_URL}/complete?msg=Backed%20up%20${TOTAL_SIZE}%20bytes"
else
    curl -s "${MONITOR_URL}/fail"
    exit 1
fi

백업 작업을 위한 CronMonitor 설정 방법

1. 새 모니터 만들기 in CronMonitor for the “backup” job.
2. 예상 스케줄 설정 (예: 매일 오전 02:00).
3. 그레이스 기간 구성—가장 큰 예상 백업이 완료될 수 있을 만큼 충분히 길게.
4. 알림 설정 (email, Slack, Discord, 등).

주요 설정

• Schedule – 서버의 크론 스케줄과 정확히 일치해야 합니다.
• Grace period – 가장 긴 예상 백업 시간보다 길어야 합니다.

모범 사례

1. 검증하고, 추정하지 말 것
   백업 파일이 존재하고 데이터가 포함되어 있는지 항상 확인하십시오. 빈 gzip 파일도 셸 관점에서는 “성공적인” 명령으로 간주됩니다.

2. 복원을 정기적으로 테스트
   백업은 복원 가능성에 따라 그 가치가 결정됩니다. 정기적인 복원 테스트를 일정에 포함하고 해당 작업을 모니터링하십시오.

3. 백업 소요 시간 모니터링
   CronMonitor는 각 작업이 걸리는 시간을 기록합니다. 갑작스러운 증가는 데이터 양 증가나 성능 문제를 나타낼 수 있습니다.

4. 백업을 오프‑사이트에 저장
   외부 드라이브나 서버로 동기화하는 단계를 포함하십시오.

   # After local backup succeeds
   rsync -az "${BACKUP_DIR}/" remote:/backups/ && \
       curl -s "${MONITOR_URL}/complete" || \
       curl -s "${MONITOR_URL}/fail"

5. 복구 절차 문서화
   알림이 발생하면(예: 백업 실패에 대한 Slack 알림) 디버깅 세션이 아니라 명확한 단계별 지침이 필요합니다.

결론

데이터베이스 백업은 데이터 손실에 대한 최후의 방어선입니다. 백업은 단순히 한 번 설정하고 잊어버리는 cron 작업이나 모든 것이 항상 정상적으로 실행될 것이라는 기대만으로는 충분하지 않습니다. 능동적인 모니터링을 추가하면 문제를 즉시 파악할 수 있어, 상황이 너무 악화되기 전에 조치를 취할 수 있습니다.

문제를 해결할 시간이 있을 때.

오늘 바로 백업 스크립트 모니터링을 시작하세요. 데이터 손실을 고객에게 설명할 필요가 없는 미래의 당신이 감사할 것입니다.

CronMonitor 은 간단하고 개발자 친화적인 cron 작업 모니터링 서비스입니다. 첫 번째 모니터를 1분 이내에 설정하세요.