데이터베이스 백업, 어떻게 복구할 것인가?

※주의 !!! 아래 작업은 실 운영서버에 바로 적용하는 것이 아닌 충분한 테스트 및 SQL에 대한 이해를 가진 후 작업을 권장드립니다.

1. DB 복원은 백업보다 어렵다

데이터베이스는 단순한 파일이 아니다.
동시에 수많은 사용자가 접근하고, 실시간으로 변경되며,
무결성과 트랜잭션 일관성을 유지해야 하는 동적 구조체다.

따라서 DB 복원은 일반적인 파일 복원보다 훨씬 더 복잡하고,
백업 파일이 있다고 해서 무조건 복원이 가능한 것도 아니다.
복구는 백업 방식, 트랜잭션 처리 상태, 의존성까지 고려해야 하는 정교한 작업이다.

 

2. 백업 방식에 따른 복원 전략

DB 복원은 사용한 백업 방식에 따라 절차가 크게 달라진다.
실무에서 주로 사용하는 MySQL, PostgreSQL을 기준으로 정리해보자.

1) 논리적 백업 (Dump 방식)

• mysqldump, pg_dump로 생성한 SQL 텍스트 파일
• 장점: 이식성과 유연성이 좋음
• 단점: 대용량 복원 시 속도 느림, 트랜잭션 복구 어려움

# MySQL 덤프
mysqldump -u root -p mydb > mydb.sql
mysql -u root -p mydb < mydb.sql

# PostgreSQL 덤프
pg_dump mydb > mydb.pgsql
psql mydb < mydb.pgsql

 

2) 물리적 백업 (데이터 파일, Tablespace 복사)

• 실제 데이터 디렉토리를 직접 백업하거나, 특정 tablespace를 백업
• 장점: 복원이 빠름, 인덱스 등 구조 보존
• 단점: 버전 호환성과 환경 의존도 높음

rsync -avz /var/lib/mysql /backup/mysql

→ 복원 시에는 권한, 소유자, 버전 동기화에 주의해야 한다.

 

3) 바이너리 로그 기반 시점 복구

• MySQL: binlog, PostgreSQL: WAL
• 장애 시점 직전까지의 트랜잭션을 재생하여 복원 가능
• 장점: 시점 복구(PITR: Point-in-time Recovery) 가능
• 단점: 설정되지 않은 경우 복구 불가

mysqlbinlog binlog.000001 | mysql -u root -p

 

 

→ 복구 시 시작 시점 지정이 중요 (--start-position, --stop-datetime 등)

 

3. 실무 복원 시나리오

시나리오 A: 전체 데이터베이스 복구

• DB 서버 전체 장애 → OS 재설치 후 DB 복구
• 덤프 파일 또는 물리 백업 활용
• 주의: 사용자 계정, 권한 복구도 함께 필요

시나리오 B: 테이블 단위 복원

• 특정 테이블만 덤프 백업하거나 복원
• --no-create-info, --tables 옵션 활용
• 인덱스, 외래키, 의존성 관계 함께 고려해야 함

시나리오 C: 특정 시점 복구

• 바이너리 로그 활성화된 환경
• --start-datetime, --stop-datetime 기준으로 binlog 복원
• 장애 직전 트랜잭션만 롤백 가능
  
  

4. 복구 절차 예시 및 주의사항

복원 절차 순서 (MySQL 기준)

1. 백업본 위치 확인 및 유효성 검사 (파일 크기, 해시 등)
2. 기존 DB 삭제 또는 빈 DB 생성
3. 복원 실행 (mysql < mydb.sql)
4. 사용자 계정 및 권한 재등록
5. 서비스 재시작 및 상태 확인

주의사항:

• 외래키 제약조건은 복원 시 일시 비활성화 가능
• 트랜잭션 로그 복원 시 중복 적용 주의
• 물리 복원 시 디렉터리 권한, SELinux 설정 확인 필요
  
  

5. 복구 후 무결성 점검 항목

• 테이블 수/레코드 수 일치 확인
• 사용자 계정과 권한 정상 작동 여부
• View, Trigger, Procedure 정상 여부
• 연결 애플리케이션과의 연동 테스트
• 로그 확인 (mysql.err, pg_log, journalctl 등)
  
  

결론

데이터베이스는 단순한 데이터가 아니다.
그건 복잡한 논리 구조와 트랜잭션 일관성의 집합체다.
따라서 복원은 ‘파일 복사’가 아니라 ‘복구 설계’로 접근해야 한다.

무엇을 복원할 것인지,
어느 시점까지 살릴 것인지,
복원 후 무엇을 점검할 것인지가 없다면
DB 백업은 종이호랑이에 불과하다.

오늘 당신의 DB 백업,

복구까지 설계되어 있는가?