“DB 장애는 ‘언젠가 반드시’ 발생한다.문제는 ‘발생하느냐’가 아니라‘얼마나 빨리 복구하느냐’다.”
| 사고 유형 | 결과 |
|---|---|
| DELETE / UPDATE 실수 | 데이터 영구 손실 |
| 애플리케이션 버그 | 대량 데이터 오염 |
| 디스크 장애 | DB 기동 불가 |
| 잘못된 마이그레이션 | 구조/데이터 파손 |
| 랜섬웨어 | 전체 암호화 |
❌ “백업 파일이 있다”
⭕ “복구가 실제로 된다”
mysqldumpmysqldump -u root -p bootcamp_shop > bootcamp_shop.sql
mysqldump -u root -p bootcamp_shop orders order_items > orders_backup.sql
| 장점 | 단점 |
|---|---|
| 단순 | 대용량 느림 |
| 이식성 좋음 | 복구 시간 김 |
| 부분 복구 쉬움 | 락/성능 영향 |
Percona XtraBackup| 장점 | 단점 |
|---|---|
| 매우 빠름 | 구조 의존 |
| 대용량 적합 | 부분 복구 어려움 |
| 운영 서비스 친화 | 설정 복잡 |
운영 서비스 / 대규모 DB 필수
“백업 중에 데이터가 바뀌면 어떻게 되나?”
InnoDB + 트랜잭션 = 백업 가능성의 전제 조건
“DB를 특정 시점 상태로 되돌리는 작업”
mysql -u root -p bootcamp_shop < bootcamp_shop.sql
특징:
- 테이블 DROP 후 다시 생성됨
- 인덱스도 같이 재생성됨
- 시간 오래 걸릴 수 있음
[전체 백업] + [binlog 재생]
SHOW VARIABLES LIKE 'log_bin';
mysqlbinlog binlog.000001 | mysql -u root -p
- 특정 시간으로 복
mysqlbinlog \
--stop-datetime="2026-01-29 14:30:00" \
binlog.000001 | mysql -u root -p
인덱스도 데이터다.백업/복구 대상이다.
CREATE INDEX 문도 함께 저장📌 대규모 DB에서 물리 백업을 쓰는 이유
❗ 설정과 책임은 사용자에게 있음
- 보존 기간
- 백업 주기
- 복구 테스트 여부
전부 엔지니어 책임
- 백업 스크립트
- 스케줄링(cron)
- 외부 저장소(S3, NFS)
- 암호화