데이터베이스는 대부분의 서비스에서 핵심 자산이며, 사용자 정보, 주문 내역, 결제 기록 등 손실 시 복구가 불가능하거나 심각한 비즈니스 피해를 야기할 수 있는 정보를 담고 있습니다. 하드웨어 장애, 실수로 인한 데이터 삭제, 랜섬웨어 공격, 소프트웨어 버그 등은 언제든 발생할 수 있으며, 이때 정기적인 백업 없이는 서비스를 정상 상태로 복구하기 어렵습니다. 백업은 단순한 보안책이 아니라, 서비스의 신뢰성과 연속성을 보장하는 가장 기본적인 안전망입니다.
이번 포스트에서는 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) 저장소에 백업 파일을 전송하는 방법을 알아보겠습니다.