백업, 복구, 마이그레이션

백업의 목적은 파일 보관이 아니다

백업을 했다는 말은 안심을 주지만, 실제 장애 상황에서는 한 가지 질문만 남습니다. "지금 이 백업으로 서비스를 복구할 수 있는가?"

백업 파일이 있어도 복원 명령을 모르면 소용없습니다. 복원은 되지만 너무 오래 걸리면 서비스 장애가 길어집니다. 백업 파일이 깨져 있거나, 필요한 바이너리 로그가 없거나, 계정과 권한이 빠져 있어도 복구는 실패할 수 있습니다.

그래서 백업 전략은 다음 순서로 세워야 합니다.

1. 얼마나 잃어도 되는가

2. 얼마나 빨리 복구해야 하는가

3. 어떤 방식으로 백업할 것인가

4. 어디에, 얼마나 오래 보관할 것인가

5. 실제로 복구되는지 어떻게 검증할 것인가

여기서 핵심이 RPO와 RTO입니다. RPO는 장애가 났을 때 허용 가능한 최대 데이터 손실 범위입니다. 예를 들어 하루 한 번 새벽에만 백업한다면, 최악의 경우 하루치 데이터를 잃을 수 있습니다. RTO는 장애가 난 뒤 서비스를 다시 사용할 수 있게 만들기까지의 목표 시간입니다. Percona의 백업 가이드도 백업 주기와 도구 선택을 RPO와 RTO에서 시작해야 한다고 설명합니다.¹

쇼핑몰 주문 데이터처럼 손실이 거의 허용되지 않는 데이터는 짧은 RPO가 필요합니다. 반대로 하루 단위로 갱신되는 내부 통계 데이터라면 RPO가 조금 길어도 됩니다. 모든 데이터에 같은 백업 정책을 적용하면 비용은 늘고, 정작 중요한 데이터는 충분히 보호하지 못할 수 있습니다.

AI 생성 이미지

논리 백업과 물리 백업

MySQL 백업은 크게 논리 백업과 물리 백업으로 나눌 수 있습니다.

논리 백업은 데이터베이스 구조와 데이터를 SQL 문장 형태로 내보내는 방식입니다. 대표 도구가 mysqldump입니다. 백업 파일 안에는 CREATE TABLE, INSERT 같은 SQL이 들어갑니다. 이 방식은 사람이 읽을 수 있고, 다른 MySQL 환경으로 옮기기 쉽습니다. 특정 데이터베이스나 특정 테이블만 복원하기도 비교적 편합니다.

하지만 데이터가 커질수록 백업과 복원이 느려집니다. SQL 문장을 다시 실행해 테이블을 만들고 데이터를 넣어야 하기 때문입니다. 수십 GB까지는 관리할 만해도, 수백 GB나 TB 단위 운영 데이터베이스라면 복원 시간이 문제가 될 수 있습니다.

물리 백업은 MySQL이 실제로 사용하는 데이터 파일과 로그 파일을 복사하는 방식입니다. Percona XtraBackup, 스토리지 스냅샷, 클라우드 스냅샷 같은 방식이 여기에 가깝습니다. 물리 백업은 보통 복구 속도가 빠르고, 대용량 데이터베이스나 새 복제 서버를 빠르게 만들 때 유리합니다. 대신 MySQL 버전, 저장 엔진, 파일 구조의 영향을 더 많이 받습니다. 가능하면 같은 MySQL 버전에서 복원하는 것이 안전합니다.

간단히 정리하면 다음과 같습니다.

처음 MySQL을 배우는 단계에서는 mysqldump를 먼저 익히는 것이 좋습니다. 명령이 단순하고, 백업 파일의 내용을 확인할 수 있으며, 다른 환경으로 데이터를 옮기는 흐름을 이해하기 쉽습니다.

mysqldump로 백업하기

mysql_book 데이터베이스를 백업해 보겠습니다.

mysqldump -u study_user -p \
  --default-character-set=utf8mb4 \
  --single-transaction \
  --routines --triggers --events \
  mysql_book > mysql_book_backup.sql

옵션의 의미는 다음과 같습니다.

• --default-character-set=utf8mb4: 한글과 이모지를 안전하게 다루기 위해 문자셋을 지정합니다.

• --single-transaction: InnoDB 테이블을 백업할 때 일관된 시점의 데이터를 가져옵니다.

• --routines: 저장 프로시저와 함수를 포함합니다.

• --triggers: 트리거를 포함합니다.

• --events: 이벤트 스케줄러 객체를 포함합니다.

전체 데이터베이스가 아니라 특정 테이블만 백업할 수도 있습니다.

mysqldump -u study_user -p mysql_book students > students_backup.sql

백업 파일은 압축해서 보관하는 것이 일반적입니다.

