MariaDB 백업은 성공했는데 복구가 실패하는 이유 5가지

 

 

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

MariaDB 백업은 성공했는데 복구가 실패하는 이유 5가지

도입

지난 글에서는 Docker 환경에서 MariaDB를 백업하는 가장 기본적인 방법으로 mysqldump를 살펴봤습니다. MariaDB 컨테이너 안에서 데이터베이스를 SQL 파일로 내보내고, 만들어진 백업 파일의 크기와 내용을 확인하는 흐름까지 정리했습니다.

그런데 여기서 끝이 아니었습니다. 백업 파일이 있다는 것과 실제로 복구할 수 있다는 것은 전혀 다른 문제였습니다. backup.sql 파일은 분명히 있는데, 막상 복구하려고 하면 오류가 나거나, 복구는 된 것 같은데 WordPress 화면은 그대로인 경우가 생길 수 있습니다.

처음에는 백업 파일 자체가 잘못된 줄 알았습니다. 하지만 하나씩 살펴보니 문제는 SQL 파일보다 주변 환경에 있는 경우가 많았습니다. 문자셋이 다르거나, 데이터베이스 이름이 맞지 않거나, 사용자 권한이 부족하거나, Docker Network와 Volume을 잘못 이해한 경우가 대표적이었습니다.

이번 글에서는 MariaDB 백업 파일이 있어도 복구가 실패하는 이유를 다섯 가지로 나누어 살펴보겠습니다. 단순히 명령어를 나열하기보다 실제 홈서버 운영에서 만날 수 있는 사고 사례처럼 정리해보려고 합니다.

MariaDB 백업 파일이 정상적으로 존재해도 Character Set, 데이터베이스 이름, 권한, Docker Network, Volume 설정이 맞지 않으면 복구가 실패할 수 있습니다. 홈서버 운영자가 가장 많이 만나는 복구 실패 사례 5가지를 한눈에 정리했습니다.

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

본문

① Character Set이 달라 한글이 깨지는 경우

복구가 실패했다고 느끼는 첫 번째 상황은 한글이 깨지는 경우입니다. SQL 파일은 정상적으로 들어간 것 같은데, WordPress 글 제목이나 본문이 이상한 문자로 보이면 문자셋 문제를 의심해볼 수 있습니다.

특히 한글 콘텐츠를 다루는 WordPress에서는 문자셋이 중요합니다. 백업할 때와 복구할 때의 문자셋이 다르거나, 데이터베이스와 테이블의 문자셋이 맞지 않으면 글자가 깨져 보일 수 있습니다.

MariaDB와 WordPress 환경에서는 보통 utf8mb4 계열을 많이 사용합니다. 이 문자셋은 한글뿐 아니라 이모지 같은 문자까지 다룰 수 있어 WordPress 운영에서 자주 사용됩니다.

docker exec mariadb mysqldump \
  --default-character-set=utf8mb4 \
  -u root -p wordpress > backup.sql

복구할 때도 문자셋을 명시할 수 있습니다.

docker exec -i mariadb mariadb \
  --default-character-set=utf8mb4 \
  -u root -p wordpress < backup.sql

이 명령이 모든 문자셋 문제를 자동으로 해결해주는 것은 아니지만, 백업과 복구 과정에서 같은 기준을 사용하도록 도와줍니다. 중요한 것은 복구 후 실제 글 제목과 본문이 정상적으로 보이는지 확인하는 것입니다.

② 데이터베이스 이름이 달라 복구가 실패하는 경우

두 번째는 데이터베이스 이름이 다른 경우입니다. 예를 들어 기존 WordPress는 wordpress라는 데이터베이스를 사용하고 있었는데, 새 환경에서는 wordpress_new 또는 wp_db 같은 이름으로 만들어두었을 수 있습니다.

이때 복구 명령에서 지정한 데이터베이스가 존재하지 않으면 오류가 발생할 수 있습니다.

ERROR 1049 (42000): Unknown database 'wordpress'

