Docker에서 MariaDB 백업하기 : mysqldump부터 시작하기

 

 

※ 이 글은 운영자가 직접 홈서버를 운영하며 겪은 경험과 MariaDB, Docker 공식 문서를 참고해 작성했습니다. 글의 문장 정리와 구성에는 AI 도구의 도움을 약간 받았지만, 최종적으로는 운영자가 직접 내용을 검토하고 확인했습니다.

Docker에서 MariaDB 백업하기 : mysqldump부터 시작하기

도입

지난 글에서는 백업이 왜 필요한지 살펴봤습니다. 홈서버에서 WordPress와 MariaDB를 운영하다 보면 서비스가 잘 열리는 것만으로는 충분하지 않습니다. 중요한 것은 문제가 생겼을 때 다시 복구할 수 있는 준비가 되어 있는가였습니다.

이번에는 한 걸음 더 들어가 실제로 MariaDB 데이터를 백업해보려고 합니다. 백업 방식은 여러 가지가 있지만, 처음에는 가장 기본적인 방법부터 이해하는 것이 좋습니다. 그 출발점으로 사용할 도구가 바로 mysqldump입니다.

mysqldump는 MariaDB 안에 들어 있는 데이터베이스 내용을 SQL 파일 형태로 저장하는 도구입니다. 쉽게 말하면 현재 데이터베이스의 구조와 데이터를 나중에 다시 실행할 수 있는 SQL 문서로 꺼내두는 방식입니다.

이번 글의 목표는 명령어 하나를 외우는 것이 아닙니다. Docker 환경에서 MariaDB가 어디에 있고, 어떤 데이터베이스를 백업해야 하며, 만들어진 백업 파일을 어떻게 확인해야 하는지 흐름을 이해하는 것입니다.

Docker 환경에서 MariaDB를 mysqldump로 백업하는 과정을 단계별로 정리한 운영 다이어그램입니다. 컨테이너 확인부터 SQL 파일 생성, 백업 검증, 3-2-1 백업 원칙까지 한눈에 이해할 수 있습니다.

※ 다이어그램은 운영 환경 설계를 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.
출처: 디지털 장난감

본문

① mysqldump란 무엇일까?

mysqldump는 MariaDB나 MySQL 계열 데이터베이스에서 자주 사용하는 백업 도구입니다. 데이터베이스 안에 들어 있는 테이블 구조와 데이터를 SQL 문장 형태로 출력합니다.

예를 들어 WordPress 데이터베이스를 mysqldump로 백업하면 게시글, 댓글, 사용자 정보, 설정값 등이 SQL 파일 안에 기록됩니다. 나중에 이 SQL 파일을 다시 MariaDB에 넣으면 백업 당시의 데이터베이스 상태를 어느 정도 되돌릴 수 있습니다.

이런 방식은 보통 논리 백업이라고 부릅니다. 데이터베이스 파일 자체를 통째로 복사하는 것이 아니라, 데이터베이스 내용을 SQL 문장으로 다시 만들어 저장하는 방식이기 때문입니다.

구분	설명	홈서버 관점
논리 백업	SQL 문장 형태로 데이터 저장	mysqldump로 시작하기 쉬움
물리 백업	데이터베이스 파일 자체를 백업	더 빠를 수 있지만 구조 이해가 필요함
파일 백업	업로드 파일, 설정 파일 복사	WordPress 복구에는 DB와 함께 필요함

처음 홈서버를 운영하는 단계에서는 mysqldump로 데이터베이스를 SQL 파일로 저장해보는 것만으로도 백업의 흐름을 이해하는 데 큰 도움이 됩니다.

② 백업 전에 무엇을 확인해야 할까?

백업 명령어를 실행하기 전에 먼저 확인해야 할 항목이 있습니다. 컨테이너 이름, 데이터베이스 이름, 사용자 계정, 비밀번호, 백업 파일을 저장할 위치입니다.

이 정보를 모른 채 명령어만 복사해서 실행하면 오류가 나기 쉽습니다. 특히 Docker Compose 환경에서는 서비스 이름과 컨테이너 이름이 다를 수 있고, 데이터베이스 이름도 설치할 때 정한 값에 따라 달라집니다.

확인 항목	예시	확인 이유
MariaDB 컨테이너 이름	mariadb	docker exec 대상 확인
데이터베이스 이름	wordpress	어떤 DB를 백업할지 지정
사용자 계정	root 또는 DB 사용자	접속 권한 확인
비밀번호	.env 또는 Compose 환경변수	접속 인증에 필요
백업 저장 위치	./backup	백업 파일 보관 위치 확인

먼저 컨테이너 상태를 확인합니다.

docker compose ps

여기서 MariaDB 컨테이너가 실행 중인지 확인합니다. 컨테이너가 실행 중이 아니라면 mysqldump도 정상적으로 실행할 수 없습니다.

③ Docker에서 mysqldump 실행하기

