"백업은 매일 돈다"는 말과 "원하는 시점으로 복구할 수 있다"는 전혀 다른 이야기입니다. 어제 새벽 백업만 있으면, 오늘 오후 실수로 지운 테이블을 복구할 때 오늘 하루치 데이터를 통째로 잃습니다. 백업 종류와 복구 시점을 구분해 설계해야 하는 이유입니다.
백업 세 가지를 구분한다
| 종류 | 방법 | 특징 | 언제 |
|---|---|---|---|
| 논리 백업 | mysqldump, mysqlpump | SQL 텍스트, 이식성 좋음, 느림 | 수십 GB 이하, 버전·서버 이동 |
| 물리 백업 | Percona XtraBackup, 파일 스냅샷 | 데이터 파일 복사, 빠름 | 수백 GB 이상, 빠른 복구 |
| PITR(시점 복구) | 전체 백업 + 바이너리 로그 | 특정 시각으로 되돌림 | 실수 삭제 복구의 핵심 |
PITR은 별도 백업이 아니라 전체 백업 한 벌 + 그 이후의 바이너리 로그를 합쳐 원하는 시점까지 재생하는 방식입니다. 그래서 binlog가 켜져 있어야 합니다.
SQL
SHOW VARIABLES LIKE 'log_bin'; -- ON 이어야 PITR 가능
논리 백업과 복구
DB 클라이언트
# 백업 (트랜잭션 일관성 + 시점 기록)
mysqldump --single-transaction --source-data=2 \
--databases app > app_2026-11-02.sql
# 복구
mysql app < app_2026-11-02.sql
--single-transaction은 InnoDB를 락 없이 일관된 스냅샷으로 덤프하고, --source-data=2는 백업 시점의 binlog 위치를 주석으로 남겨 PITR의 출발점이 됩니다.
PITR — 실수 시점 직전까지
전체 백업을 복구한 뒤, 그 시점부터 사고 직전까지만 binlog를 재생합니다.
DB 클라이언트
# 14:59:50에 DROP TABLE 사고 → 그 직전까지만 적용
mysqlbinlog --stop-datetime="2026-11-02 14:59:49" \
mysql-bin.000045 | mysql app
--stop-datetime 대신 정확한 위치를 알면 --stop-position을 씁니다. 사고 트랜잭션만 건너뛰려면 --start-position/--stop-position으로 구간을 잘라냅니다.
점검 체크리스트
로컬 터미널
SHOW VARIABLES LIKE 'log_bin'; # PITR 전제 조건
mysqldump --single-transaction ... # 일관된 논리 백업
# 복구 리허설 — 검증 안 한 백업은 백업이 아니다
mysql --force restore_test < app_2026-11-02.sql
mysqlbinlog --stop-datetime=... | mysql app # 시점 복구
가장 중요한 건 복구 리허설입니다. 한 번도 복구해본 적 없는 백업은 사고 당일 처음 열어보게 되고, 그때 깨져 있으면 끝입니다.
백업을 직접 떠보고 일부러 데이터를 지운 뒤 시점 복구로 되살리는 실습은 데이터베이스 트랙에서 회원가입 없이 무료로 할 수 있습니다.