MySQL에서 사용되는 기본적인 백업 유틸리티는 mysqldump이다. 하지만 mysqldump는 대용량 데이터 백업/복구에 있어 느린 속도가 발목을 잡는다.
이러한 mysqldump의 단점을 보완한 유틸리티가 XtraBackup이다.
XtraBackup은 Percona에서 개발된 오픈소스로 백업 도구이다.
mysqldump는 테이블 생성, 데이터 쿼리에 대한 SQL 생성문을 갖는 논리적 백업이라면 XtraBackup은 엔진 데이터를 그대로 복사하는 물리적 백업 방식이다.
create, insert 등의 SQL 쿼리문을 사용한 논리적 백업 방식이다.이러한 XtraBackup은 MySQL 엔터프라이즈 라이센스에 포함된 백업 도구의 기능을 모두 제공할 뿐만 아니라 더 유용한 기능들도 제공한다.
XtraBackup의 백업 방식은 크게 전체 백업, 증분 백업, 개별(DB, TABLE) 백업, 압축(qpress) 백업, Encrypted 백업이 있다. 또한 stream을 지원하기 때문에 파이프(|)를 통하여 다른 프로그램의 표준 입력으로 리다이렉션이 가능하다. 이를 통해 상황에 맞는 복잡한 백업/복구 로직을 작성할 수 있다.
mysqldump xtrabackup 백업 방식 SQL 스크립트(insert, create 등) 내보내기 방식 데이터 파일 자체를 복사 무중단 방식 InnoDB는 --single-transaction옵션을 사용하여 무중단 백업 가능
MyISAM은 별도 락 필요기본적으로 InnoDB 무중단 백업 가능
MyISAM은 별도 락 필요속도 비교적 느림 비교적 빠름 디스크 사용 용량 상대적으로 적게 사용 데이터 용량만큼 사용 호환성 Window, Linux, macOS 등 Linux 전용 설치 여부 MySQL 기본 내장(별도 설치X) 별도 설치 필요(Percona 패키지) 증분 백업 지원 X 지원 O 장점 간단함, 높은 이식성 빠른 속도, 무중단, 대용량 데이터 작업 단점 느림, DB 락이 걸릴 수 있음 복잡한 과정, 추가 패키지 설치, 디스크 사용량 증가
MySQL 서버(CentOS 10, MySQL 8.4.2 CentOS 9, MySQL 8.0.41)에 맞는 XtraBackup 8.0 버전을 설치한다.
2025.07.05 기준 CentOS 10 버전에 맞는 XtraBackup 버전이 없어 CentOS 9를 설치 사용, 이에 맞게 임시로 MySQL 8.0.41 사용
MySQL 5.x 이하일 때는 XtraBackup 2.x을 설치 사용 (XtraBackup 2.4 는 단종...)
MySQL 8.0.x 이상일 때는 XtraBackup 8.0을 설치 사용
MySQL 8.4.x 이상인 경우 XtraBackup 8.4를 설치하여 사용하면 된다.
[XtraBackup 설치]
# Percona yum 저장소 설치 $ sudo dnf install https://repo.percona.com/yum/percona-release-latest.noarch.rpm# 저장소 활성화 $ sudo percona-release enable pxb-80# Percona XtraBackup 설치 $ sudo dnf install percona-xtrabackup-80# zstd 압축 알고리즘 설치 (선택 사항) $ sudo dnf install zstd[XtraBackup 설치 확인]
# 아래 명령어가 실패한 경우 설치가 완료되지 않았거나 잘못되었다는 뜻 $ xtrabackup --version
Percona XtraBackup 8.0 기준으로 아래와 같은 바이너리 유틸리티를 제공한다.
XtraBackup는 다양한 유틸을 제공하지만 가장 많이 사용하는
xtrabackup유틸을 대표로 사용해볼 예정이다.[xtrabackup 주요 옵션]
- --backup : 특정 디렉터리에 데이터베이스 백업
- --prepare : --backup으로 생성된 백업 데이터를 복구하는 모드(복구 모드로 전환)
- --copy-back : 백업된 데이터를 실제 디렉터리에 복구
- 복구하려는 디렉터리에 데이터가 있는경우 운영 체제 오류 17과 함께 실패한다. 때문에 디렉터리를 비우고 실행하는 것을 권장
- --move-back : 백업된 데이터를 원래 위치로 복구+이동 (백업 데이터는 삭제)
- 복구하려는 디렉터리에 데이터가 있는경우 운영 체제 오류 17과 함께 실패한다. 때문에 디렉터리를 비우고 실행하는 것을 권장
- --stats : 지정된 데이터 파일을 스캔하고 인덱스 통계 출력
- --target-dir : 백업 데이터를 저장할 디렉터리 지정 (디렉터리가 없는 경우 xtrabackup이 디렉터리를 생성)
- --no-lock : 백업하는 동안 테이블 락 없이 작업 진행 (InnoDB 에서만 사용 가능)
[데이터베이스 통 백업]
백업하는 동안 table lock 없이 백업을 진행하려면--no-lock옵션을 추가해야 한다. 단 이는 InnoDB에서만 사용 가능하다.# 백업 대상 : /etc/my.cnf # 백업 데이터 저장소 : /backup/xtrabackup_20250702 xtrabackup --backup \ --defaults-file=/etc/my.cnf \ --no-lock \ --target-dir=/backup/xtrabackup_20250702 \ --user=<DB 사용자명> \ --password=<DB 사용자 비밀번호> \[데이터베이스 통 복구]
데이터베이스를 통 복구할 때는 데이터베이스에 데이터가 없어야 하며, MySQL 서비스를 종료해야 한다.
(만약 서버에 데이터가 남아 있는 경우 에러가 발생하면서 복구에 실패한다)# 백업 준비(복구 모드) xtrabackup --prepare \ --target-dir=/backup/xtrabackup_20250702# MySQL 서버 중지 systemctl stop mysqld# MySQL 서버 데이터 이름변경을 통한 백업(혹시 모를 장애 대비) mv /var/lib/mysql /var/lib/mysql_bak_$(date +%Y%m%d_%H%M)# 데이터 복구 xtrabackup --copy-back \ --target-dir=/backup/xtrabackup_20250702# 소유권 수정 chown -R mysql:mysql /var/lib/mysql# MySQL 서버 시작 systemctl start mysqld

