카테고리 없음

MySQL 데이터베이스 백업 방법: mysqldump를 활용한 실전 백업과 복구

14722 2026. 8. 22. 15:38

리눅스 서버에서 웹사이트나 서비스를 운영하다 보면 데이터베이스 백업은 반드시 준비해야 하는 작업입니다.

서버 장애가 발생하거나 실수로 데이터를 삭제했을 때 백업 파일이 없다면 복구가 매우 어려울 수 있습니다.

특히 MySQL을 사용하는 서버라면 mysqldump 명령어를 이용해 데이터베이스를 파일로 백업하고 필요할 때 다시 복구할 수 있습니다.

mysqldump는 MySQL 데이터베이스의 구조와 데이터를 SQL 형태로 추출하는 도구입니다.

이번 글에서는 리눅스 서버에서 mysqldump를 이용해 MySQL 데이터베이스를 백업하는 방법부터 특정 데이터베이스 백업, 전체 데이터베이스 백업, 압축 백업, 복구 방법, 오류 해결, 자동 백업을 위한 기본적인 구성 방법까지 실무에서 바로 활용할 수 있도록 정리해보겠습니다.

1. MySQL 데이터베이스 백업이 중요한 이유

웹사이트에서 작성한 게시글이나 회원 정보, 주문 정보 등의 데이터가 데이터베이스에 저장되어 있다면 서버에 문제가 생겼을 때 데이터 손실이 발생할 수 있습니다.

예를 들어 다음과 같은 상황이 발생할 수 있습니다.

서버 디스크 고장
데이터베이스 파일 손상
잘못된 SQL 명령 실행
중요한 데이터 삭제
서버 이전
운영 중인 서비스 장애
업데이트 과정에서 발생하는 문제

이럴 때 별도의 백업 파일이 있다면 데이터를 다시 복구할 수 있습니다.

따라서 서버 운영에서는 백업 자체보다 실제로 복구할 수 있는 백업을 만들어두는 것이 중요합니다.

2. mysqldump란 무엇인가?

mysqldump는 MySQL에서 제공하는 데이터베이스 백업 도구입니다.

데이터베이스의 테이블 구조와 데이터를 SQL 명령 형태로 추출할 수 있습니다.

기본적인 사용 형태는 다음과 같습니다.

mysqldump -u 사용자명 -p 데이터베이스명 > backup.sql

예를 들어 데이터베이스 이름이 myblog라면:

mysqldump -u root -p myblog > myblog_backup.sql

명령어를 실행하면 MySQL 계정의 비밀번호를 입력하라는 메시지가 나타납니다.

백업이 완료되면 현재 디렉터리에:

myblog_backup.sql

파일이 생성됩니다.

3. mysqldump 명령어 기본 구조 이해하기

다음 명령어를 하나씩 살펴보겠습니다.

mysqldump -u root -p myblog > myblog_backup.sql

mysqldump

MySQL 데이터를 백업하는 프로그램입니다.

-u root

MySQL에 접속할 사용자 계정을 지정합니다.

-p

비밀번호를 입력하겠다는 의미입니다.

실행하면 비밀번호 입력 화면이 나타납니다.

myblog

백업할 데이터베이스 이름입니다.

> myblog_backup.sql

백업 결과를 myblog_backup.sql 파일로 저장합니다.

4. 특정 데이터베이스 백업하기

가장 많이 사용하는 방법입니다.

예를 들어 wordpress라는 데이터베이스를 백업한다고 가정해보겠습니다.

mysqldump -u root -p wordpress > wordpress_backup.sql

백업 파일이 생성됐는지 확인합니다.

ls -lh wordpress_backup.sql

파일 크기가 표시되면 백업 파일이 생성된 것입니다.

백업 파일의 내용을 간단하게 확인할 수도 있습니다.

head wordpress_backup.sql

SQL 문장이 들어 있다면 정상적으로 생성됐는지 확인하는 데 도움이 됩니다.

5. 백업 파일을 특정 디렉터리에 저장하기

서버에서는 백업 파일을 별도의 디렉터리에 모아 관리하는 것이 좋습니다.

예를 들어:

sudo mkdir -p /backup/mysql

그다음:

sudo mysqldump -u root -p wordpress > /backup/mysql/wordpress_backup.sql

백업 파일 확인:

ls -lh /backup/mysql/

결과 예:

wordpress_backup.sql

처럼 표시될 수 있습니다.

6. 날짜를 백업 파일 이름에 넣는 방법

백업 파일에 날짜를 넣어두면 언제 생성된 백업인지 쉽게 구분할 수 있습니다.

예를 들어:

mysqldump -u root -p wordpress > /backup/mysql/wordpress_$(date +%Y-%m-%d).sql