gzip mysql_book_backup.sql

운영 환경에서는 백업 파일에 개인정보나 민감 정보가 들어 있을 수 있습니다. 백업 파일도 데이터베이스와 같은 수준으로 보호해야 합니다. 외부 저장소에 보관한다면 암호화를 고려해야 하고, 암호화 키나 비밀번호를 잃어버리지 않도록 별도로 관리해야 합니다. 키가 없으면 백업 파일은 있어도 복구할 수 없습니다.

백업 파일 복원하기

복원은 운영 데이터베이스에 바로 하지 않는 것이 원칙입니다. 먼저 별도 데이터베이스나 테스트 서버에 복원해 파일이 정상인지 확인해야 합니다.

CREATE DATABASE mysql_book_restore
  DEFAULT CHARACTER SET utf8mb4
  DEFAULT COLLATE utf8mb4_0900_ai_ci;

그다음 백업 파일을 복원합니다.

mysql -u study_user -p mysql_book_restore < mysql_book_backup.sql

복원 후에는 단순히 명령이 끝났는지만 보지 말고 데이터를 확인해야 합니다.

USE mysql_book_restore;

SHOW TABLES;

SELECT COUNT(*) FROM students;
SELECT * FROM students ORDER BY id LIMIT 5;

실무에서는 테이블 개수, 주요 테이블의 행 수, 핵심 조회 쿼리 결과를 원본과 비교합니다. 금액 합계나 주문 건수처럼 업무적으로 중요한 값도 확인해야 합니다.

다른 서버로 옮길 때는 몇 가지 문제가 자주 발생합니다.

첫째, 문자셋과 콜레이션 차이입니다. 원본은 utf8mb4인데 대상 서버가 다른 문자셋을 기본값으로 사용하면 한글이나 이모지가 깨질 수 있습니다. 데이터베이스를 만들 때 문자셋을 명시하고, 덤프와 복원 명령에도 문자셋 옵션을 지정하는 습관이 좋습니다.

둘째, 계정과 권한입니다. 데이터베이스 백업에는 보통 MySQL 사용자 계정과 권한이 자동으로 모두 포함되지 않습니다. 애플리케이션 계정, 읽기 전용 계정, 백업 계정은 대상 서버에서 별도로 만들어야 합니다.

셋째, DEFINER 문제입니다. 뷰, 프로시저, 트리거에는 생성자 정보가 들어갈 수 있습니다. 대상 서버에 해당 계정이 없으면 복원 후 실행 오류가 날 수 있습니다. 마이그레이션 전에 덤프 파일의 DEFINER를 점검하거나, 대상 서버에 필요한 계정을 준비해야 합니다.

넷째, 버전 차이입니다. MySQL 5.7에서 만든 덤프를 MySQL 8.0에 복원하거나 반대로 복원할 때 문법, 인증 방식, 기본 콜레이션 차이가 문제가 될 수 있습니다. 운영 이전에는 반드시 같은 조건으로 리허설해야 합니다.

전체 백업, 증분 백업, 바이너리 로그

전체 백업은 특정 시점의 데이터베이스 전체를 보관하는 방식입니다. 단순하고 복원이 쉽지만, 데이터가 커질수록 저장 공간과 시간이 많이 듭니다.

증분 백업은 마지막 백업 이후 변경된 부분만 저장하는 방식입니다. 대용량 데이터베이스에서 저장 공간과 백업 시간을 줄이는 데 도움이 됩니다. 하지만 복원할 때 전체 백업과 여러 증분 백업을 순서대로 적용해야 합니다. 중간 증분 백업 하나가 손상되면 이후 복원 체인이 깨질 수 있습니다. 그래서 증분 백업은 RPO에는 유리할 수 있지만, RTO를 나쁘게 만들 수도 있습니다.

MySQL에서 장애 직전이나 특정 시점까지 복구하려면 바이너리 로그가 중요합니다. 바이너리 로그는 데이터 변경 내용을 기록하는 로그입니다. 전체 백업이 새벽 2시에 있고 장애가 오전 10시에 났다면, 전체 백업만으로는 새벽 2시 상태까지만 돌아갈 수 있습니다. 하지만 새벽 2시 이후의 바이너리 로그를 보관하고 있다면 오전 9시 59분 같은 시점까지 변경 내용을 다시 적용할 수 있습니다. 이를 시점 복구, 즉 PITR이라고 합니다. Percona도 바이너리 로그 복사본을 함께 보관하면 마지막 트랜잭션에 가까운 지점까지 복구할 수 있다고 설명합니다.²

흐름은 다음과 같습니다.

1. 전체 백업을 복원한다.

2. 백업 이후의 바이너리 로그를 준비한다.