sys, performance_schema, information_schema 제외 대략 2.45 GB의 데이터를 백업/복구하는 데 있어 아래와 같은 속도 차이가 있었다.
mysqldump는 sys, performance_schema, information_schema 데이터베이스의 정보만을 백업한다. 즉, 완전한 백업이 아니다.[mysqldump 백업]
mysqldump명령어로 백업을 진행한 경우 총 33.810초가 소요되었음을 확인 할 수 있었다.
[XtraBackup 백업]
중간 백업 로드 과정 이미지 생략
xtraBackup명령어로 백업을 진행한 경우 총 9.006초가 소요되었음을 확인 할 수 있었다.
[mysqldump 복구]
mysqldump명령어로 복구을 진행한 경우 282.203(약 4분 42초)초가 소요되었음을 확인 할 수 있었다.
[XtraBackup 복구]
1. 백업 준비(복구 모드)
백업 준비 로드 과정 이미지 생략
백업 준비에 2.647초 소요
2. 데이터 복구
데이터 복구 로드 과정 이미지 생략
데이터 백업에 4.083초 소요
xtraBackup명령어로 복구을 진행 한 경우 총합(복구 준비 + 데이터 백업) 6.73초가 소요되었음을 확인 할 수 있었다.
MySQL 서버에서 sys, performance_schema, information_schema 데이터베이스를 제외한 약 2.45 GB의 데이터를 기준으로 아래와 같은 결과를 확인할 수 있었다.
| 단위 : 초 | mysqldump | XtraBackup |
|---|---|---|
| 백업 | 33.810 | 9.006 |
| 복구 | 282.203 | 6.73 |
백업의 경우 XtraBackup 방식이 약 3.75배 더 빠르며,
복구의 경우 XtraBackup 방식이 약 41.9배 더 빨랐다.