복구 전에 현재 MariaDB 안에 어떤 데이터베이스가 있는지 확인해야 합니다.

docker exec -it mariadb mariadb -u root -p

SHOW DATABASES;

복구 대상 데이터베이스가 없다면 먼저 만들어야 합니다.

CREATE DATABASE wordpress;

여기서 더 헷갈리는 상황도 있습니다. SQL 파일은 정상적으로 복구됐는데 WordPress가 다른 데이터베이스를 바라보고 있는 경우입니다. 이때는 복구가 안 된 것이 아니라, WordPress의 연결 설정과 복구한 DB가 서로 다른 곳을 보고 있는 것입니다.

• docker-compose.yml의 DB 이름을 확인합니다.
• .env 파일에 적힌 DB 이름을 확인합니다.
• WordPress가 바라보는 DB_HOST와 DB_NAME을 확인합니다.
• 복구한 데이터베이스 이름과 실제 연결 정보가 같은지 확인합니다.

③ 권한이 부족해 복구가 막히는 경우

세 번째는 사용자 권한 문제입니다. 백업 파일을 읽는 것과 데이터베이스에 다시 넣는 것은 다릅니다. 복구하려는 사용자가 데이터베이스에 테이블을 만들고 데이터를 넣을 권한이 없다면 오류가 발생할 수 있습니다.

대표적으로 볼 수 있는 오류는 Access denied입니다.

ERROR 1045 (28000): Access denied for user 'root'@'localhost'

또는 특정 데이터베이스에 대한 권한이 없을 때도 비슷한 오류가 발생할 수 있습니다.

ERROR 1044 (42000): Access denied for user to database 'wordpress'

이런 경우에는 사용자 이름, 비밀번호, 권한을 순서대로 확인해야 합니다. 특히 Docker Compose 환경에서는 root 비밀번호와 WordPress 전용 DB 사용자 비밀번호가 따로 설정되어 있을 수 있습니다.

확인 항목	확인 내용	주의할 점
사용자 이름	-u root 또는 전용 사용자	실제 계정과 일치해야 함
비밀번호	-p 입력 후 확인	.env 값과 혼동 주의
DB 권한	복구 대상 DB에 쓰기 가능 여부	읽기 권한만 있으면 복구 불가
접속 위치	컨테이너 내부 접속 여부	호스트와 컨테이너 환경 차이 주의

처음 복구 테스트를 할 때는 root 계정으로 흐름을 이해할 수 있습니다. 다만 실제 운영에서는 최소 권한 원칙도 함께 생각해야 합니다. 복구 작업은 강한 권한이 필요한 작업이므로, 계정 정보 관리가 중요합니다.

④ Docker Network가 달라 연결되지 않는 경우

네 번째는 Docker Network 문제입니다. MariaDB 컨테이너는 살아 있고 WordPress 컨테이너도 실행 중인데, 두 컨테이너가 서로 통신하지 못하면 WordPress는 데이터베이스에 연결할 수 없습니다.

이때 WordPress 화면에서는 흔히 데이터베이스 연결 오류가 나타날 수 있습니다. 사용자는 복구가 실패했다고 느끼지만, 실제로는 복구된 DB에 WordPress가 접근하지 못하는 상황일 수 있습니다.

docker compose ps

먼저 두 컨테이너가 같은 Compose 프로젝트 안에서 실행 중인지 확인합니다. 그리고 WordPress 환경변수에서 DB_HOST가 어떤 값을 바라보는지도 확인해야 합니다.

services:
  wordpress:
    environment:
      WORDPRESS_DB_HOST: mariadb
      WORDPRESS_DB_NAME: wordpress

  mariadb:
    image: mariadb

Docker Compose에서는 같은 네트워크 안에 있는 서비스끼리 서비스명으로 접근할 수 있습니다. 그래서 WordPress가 MariaDB에 연결할 때 localhost가 아니라 mariadb 같은 서비스명을 사용해야 하는 경우가 많습니다.