Docker 환경에서 MariaDB를 백업할 때는 보통 docker exec를 이용해 컨테이너 안에서 mysqldump를 실행합니다. 그리고 그 결과를 호스트의 SQL 파일로 저장합니다.

기본 구조는 아래와 같습니다.

docker exec mariadb mysqldump -u root -p wordpress > backup.sql

이 명령은 MariaDB 컨테이너 안에서 mysqldump를 실행하고, wordpress 데이터베이스 내용을 현재 작업 폴더의 backup.sql 파일로 저장합니다.

명령 요소	의미
docker exec	실행 중인 컨테이너 안에서 명령 실행
mariadb	MariaDB 컨테이너 이름
mysqldump	데이터베이스를 SQL 형태로 내보내는 도구
-u root	접속할 데이터베이스 사용자
-p	비밀번호 입력을 요청
wordpress	백업할 데이터베이스 이름
> backup.sql	출력 결과를 SQL 파일로 저장

비밀번호를 명령어에 직접 적는 방식도 가능하지만, 터미널 기록에 비밀번호가 남을 수 있어 조심해야 합니다. 처음 연습할 때는 -p 옵션을 사용해 실행 후 비밀번호를 입력하는 방식을 이해하는 편이 안전합니다.

④ 백업 폴더를 만들고 날짜를 붙여 저장하기

백업 파일 이름이 항상 backup.sql이면 나중에 어떤 시점의 백업인지 알기 어렵습니다. 그래서 날짜를 붙여 저장하는 습관이 좋습니다.

mkdir -p backup

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

이렇게 하면 backup 폴더 안에 날짜가 붙은 SQL 파일이 만들어집니다.

backup/wordpress_20260618.sql

날짜를 파일명에 넣어두면 나중에 백업 이력을 확인하기 쉽습니다. 자동 백업으로 넘어가면 이 방식이 더 중요해집니다. 어떤 파일이 최신 백업인지, 어떤 파일을 오래 보관할지 판단할 수 있기 때문입니다.

⑤ 백업 파일이 만들어졌는지 확인하기

명령어가 끝났다고 해서 바로 안심하면 안 됩니다. 먼저 파일이 실제로 만들어졌는지 확인해야 합니다.

ls -lh backup

파일 크기가 0바이트라면 정상적인 백업이 아닐 가능성이 큽니다. 오류 메시지가 파일에 섞여 들어갔거나, 접속 권한 문제로 실제 데이터가 저장되지 않았을 수도 있습니다.

SQL 파일의 앞부분을 살펴보는 것도 도움이 됩니다.

head -n 20 backup/wordpress_20260618.sql

정상적인 SQL Dump 파일이라면 테이블 생성 구문이나 데이터 삽입 구문이 들어 있습니다. 파일을 전부 읽을 필요는 없지만, 최소한 SQL 파일이 비어 있지 않은지는 확인해야 합니다.

• 백업 파일이 실제로 생성되었는지 확인합니다.
• 파일 크기가 0바이트가 아닌지 확인합니다.
• 파일명에 날짜가 포함되어 있는지 확인합니다.
• SQL 내용 일부를 열어 정상적인 Dump인지 확인합니다.
• 오류 메시지가 SQL 파일 안에 들어가지 않았는지 확인합니다.

⑥ 백업 파일은 어디에 보관해야 할까?

백업 파일이 만들어졌다면 다음으로 생각할 것은 보관 위치입니다. 같은 서버 안에만 백업 파일을 두면 저장장치가 고장 났을 때 원본과 백업을 함께 잃을 수 있습니다.

월요일에 살펴본 3-2-1 백업 원칙을 떠올리면, 백업 파일은 가능하면 다른 저장장치나 다른 장소에도 보관하는 편이 좋습니다.

보관 위치	장점	주의할 점
서버 내부 폴더	가장 빠르고 간단함	디스크 고장 시 함께 손실 가능
외장하드	분리 보관 가능	주기적으로 연결하고 확인 필요
NAS	여러 장치에서 접근 가능	권한과 네트워크 상태 확인 필요
클라우드 저장소	외부 장소 보관 가능	민감한 정보 암호화 고려

데이터베이스 백업 파일에는 사이트 설정이나 사용자 정보가 들어 있을 수 있습니다. 그래서 외부에 보관할 때는 접근 권한과 암호화도 함께 고민해야 합니다.

⑦ 백업은 성공했을까?

백업 파일이 만들어졌다고 해서 백업이 완성된 것은 아닙니다. 진짜 중요한 질문은 이 파일로 복구할 수 있는가입니다.

오늘 단계에서는 복구 실습까지 깊게 들어가지는 않지만, 백업 파일을 만들 때부터 복구 가능성을 생각해야 합니다. 파일명, 날짜, 데이터베이스 이름, 백업 위치, 파일 크기를 기록해두면 나중에 복구할 때 훨씬 덜 당황합니다.