실행 날짜가 2026년 8월 22일이라면:

wordpress_2026-08-22.sql

같은 파일이 만들어집니다.

이 방법은 자동 백업 스크립트를 만들 때 특히 유용합니다.

7. MySQL 전체 데이터베이스 백업하기

서버에 여러 개의 데이터베이스가 있다면 전체 데이터베이스를 한 번에 백업할 수도 있습니다.

mysqldump -u root -p --all-databases > all_databases.sql

이 명령어는 MySQL 서버에 있는 여러 데이터베이스를 하나의 SQL 파일로 저장하는 방식입니다.

백업 파일 확인:

ls -lh all_databases.sql

데이터베이스가 많으면 백업 파일의 크기도 커질 수 있으므로 디스크 공간을 확인하는 것이 좋습니다.

df -h

8. 데이터베이스 구조만 백업하기

데이터는 제외하고 테이블 구조만 백업해야 하는 경우도 있습니다.

이때 --no-data 옵션을 사용할 수 있습니다.

mysqldump -u root -p --no-data wordpress > wordpress_structure.sql

이렇게 하면 테이블 구조를 확인하거나 새로운 서버에 데이터베이스 구조를 먼저 만드는 데 활용할 수 있습니다.

9. 데이터만 백업하기

반대로 테이블 구조를 제외하고 데이터 중심으로 백업해야 하는 경우도 있습니다.

환경에 따라 --no-create-info 옵션을 사용할 수 있습니다.

mysqldump -u root -p --no-create-info wordpress > wordpress_data.sql

실제 운영 환경에서는 구조와 데이터를 함께 백업하는 일반적인 mysqldump 방식이 가장 많이 사용됩니다.

10. MySQL 백업 파일 압축하기

데이터베이스가 커지면 SQL 백업 파일의 크기도 상당히 커질 수 있습니다.

이럴 때 gzip을 함께 사용하면 저장 공간을 줄이는 데 도움이 됩니다.

다음과 같이 사용할 수 있습니다.

mysqldump -u root -p wordpress | gzip > /backup/mysql/wordpress_backup.sql.gz

백업 파일은:

wordpress_backup.sql.gz

형태로 생성됩니다.

크기를 확인하려면:

ls -lh /backup/mysql/

압축 파일을 직접 해제하려면:

gzip -d wordpress_backup.sql.gz

그러면:

wordpress_backup.sql

파일로 돌아옵니다.

11. 압축을 풀지 않고 바로 복구하기

gzip으로 압축한 MySQL 백업 파일은 압축을 먼저 풀지 않고 바로 복구할 수도 있습니다.

예:

gunzip < wordpress_backup.sql.gz | mysql -u root -p wordpress

이 방식은 대용량 백업 파일을 다룰 때 유용할 수 있습니다.

다만 복구하기 전에 복구 대상 데이터베이스를 정확하게 확인하는 것이 매우 중요합니다.

12. MySQL 데이터베이스 복구하기

이제 가장 중요한 복구 방법을 알아보겠습니다.

먼저 복구할 데이터베이스가 존재하는지 확인합니다.

mysql -u root -p

MySQL에 접속한 후:

SHOW DATABASES;

를 실행합니다.

데이터베이스가 없다면 필요에 따라 생성합니다.

CREATE DATABASE wordpress;

MySQL을 종료합니다.

exit;

그리고 SQL 백업 파일을 복구합니다.

mysql -u root -p wordpress < wordpress_backup.sql

비밀번호를 입력하면 SQL 파일의 내용이 데이터베이스로 복원됩니다.

13. 압축된 백업 파일 복구하기

앞에서 만든:

wordpress_backup.sql.gz

파일을 바로 복구하려면:

gunzip < wordpress_backup.sql.gz | mysql -u root -p wordpress

이렇게 하면 별도의 SQL 파일로 압축을 풀지 않고 데이터베이스에 복구할 수 있습니다.

14. 복구 후 데이터 확인하기

복구가 완료됐다고 바로 작업을 끝내지 말고 데이터가 실제로 들어갔는지 확인하는 것이 좋습니다.

MySQL에 접속합니다.

mysql -u root -p wordpress

테이블 목록을 확인합니다.

SHOW TABLES;

특정 테이블의 데이터도 확인할 수 있습니다.

SELECT COUNT(*) FROM 테이블명;

실제 운영 데이터가 정상적으로 복구됐는지 확인하는 것이 중요합니다.

15. MySQL 사용자 계정까지 백업하려면?

특정 데이터베이스만 백업하면 해당 데이터베이스의 구조와 데이터 중심으로 저장됩니다.

서버 이전이나 전체 환경 복구가 목적이라면 데이터베이스 사용자와 권한 설정도 별도로 확인해야 합니다.