• WordPress와 MariaDB가 같은 Compose 네트워크에 있는지 확인합니다.
• WORDPRESS_DB_HOST 값이 MariaDB 서비스명과 맞는지 확인합니다.
• 컨테이너 이름과 서비스명을 혼동하지 않습니다.
• 복구한 DB 컨테이너와 WordPress가 연결된 DB 컨테이너가 같은지 확인합니다.

⑤ Volume을 잘못 연결해 다른 데이터를 보는 경우

다섯 번째는 Docker Volume 문제입니다. 이 부분은 실제 사고가 가장 많이 생길 수 있는 지점입니다. 컨테이너는 새로 만들 수 있지만, 데이터는 Volume이나 바인드 마운트 경로에 저장됩니다.

예를 들어 MariaDB를 새로 띄웠는데 기존 Volume을 연결하지 않았다면, 컨테이너는 깨끗한 새 데이터베이스처럼 보일 수 있습니다. 반대로 복구를 했다고 생각했는데 WordPress 화면이 바뀌지 않는다면, WordPress가 연결된 MariaDB와 내가 복구한 MariaDB가 서로 다를 수도 있습니다.

docker volume ls

docker compose config

Compose 설정에서 MariaDB가 어떤 Volume이나 폴더를 사용하는지 확인합니다.

services:
  mariadb:
    volumes:
      - ./mariadb_data:/var/lib/mysql

Volume 문제는 눈에 잘 보이지 않기 때문에 더 위험합니다. 컨테이너가 정상적으로 실행되고 있어도 실제 데이터 위치가 다르면, 복구 결과가 예상과 다르게 보일 수 있습니다.

상황	가능한 원인	확인 방법
복구했는데 글이 안 보임	다른 DB에 복구	DB_HOST, DB_NAME 확인
새 WordPress처럼 보임	기존 Volume 미연결	Volume 경로 확인
컨테이너 재생성 후 데이터 없음	데이터 폴더 삭제	바인드 마운트 경로 확인
복구 파일은 정상인데 화면 변화 없음	다른 MariaDB를 보고 있음	Compose 프로젝트와 네트워크 확인

⑥ 복구는 테스트까지 해야 완성된다

이 다섯 가지 문제를 살펴보면 공통점이 있습니다. 백업 파일 자체보다 복구하는 환경이 더 중요하다는 점입니다. Character Set, DB 이름, 권한, Docker Network, Volume은 모두 SQL 파일 밖에 있는 요소입니다.

그래서 복구는 운영 중인 서비스에 바로 적용하기보다, 가능하면 테스트용 데이터베이스나 별도 환경에서 먼저 확인하는 것이 안전합니다.

CREATE DATABASE wordpress_test;

docker exec -i mariadb mariadb -u root -p wordpress_test < backup.sql

복구 후에는 테이블이 생성되었는지 확인합니다.

USE wordpress_test;
SHOW TABLES;

여기서 끝내지 않고 실제 데이터가 들어왔는지도 확인해야 합니다. WordPress라면 게시글 테이블, 옵션 테이블, 사용자 테이블 등이 존재하는지 살펴볼 수 있습니다.

운영 철학

백업은 파일을 만드는 작업이 아니라, 언제든 서비스를 다시 살릴 수 있는 상태를 만드는 작업입니다.

운영노트

아래 표는 MariaDB 백업 파일을 복구하기 전에 점검할 수 있는 기본 항목입니다. 실제 운영 환경에서는 서비스 중단 가능성과 데이터 덮어쓰기 위험도 함께 고려해야 합니다.

점검 항목	확인 방법	운영 판단
Character Set	utf8mb4 여부 확인	한글 깨짐 예방
DB 이름	SHOW DATABASES;	복구 대상 DB 확인
권한	접속과 쓰기 권한 확인	Access denied 예방
Docker Network	docker compose ps	서비스 간 연결 확인
Volume	docker volume ls	실제 데이터 위치 확인
복구 테스트	테스트 DB에 복원	백업 신뢰도 확인

