MariaDB의 백업 방식 중 가장 많이 사용하는 mysqldump와 mariabackup 방식을 비교해보자.

mysqldump?
mysqldump는 MySQL과 MariaDB에서 가장 기본적으로 제공되는 논리(Logic) 백업 도구이다.
즉, 데이터베이스의 실제 파일을 복사하는 것이 아니라, 데이터베이스의 구조와 데이터를 SQL 문 형태로 추출하는 방식이다.
기본 사용 방법
[전체 데이터베이스 백업]
mysqldump -u root -p testdb > testdb_backup.sql
[특정 테이블만 백업]
mysqldump -u root -p testdb test_table1 test_table2 > test_table_partial.sql
[복구]
mysql -u root -p testdb < testdb_backup.sql
주요 옵션은 다음과 같다.
| 옵션 | 설명 |
| --single-transaction | 트랜잭션 단위로 백업 (InnoDB용, 락 없이 백업 가능) |
| --routines | 저장 프로시저, 함수 포함 |
| --triggers | 트리거 포함 |
| --no-data | 데이터 없이 스키마만 백업 |
| --where | 특정 조건에 맞는 데이터만 백업 |
장점
- 간단하고 직관적이다.
- SQL 문으로 추출되기 때문에 이식성이 매우 높다.
- 테이블 단위 복구가 가능하다.
- MariaDB뿐 아니라 MySQL, Percona 등 여러 엔진 간 버전 호환성이 좋다.
단점
- 대용량 데이터에서는 속도가 느리다.
- SQL 파싱 및 인덱스 재생성으로 인해 복구 시간이 오래 걸린다.
- Binary log, Redo log 기반 정합성은 보장하지 못한다.
- 테이블이 많거나 데이터가 클수록 서버 부하(CPU/I/O) 가 커진다.
mariabackup?
mariabackup은 MariaDB에서 제공하는 물리(Physical) 백업 도구이다.
mysqldump가 SQL 문을 생성해 데이터를 논리적으로 추출하는 방식이라면, mariabackup은 실제 데이터 파일(.ibd, .frm 등)을 통째로 복사하는 백업 방식이다.
mariabackup은 InnoDB 엔진 전용으로 설계되었으며, Percona의 xtrabackup을 기반으로 MariaDB용으로 개선된 버전이다.
기본 사용 방법
[전체 백업]
mariabackup --backup --target-dir=/backup/full --user=root --password=pass
| 옵션 | 의미 |
| --backup | 백업 모드로 실행 (기본) |
| --target-dir | 백업 결과를 저장할 디렉터리 지정 |
| --user, --password | DB 접속 계정 정보 |
| --databases | 특정 DB만 백업하고 싶을 때 사용 (예: --databases "appdb testdb") |
| --stream=xbstream | 파일로 직접 저장하지 않고 스트림 형태로 출력 (압축 백업 시 사용) |
| --compress | 데이터 파일을 압축하며 백업 (공간 절약, 속도는 다소 느림) |
| --parallel=N | 병렬 스레드 개수 지정 (멀티코어 환경에서 속도 향상) |
[증분 백업]
기존 백업 이후 변경된 데이터만 추가로 백업할 수 있다.
mariabackup --backup \
--target-dir=/backup/inc1 \
--incremental-basedir=/backup/full \
--user=root --password=pass
| 옵션 | 의미 |
| --incremental-basedir | 이전(기준) 백업 경로 지정 |
| --incremental | 증분 백업 모드로 실행 (보통 자동 적용됨) |
[백업 검증 - prepare 단계]
백업 파일은 그대로 쓸 수 없고, redo log를 적용해 일관된 상태로 복원준비를 해야한다.
cf. redo log 는 InnoDB 엔진이 데이터 정합성을 보장하기 위해 사용하는 로그 파일이다.
트랜잭션이 아직 디스크에 완전히 써지기 전에 기록해 두는 안전 장치다.
mariabackup --prepare --target-dir=/backup/full_2025_11_05
[증분 백업 병합 과정]
만약 증분 백업이 있다면, 두 단계를 거쳐 병합해야 한다.
mariabackup --prepare --apply-log-only --target-dir=/backup/full_2025_11_05
- 전체 백업의 redo log만 재적용하고,
- 증분 병합은 하지 않는다.
mariabackup --prepare --target-dir=/backup/full_2025_11_05 --incremental-dir=/backup/inc1
- /backup/inc1에 있는 LSN 이후 변경된 InnoDB 페이지를
/backup/full_2025_11_05의 실제 데이터 파일에 덮어쓴다. - 각 테이블별 .ibd 파일이 업데이트된다.
- checkpoint LSN이 증분 백업 시점으로 갱신된다.
위 과정들을 통해 전체 백업 디렉터리가 최종적으로 증분 백업 시점의 완전한 데이터베이스 복제본이 되는 것이다.
증분 병합이 끝나면 한 번 더 최종 정합성을 맞추는 --prepare를 수행한다.
mariabackup --prepare --target-dir=/backup/full_2025_11_05
[복구]
복구할 때는 다음과 같이 복구한다.
systemctl stop mariadb
rsync -avr /backup/full_2025_11_05/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
systemctl start mariadb
- mariadb 중지
- 기존 /var/lib/mysql 데이터 백업
- 백업 디렉터리(target-dir) 내용을 복사
- 권한(mysql:mysql) 복구
- 서비스 재시작
장점
- 대규모 운영 DB에도 빠르고 안정적이다.
- 증분 백업 및 무중단 백업이 가능하다.
- 복구 시 redo log 기반 트랜잭션 정합성 보장
- I/O 효율이 높고 CPU 부하가 적음
단점
- InnoDB 엔진만 완전 지원한다.
- 백업 결과물이 파일 단위라서,
테이블 하나만 복원하기는 어렵다. - --prepare 및 권한 설정(chown) 등 복구 절차가 mysqldump보다 복잡하다.
- MariaDB 버전 차이에 따른 호환성 문제 발생 가능
mysqldump vs mariabackup
| 항목 | mysqldump | mariabackup |
| 백업 방식 | 논리(SQL 기반) | 물리(파일 기반) |
| 속도 | 느림 | 빠름 |
| 정합성 | 낮음 (트랜잭션 단위) | 높음 (redo log 기반) |
| 증분 백업 | 불가 | 가능 |
| 복구 범위 | 테이블 단위 | 인스턴스 단위 |
| 이식성 | 높음 | 낮음 |
| 권장 용도 | 개발, 테스트, 마이그레이션 | 운영, 대용량 백업 |