
데이터베이스는 대부분의 서비스에서 핵심 자산이며, 사용자 정보, 주문 내역, 결제 기록 등 손실 시 복구가 불가능하거나 심각한 비즈니스 피해를 야기할 수 있는 정보를 담고 있습니다. 하드웨어 장애, 실수로 인한 데이터 삭제, 랜섬웨어 공격, 소프트웨어 버그 등은 언제든 발생할 수 있으며, 이때 정기적인 백업 없이는 서비스를 정상 상태로 복구하기 어렵습니다. 백업은 단순한 보안책이 아니라, 서비스의 신뢰성과 연속성을 보장하는 가장 기본적인 안전망입니다.
이번 포스트에서는 MySQL에서 제공하는 mysqldump를 활용하여 MySQL DB를 백업하고 복원하는 방법에 대해 알아보겠습니다.
데이터베이스 백업은 목적과 방식에 따라 다음과 같이 나뉩니다:
| 백업 유형 | 설명 |
|---|---|
| 전체 백업 | 데이터베이스 전체를 백업. 복원이 가장 간단하나, 백업 시간이 오래 걸릴 수 있음. |
| 차등 백업 | 마지막 전체 백업 이후 변경된 데이터만 백업. 전체 백업과 함께 사용됨. |
| 증분 백업 | 마지막 백업(전체 또는 증분) 이후 변경된 데이터만 백업. 저장 공간 효율적이지만 복원 복잡도가 높음. |
| 논리 백업 | SQL 쿼리 형식으로 덤프 (mysqldump, pg_dump 등). 이식성과 가독성이 좋음. |
| 물리 백업 | 실제 데이터 파일을 복사 (xtrabackup, LVM snapshot, 디스크 복사 등). 대용량에 적합하며 성능 손실이 적음. |
mysqldump로 백업하기mysqldump -u [사용자명] -p --all-databases > all-databases.sql
mysqldump -u [사용자명] -p [데이터베이스명] > database.sql
mysqldump -u [사용자명] -p [데이터베이스명] table1 table2 > partial.sql
| 옵션 | 설명 |
|---|---|
--single-transaction | InnoDB 사용 시 전체 일관된 상태로 백업 |
--quick | 메모리 절약을 위해 row 단위로 읽기 |
--routines | 저장 프로시저 포함 |
--triggers | 트리거 포함 (기본값: 포함됨) |
--set-gtid-purged=OFF | GTID 복제 환경에서 권장 |
mysqldump -u root -p --single-transaction --quick --routines mydb > mydb.sql
백업 파일은 용량이 크기 때문에 압축하는 것이 일반적입니다.
gzip mydb.sql
# 결과: mydb.sql.gz
복원 전에는 압축을 해제해야 합니다.
gunzip mydb.sql.gz
mysqldump로 복원하기복원은 단순히 mysql 클라이언트를 통해 백업 SQL 파일을 실행하면 됩니다.
mysql -u [사용자명] -p [대상DB명] < mydb.sql
주의: 복원 전에 DB가 생성되어 있어야 합니다. 없다면 먼저 생성합니다.
CREATE DATABASE mydb;
mysqldump의 강력한 기능 덕분에 데이터베이스의 백업과 복원을 쉽고 빠르게 할 수 있게되었습니다. 다만, mysqldump로 생성된 백업 파일들이 서비스와 동일한 서버에 보관될 경우, 서버에 문제가 발생 시 복원에 필요한 파일에도 접근이 불가능한 문제가 발생할 수 있습니다. 때문에 NAS나 S3같은 별도의 저장소에 백업 파일을 보관하는 것이 일반적입니다.
다음 포스트에서는 AWS CLI를 활용하여 S3(NCP Object Storage) 저장소에 백업 파일을 전송하는 방법을 알아보겠습니다.