에디터의 해석노트

백업 파일을 만들면 마음이 조금 놓입니다. 하지만 이번 글을 정리하면서 파일이 있다는 사실과 복구가 가능하다는 사실은 다르다는 점을 다시 느꼈습니다.

특히 Docker 환경에서는 데이터베이스만 보면 안 됩니다. 컨테이너, 네트워크, Volume, 환경변수까지 함께 봐야 합니다. SQL 파일은 복구 재료일 뿐이고, 실제 복구는 그 파일이 들어갈 환경까지 맞아야 완성됩니다.

앞으로는 백업을 만들 때마다 파일 크기만 확인하는 것이 아니라, 테스트 복구까지 하나의 과정으로 생각해야겠습니다. 복구해보지 않은 백업은 아직 완성된 백업이 아니라고 보는 편이 더 안전하겠습니다.

참고 링크 (References)

1. MariaDB Dump Documentation
2. MariaDB Backup and Restore Overview
3. MariaDB Character Sets and Collations
4. Docker Volumes Documentation
5. Docker Compose Networking

트러블슈팅

문제: MariaDB 백업 파일을 복구했지만 오류가 발생하거나 WordPress 화면이 예상대로 돌아오지 않음

백업 파일이 있어도 복구가 실패할 수 있습니다. 이때는 SQL 파일만 의심하지 말고 Character Set, 데이터베이스 이름, 사용자 권한, Docker Network, Volume 연결을 순서대로 확인해야 합니다.

확인: 복구 대상 DB와 실제 WordPress 연결 정보를 먼저 확인하고, SQL 파일 상태와 Docker 환경을 함께 점검합니다.

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

# 실행 중인 컨테이너 확인
docker ps

# MariaDB 접속
docker exec -it mariadb mariadb -u root -p

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

# Volume 목록 확인
docker volume ls

# Compose 설정 확인
docker compose config

원인: 문자셋 불일치, DB 이름 불일치, 사용자 권한 부족, Docker Network 불일치, 기존 Volume 미연결 또는 다른 MariaDB 컨테이너에 복구

해결: 운영 DB에 바로 복구하지 말고 먼저 테스트용 DB에 복구합니다. 복구 후 테이블 목록과 주요 데이터, 한글 표시 여부를 확인한 뒤 실제 운영 환경에 적용하는 것이 안전합니다.

• 한글 깨짐: utf8mb4 문자셋을 확인합니다.
• Unknown database: 복구 대상 DB 이름을 확인합니다.
• Access denied: 사용자 계정과 권한을 확인합니다.
• DB 연결 오류: Docker Network와 DB_HOST 값을 확인합니다.
• 복구 후 변화 없음: Volume과 실제 연결된 DB를 확인합니다.

복구 실패는 백업 파일 하나만의 문제가 아닐 수 있습니다. 실제 운영 환경에서는 SQL 파일, 데이터베이스, Docker 설정, WordPress 연결 정보가 모두 맞아야 복구가 완료됩니다.

마무리

이번 글에서는 MariaDB 백업은 성공했는데 복구가 실패하는 이유를 다섯 가지로 정리했습니다. Character Set, DB 이름, 권한, Docker Network, Volume 문제는 모두 실제 홈서버 운영에서 충분히 만날 수 있는 복구 실패 원인입니다.

백업 파일은 중요한 출발점입니다. 하지만 그것만으로는 충분하지 않습니다. 백업 파일을 어디에 넣을지, 어떤 데이터베이스에 복구할지, WordPress가 그 데이터베이스를 제대로 바라보고 있는지까지 확인해야 합니다.

결국 백업은 파일을 만드는 작업이 아니라, 언제든 서비스를 다시 살릴 수 있는 상태를 만드는 작업입니다. 다음 글에서는 이 백업 과정을 매번 손으로 실행하지 않도록, cron과 Docker를 이용해 자동 백업 구조를 만드는 방법을 살펴보겠습니다.