예를 들어 MySQL 계정 권한은 데이터베이스 백업과 별개의 관리 대상이 될 수 있습니다.

따라서 서버 이전을 준비한다면:

데이터베이스
+
사용자 계정
+
권한
+
MySQL 설정

을 함께 확인하는 것이 좋습니다.

16. 백업 파일에 비밀번호를 직접 입력하지 않는 이유

다음과 같이 명령어에 비밀번호를 직접 적는 방법도 있지만 권장하지 않습니다.

mysqldump -u root -pMyPassword wordpress > backup.sql

서버의 명령 기록이나 프로세스 정보 등에 민감한 정보가 노출될 가능성을 고려해야 합니다.

일반적으로 다음처럼 사용하는 것이 더 안전합니다.

mysqldump -u root -p wordpress > backup.sql

실행 후 비밀번호를 직접 입력합니다.

자동 백업을 구성할 때는 별도의 인증 설정이나 비밀정보 관리 방법을 사용하는 것이 좋습니다.

17. 백업 파일의 권한 확인하기

데이터베이스 백업 파일에는 중요한 정보가 들어 있을 수 있습니다.

따라서 백업 파일의 접근 권한도 확인해야 합니다.

ls -lh /backup/mysql/

필요한 경우 백업 디렉터리의 접근 권한을 제한합니다.

예:

sudo chmod 700 /backup/mysql

백업 파일 자체도 불필요한 사용자에게 읽기 권한이 없도록 관리하는 것이 좋습니다.

특히 회원정보나 개인정보 등이 포함된 데이터베이스라면 백업 파일 자체도 중요한 보안 자산으로 취급해야 합니다.

18. 백업 파일이 정상인지 확인하는 방법

백업 명령어가 실행됐다고 해서 무조건 복구 가능한 백업이라고 단정해서는 안 됩니다.

먼저 파일 크기를 확인합니다.

ls -lh wordpress_backup.sql

SQL 파일의 앞부분을 확인합니다.

head -n 20 wordpress_backup.sql

그리고 가장 중요한 것은 실제 복구 테스트입니다.

운영 데이터베이스에 바로 복구하기보다는 테스트용 데이터베이스를 만들어 백업 파일을 복구해보는 것이 안전합니다.

19. 테스트 데이터베이스에 복구하기

테스트용 데이터베이스를 생성합니다.

CREATE DATABASE wordpress_test;

그리고 백업 파일을 복구합니다.

mysql -u root -p wordpress_test < wordpress_backup.sql

복구 후:

mysql -u root -p wordpress_test

접속해서:

SHOW TABLES;

를 실행합니다.

테이블이 정상적으로 생성됐다면 백업 파일을 실제로 복구할 수 있는지 확인하는 데 도움이 됩니다.

20. MySQL 백업 자동화의 기본 원리

서버를 운영하면서 매번 수동으로 백업하는 것은 현실적으로 어렵습니다.

따라서 일반적으로 다음과 같은 구조를 사용합니다.

cron
  ↓
백업 스크립트 실행
  ↓
mysqldump
  ↓
SQL 백업 생성
  ↓
gzip 압축
  ↓
날짜별 파일 저장
  ↓
오래된 백업 삭제

예를 들어 백업 스크립트에서:

#!/bin/bash

BACKUP_DIR="/backup/mysql"
DB_NAME="wordpress"
DATE=$(date +%Y-%m-%d)

mysqldump -u root -p "$DB_NAME" | gzip > "$BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz"

와 같은 구조를 사용할 수 있습니다.

다만 자동 백업에서는 비밀번호를 스크립트에 평문으로 넣지 않는 등 인증정보 관리에 특히 주의해야 합니다.

21. 오래된 백업 파일 자동 삭제하기

백업을 매일 생성하면 파일이 계속 쌓이게 됩니다.

예를 들어 30일이 지난 백업을 정리하는 방식으로 보관 기간을 관리할 수 있습니다.

find /backup/mysql -type f -name "*.sql.gz" -mtime +30 -delete

이 명령은 조건에 맞는 오래된 압축 백업 파일을 삭제합니다.

하지만 -delete는 실제 파일을 삭제하므로 운영 서버에서 바로 사용하기 전에 검색 결과를 먼저 확인하는 습관이 중요합니다.

먼저:

find /backup/mysql -type f -name "*.sql.gz" -mtime +30

으로 삭제 대상 파일을 확인한 후 필요할 때 -delete를 사용하는 것이 안전합니다.

22. MySQL 백업에서 디스크 공간 확인하기

백업을 자동화할 경우 디스크 공간 부족 문제가 발생할 수 있습니다.

현재 디스크 사용량:

df -h