운영 철학

백업은 파일을 만드는 순간 끝나는 것이 아니라, 복구할 수 있을 때 비로소 완성됩니다.

이번 글에서는 MariaDB 데이터를 SQL 파일로 저장하는 흐름을 살펴봤습니다. 다음 단계에서는 이 백업 파일을 가지고도 복구가 실패할 수 있는 이유를 살펴보게 됩니다.

운영노트

아래 표는 Docker 환경에서 MariaDB 백업을 만들 때 기록해두면 좋은 운영 항목입니다. 실제 값은 운영 환경에 맞게 변경해야 합니다.

확인 항목	예시	운영 판단
컨테이너 이름	mariadb	실제 Compose 구성과 일치해야 함
DB 이름	wordpress	백업 대상 데이터베이스 확인
백업 파일명	wordpress_20260618.sql	날짜를 포함해 이력 관리
저장 위치	./backup	서버 내부와 외부 보관 분리 검토
파일 크기	0바이트 아님	빈 파일 여부 확인
복구 테스트	별도 환경에서 진행	다음 단계에서 검증 필요

에디터의 해석노트

MariaDB 백업이라고 하면 처음에는 어렵게 느껴졌습니다. 하지만 mysqldump를 기준으로 보면 현재 데이터베이스 상태를 하나의 SQL 문서로 저장하는 작업이라고 이해할 수 있었습니다.

실제로 더 중요한 것은 명령어 자체보다 백업 파일을 관리하는 방식이었습니다. 어떤 데이터베이스를 백업했는지, 언제 만든 파일인지, 파일이 정상적으로 생성되었는지 확인하지 않으면 나중에 복구할 때 혼란이 생길 수 있습니다.

이번 글을 정리하면서 백업은 한 번 실행하고 끝나는 작업이 아니라, 기록하고 확인하고 보관하는 운영 습관이라는 생각이 들었습니다.

참고 링크 (References)

1. MariaDB Dump Documentation
2. MariaDB Backup and Restore Overview
3. Docker exec Reference
4. Docker Compose Documentation
5. WordPress Backups

트러블슈팅

문제: mysqldump 명령을 실행했지만 백업 파일이 정상적으로 만들어지지 않음

Docker 환경에서 MariaDB를 백업할 때는 컨테이너 이름, 데이터베이스 이름, 사용자 계정, 권한, 저장 경로 중 하나만 달라도 오류가 발생할 수 있습니다. 오류 메시지를 보고 어느 단계에서 문제가 생겼는지 먼저 나누어 보는 것이 좋습니다.

확인: 컨테이너 이름, 데이터베이스 이름, 사용자 권한, 비밀번호, 저장 경로를 순서대로 점검

# 컨테이너 상태 확인
docker compose ps

# 컨테이너 이름 확인
docker ps

# MariaDB 컨테이너 안으로 접속
docker exec -it mariadb mariadb -u root -p

# 데이터베이스 목록 확인
SHOW DATABASES;

원인: 컨테이너 이름 불일치, 비밀번호 오류, 데이터베이스 이름 오타, 사용자 권한 부족, 백업 폴더 권한 문제

해결: 실제 컨테이너 이름과 데이터베이스 이름을 먼저 확인한 뒤 명령어에 반영합니다. 백업 폴더가 없다면 먼저 생성하고, 파일이 0바이트로 생성되었는지도 확인합니다.

• Access denied: 사용자 이름 또는 비밀번호, 권한을 확인합니다.
• Unknown database: 데이터베이스 이름이 실제와 일치하는지 확인합니다.
• Container not found: docker ps로 컨테이너 이름을 확인합니다.
• Permission denied: 백업 저장 폴더의 권한을 확인합니다.
• 0바이트 파일: 오류가 파일로 리다이렉션되었는지 확인하고 명령을 다시 점검합니다.

이번 단계에서는 백업 파일을 만드는 것에 집중했습니다. 다음 글에서는 백업 파일이 있어도 복구가 실패할 수 있는 이유를 살펴보겠습니다.

마무리

이번 글에서는 Docker 환경에서 MariaDB를 백업하는 가장 기본적인 방법으로 mysqldump를 살펴봤습니다. 데이터베이스 내용을 SQL 파일로 저장하고, 파일이 정상적으로 만들어졌는지 확인하는 흐름까지 정리했습니다.

백업은 명령어를 한 번 실행하는 것으로 끝나지 않습니다. 어떤 데이터베이스를 백업했는지, 파일이 어디에 저장되었는지, 언제 만들어졌는지, 실제로 복구할 수 있는지까지 생각해야 합니다.

다음 글에서는 백업 파일이 있어도 복구가 실패하는 경우를 살펴보겠습니다. 백업을 만들었다는 안도감이 실제 복구 가능성으로 이어지려면 어떤 점을 확인해야 하는지 이어서 정리해보겠습니다.