3. mysqlbinlog로 원하는 시점까지 SQL을 재생한다.

4. 데이터 정합성을 확인한다.

5. 애플리케이션 트래픽을 전환한다.

예시는 다음과 같습니다.

mysqlbinlog \
  --stop-datetime='2026-05-22 09:59:00' \
  binlog.000123 binlog.000124 \
  | mysql -u root -p mysql_book

실수로 오전 10시에 중요한 데이터를 삭제했다면, 삭제 직전 시점까지만 로그를 적용해야 합니다. 무조건 최신 로그까지 모두 적용하면 실수 삭제도 다시 적용됩니다.

마이그레이션 전에 확인할 것

마이그레이션은 단순히 백업 파일을 다른 서버에 복원하는 작업이 아닙니다. 개발, 테스트, 운영 환경 사이에서 데이터를 옮길 때도 계획이 필요합니다.

먼저 원본과 대상 서버의 저장 공간을 확인해야 합니다. 덤프 파일, 압축 해제 파일, 복원 중 생성되는 임시 파일, 인덱스 생성 공간까지 고려해야 합니다. AWS의 대용량 MySQL 마이그레이션 가이드도 원본과 대상 양쪽에 백업과 복원에 필요한 충분한 공간을 확보해야 한다고 강조합니다.³

다음으로 시간을 계산해야 합니다. 백업 시간, 네트워크 전송 시간, 복원 시간, 검증 시간을 모두 더해야 실제 작업 시간이 나옵니다. 100GB 파일을 만드는 시간보다 네트워크로 옮기는 시간이 더 오래 걸릴 수 있습니다. 복원 후 인덱스를 만드는 시간이 병목이 되기도 합니다.

운영 서버에서 직접 mysqldump를 실행하면 부하가 생길 수 있습니다. 가능하면 복제 서버에서 덤프를 뜨거나, 기존 백업을 임시 서버에 복원한 뒤 그곳에서 내보내는 방식이 안전합니다. 복제 서버나 백업이 없다면 사용량이 적은 시간대에 실행하고, 병렬 작업 수를 낮춰 운영 트래픽에 줄 영향을 줄여야 합니다.⁴

여러 독립 데이터베이스를 한 서버에 몰아넣을지도 검토해야 합니다. 서로 다른 서비스의 데이터베이스라면 분리된 인스턴스로 옮기는 편이 운영, 권한 관리, 장애 대응에 유리할 수 있습니다.

개발·테스트 환경으로 운영 데이터를 옮길 때는 개인정보 마스킹도 필요합니다. 이메일, 전화번호, 주소, 결제 관련 정보는 그대로 복사하지 않는 것이 원칙입니다. 개발자는 실제 고객 정보 없이도 기능을 검증할 수 있어야 합니다.

복원 테스트가 백업 전략의 완성이다

백업 정책의 마지막 단계는 복원 테스트입니다. 백업 파일이 존재하는지 확인하는 것은 충분하지 않습니다. 별도 환경에서 정기적으로 복원해 봐야 합니다.

복원 테스트에서는 다음을 확인합니다.

• 백업 파일이 손상되지 않았는가

• 문서화된 절차만 보고 복구할 수 있는가

• 복원 시간이 목표 RTO 안에 들어오는가

• 바이너리 로그까지 적용해 목표 RPO를 만족하는가

• 계정, 권한, 뷰, 트리거, 프로시저가 정상 동작하는가

• 애플리케이션이 복원된 DB에 접속해 핵심 기능을 수행할 수 있는가

Percona는 정기적인 복원 테스트와 복구 절차 문서화를 권장합니다. 자동으로 전체 복원을 수행하고, 복원된 서버를 복제 구성에 붙여 보는 방식은 백업 파일, 복구 시간, 복제 절차를 함께 검증하는 좋은 방법입니다.⁵

백업은 장애가 나기 전에는 비용처럼 보입니다. 그러나 장애가 난 뒤에는 서비스의 마지막 안전망입니다. 좋은 백업 전략은 화려한 도구보다 명확한 기준에서 출발합니다. RPO와 RTO를 정하고, 데이터 규모에 맞는 백업 방식을 선택하고, 바이너리 로그를 함께 보관하고, 별도 환경에서 반복해서 복원해 보는 것. 이 네 가지를 지키면 MySQL 운영에서 가장 큰 위험인 데이터 손실을 현실적으로 줄일 수 있습니다.

참고

¹MySQL Backup and Recovery Best Practices: The Ultimate Guide

²MySQL Backup and Recovery Best Practices: The Ultimate Guide

³Best practices for migrating large MySQL and MariaDB databases

⁴Best practices for migrating large MySQL and MariaDB databases

⁵MySQL Backup and Recovery Best Practices: The Ultimate Guide