백업 디렉터리 용량:

du -sh /backup/mysql

하위 파일별 크기를 확인하려면:

du -sh /backup/mysql/*

이 명령어를 활용하면 어떤 백업 파일이 많은 공간을 차지하는지 쉽게 확인할 수 있습니다.

23. mysqldump 백업 시 자주 사용하는 옵션

실무에서 자주 접하게 되는 옵션을 정리해보겠습니다.

옵션의미

-u	MySQL 사용자 지정
-p	비밀번호 입력
--all-databases	전체 데이터베이스 백업
--no-data	데이터 없이 구조만 백업
--no-create-info	테이블 생성문 제외
--single-transaction	트랜잭션 기반 백업에 활용
--routines	저장 프로시저와 함수 포함
--triggers	트리거 포함
--events	이벤트 포함

특히 InnoDB 테이블을 사용하는 환경에서 서비스 중단을 줄이면서 논리 백업을 수행할 때 --single-transaction 옵션을 고려할 수 있습니다.

예:

mysqldump -u root -p --single-transaction wordpress > wordpress_backup.sql

다만 데이터베이스 구성과 스토리지 엔진에 따라 백업 전략을 검토해야 합니다.

24. 실무에서 사용할 수 있는 백업 명령어

일반적인 백업

mysqldump -u root -p wordpress > wordpress.sql

날짜를 포함한 백업

mysqldump -u root -p wordpress > wordpress_$(date +%Y-%m-%d).sql

압축 백업

mysqldump -u root -p wordpress | gzip > wordpress_$(date +%Y-%m-%d).sql.gz

전체 데이터베이스 백업

mysqldump -u root -p --all-databases > all_databases.sql

트랜잭션 기반 백업

mysqldump -u root -p --single-transaction wordpress > wordpress.sql

25. MySQL 백업과 복구 핵심 정리

백업:

mysqldump -u root -p wordpress > wordpress_backup.sql

복구:

mysql -u root -p wordpress < wordpress_backup.sql

압축 백업:

mysqldump -u root -p wordpress | gzip > wordpress_backup.sql.gz

압축 백업 복구:

gunzip < wordpress_backup.sql.gz | mysql -u root -p wordpress

전체 데이터베이스 백업:

mysqldump -u root -p --all-databases > all_databases.sql

디스크 공간 확인:

df -h

백업 디렉터리 용량 확인:

du -sh /backup/mysql

26. MySQL 백업에서 가장 중요한 5가지

MySQL 서버를 운영한다면 다음 5가지는 꼭 기억해두는 것이 좋습니다.

첫째, 정기적으로 백업하세요.

수동 백업보다는 자동 백업 시스템을 구축하는 것이 좋습니다.

둘째, 백업 파일을 같은 서버에만 보관하지 마세요.

서버 자체에 장애가 발생하면 백업 파일도 함께 손실될 수 있습니다.

셋째, 백업 파일의 접근 권한을 관리하세요.

데이터베이스 백업에는 중요한 정보가 포함될 수 있습니다.

넷째, 백업이 실제로 복구되는지 테스트하세요.

백업 파일이 존재하는 것과 실제 복구 가능한 것은 다릅니다.

다섯째, 보관 기간을 정하세요.

매일 백업한다면 오래된 파일을 정리하지 않을 경우 디스크 공간이 부족해질 수 있습니다.

마무리

MySQL 데이터베이스를 운영한다면 백업은 선택이 아니라 기본적인 서버 관리 작업이라고 생각하는 것이 좋습니다.

특히 mysqldump를 활용하면 복잡한 프로그램 없이도 데이터베이스의 구조와 데이터를 SQL 파일로 백업할 수 있습니다.

가장 기본적인 백업 명령어는 다음과 같습니다.

mysqldump -u root -p 데이터베이스명 > backup.sql

복구할 때는:

mysql -u root -p 데이터베이스명 < backup.sql

대용량 백업 파일이라면 gzip을 함께 사용할 수 있습니다.

mysqldump -u root -p 데이터베이스명 | gzip > backup.sql.gz

그리고 복구할 때:

gunzip < backup.sql.gz | mysql -u root -p 데이터베이스명

하지만 진짜 중요한 것은 백업 파일을 만드는 것에서 끝나지 않는 것입니다.

정기적으로 백업하고, 적절한 보관 기간을 설정하며, 다른 저장 공간에도 백업을 보관하고, 실제 복구 테스트까지 진행해야 안전한 백업 시스템이라고 할 수 있습니다.

리눅스 서버에서 MySQL을 운영하고 있다면 mysqldump를 기본 백업 도구로 익혀두는 것만으로도 서버 장애나 데이터 손실에 대비하는 중요한 첫걸음이 될 수 있습니다.