백업 파일 복원 테스트로 백업 신뢰성 확인이 얼마나 중요한지 알게 된 건 DB가 깨진 후 백업 파일을 열었더니 gzip: /var/backups/mysql/backup.sql.gz: unexpected end of file이 나왔을 때입니다. 디스크 쓰기가 실패한 날 백업이 불완전하게 저장됐고, 이후 로그도 확인 안 하고 안심하고 있었습니다. 백업이 있어도 열리지 않으면 없는 것과 같습니다.
# gzip 파일 무결성 테스트 (압축 풀지 않고 검증)
gzip -t /var/backups/mysql/backup_20260525.sql.gz
echo "Exit code: $?" # 0이면 정상, 1이면 손상
# 모든 백업 파일 일괄 검증
for f in /var/backups/mysql/*.sql.gz; do
gzip -t "$f" 2>/dev/null && echo "✅ OK: $f" || echo "❌ FAIL: $f"
done
# SQL 파일 헤더 확인 (압축 풀어서 첫 줄 확인)
zcat /var/backups/mysql/backup_20260525.sql.gz | head -5
# 테스트 DB 생성
mysql -u root -p -e "CREATE DATABASE restore_test;"
# 백업을 테스트 DB에 복원
zcat /var/backups/mysql/backup_20260525.sql.gz | mysql -u root -p restore_test
# 복원 확인 (테이블 수 비교)
mysql -u root -p -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='restore_test';"
mysql -u root -p -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='원본DB';"
# 테스트 DB 삭제
mysql -u root -p -e "DROP DATABASE restore_test;"
#!/bin/bash
# /usr/local/bin/verify-backup.sh
BACKUP_DIR="/var/backups/mysql"
LATEST=$(ls -t "$BACKUP_DIR"/*.sql.gz 2>/dev/null | head -1)
ADMIN_EMAIL="admin@병원사이트.com"
if [ -z "$LATEST" ]; then
echo "백업 파일 없음" | mail -s "[서버경고] 백업 파일 미발견" $ADMIN_EMAIL
exit 1
fi
if ! gzip -t "$LATEST" 2>/dev/null; then
echo "백업 파일 손상: $LATEST" | mail -s "[서버경고] 백업 파일 손상" $ADMIN_EMAIL
exit 1
fi
echo "$(date): 백업 검증 OK - $LATEST" >> /var/log/backup-verify.log
백업 복원 테스트는 월 1회 이상 정기적으로 실시해야 합니다. 실제 장애 상황에서 처음 복원을 시도하면 예상치 못한 문제가 나타나기 쉽습니다.
AI가 초안을 생성하고, 의료기관 인프라 운영자가 1차 데이터 기반으로 최종 검수·승인합니다.
작성·검수: WavePix 운영자 (의료기관 3곳 인프라 전담)