백업 파일은 있는데 왜 복구가 안 될까?

 

 

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

백업 파일은 있는데 왜 복구가 안 될까?

도입

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

그런데 백업 파일이 있다고 해서 곧바로 안심할 수 있을까요? 실제 운영에서는 백업 파일은 있는데 복구가 되지 않는 경우가 생길 수 있습니다. 파일은 분명히 있는데 데이터베이스 이름이 다르거나, 사용자 권한이 맞지 않거나, 문자셋 문제로 한글이 깨지거나, Docker Volume 위치를 잘못 이해해서 예상과 다른 곳에 복구하는 상황도 생깁니다.

백업은 파일을 만드는 순간 끝나는 것이 아니라, 복구할 수 있을 때 비로소 완성됩니다. 그래서 이번 글에서는 백업 파일이 있는데도 복구가 실패하는 대표적인 이유를 하나씩 살펴보려고 합니다.

오늘은 새로운 기능을 추가하는 글이 아닙니다. 오히려 백업 파일을 믿기 전에 무엇을 확인해야 하는지, 복구 과정에서 어디서 실수가 생기는지, 홈서버 운영자가 어떤 순서로 문제를 좁혀가야 하는지 정리하는 트러블슈팅 글입니다.

Docker 기반 MariaDB 복구 실패 원인을 단계별로 점검하는 운영 가이드입니다. 데이터베이스 이름, 권한, 문자셋, SQL 파일, Docker Volume까지 복구 전에 확인해야 할 핵심 체크포인트를 한눈에 정리했습니다.

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

본문

① 백업 파일이 있다고 안심하면 안 되는 이유

백업 파일을 만들고 나면 일단 마음이 놓입니다. backup.sql 파일이 있고, 파일 크기도 0바이트가 아니며, 열어보면 SQL 문장도 들어 있습니다. 겉으로 보기에는 백업이 성공한 것처럼 보입니다.

하지만 복구는 또 다른 문제입니다. 백업 파일은 과거의 데이터를 담고 있는 재료일 뿐이고, 실제로 서비스를 되살리려면 그 파일을 올바른 데이터베이스에 정확히 넣을 수 있어야 합니다. 이 과정에서 환경이 조금만 달라도 오류가 생길 수 있습니다.

• 백업한 데이터베이스 이름과 복구 대상 이름이 다를 수 있습니다.
• 복구할 사용자에게 충분한 권한이 없을 수 있습니다.
• 문자셋이 맞지 않아 한글이 깨질 수 있습니다.
• Docker Volume 위치를 잘못 이해할 수 있습니다.
• SQL 파일이 중간에 잘렸거나 손상되었을 수 있습니다.

그래서 백업을 만들었다면 언젠가는 반드시 복구 테스트를 해봐야 합니다. 복구해본 적 없는 백업은 실제 장애 상황에서 얼마나 믿을 수 있는지 알기 어렵습니다.

② 복구 실패가 자주 생기는 지점

MariaDB 복구는 보통 SQL 파일을 데이터베이스에 다시 넣는 방식으로 진행됩니다. 기본 형태는 아래와 같습니다.

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

이 명령은 호스트에 있는 backup.sql 파일을 MariaDB 컨테이너 안의 wordpress 데이터베이스로 가져오는 구조입니다. 하지만 이 명령이 항상 성공하는 것은 아닙니다.

실패 지점	대표 증상	먼저 확인할 것
컨테이너 이름	Container not found	docker ps로 실제 이름 확인
DB 이름	Unknown database	SHOW DATABASES; 확인
사용자 권한	Access denied	사용자, 비밀번호, 권한 확인
SQL 파일	복구 중 중단	파일 크기와 내용 확인
문자셋	한글 깨짐	덤프와 복구 문자셋 확인

오류가 발생하면 명령어 전체를 다시 복사하기보다, 어느 지점에서 실패했는지 먼저 나누어 보는 것이 좋습니다. 컨테이너 문제인지, 데이터베이스 문제인지, 권한 문제인지 구분해야 해결이 빨라집니다.

③ 데이터베이스 이름이 다르면 복구가 막힐 수 있다

가장 흔한 실수 중 하나는 백업한 데이터베이스 이름과 복구하려는 데이터베이스 이름이 다른 경우입니다. 예를 들어 백업 파일은 wordpress 데이터베이스에서 만들었는데, 새 환경에서는 데이터베이스 이름을 wp_db로 만들어두었을 수 있습니다.

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

ERROR 1049 (42000): Unknown database 'wordpress'

먼저 MariaDB에 접속해 현재 데이터베이스 목록을 확인합니다.

docker exec -it mariadb mariadb -u root -p

SHOW DATABASES;

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

CREATE DATABASE wordpress;

운영 환경에서는 데이터베이스 이름을 마음대로 바꾸지 않는 것이 좋습니다. WordPress의 DB 연결 정보와도 맞아야 하기 때문입니다. 복구 전에는 docker-compose.yml이나 .env 파일에 적힌 데이터베이스 이름도 함께 확인해야 합니다.

④ 사용자 권한과 비밀번호 문제

복구 과정에서 Access denied 오류가 나오면 사용자 이름, 비밀번호, 권한을 먼저 확인해야 합니다. MariaDB는 사용자에게 권한이 있어야 데이터베이스를 읽거나 쓸 수 있습니다.

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

이 오류는 비밀번호가 틀렸거나, 해당 사용자가 지정한 위치에서 접속할 권한이 없거나, 복구 대상 데이터베이스에 필요한 권한이 없을 때 발생할 수 있습니다.

• -u 뒤에 적은 사용자 이름이 맞는지 확인합니다.
• -p 입력 후 비밀번호를 정확히 입력했는지 확인합니다.
• WordPress 전용 DB 사용자와 root 사용자를 혼동하지 않습니다.
• 복구 대상 DB에 쓰기 권한이 있는지 확인합니다.
• .env 파일과 Compose 환경변수를 함께 확인합니다.

처음 테스트할 때는 root 계정으로 복구 흐름을 이해할 수 있지만, 실제 운영에서는 권한을 최소화한 전용 계정과 보안 관리도 함께 고려해야 합니다.

⑤ 문자셋과 한글 깨짐 문제

백업 파일이 정상적으로 복구되었는데도 한글이 깨져 보일 수 있습니다. 이 경우에는 문자셋과 정렬 방식 문제를 의심해볼 수 있습니다.

WordPress는 한글 콘텐츠를 많이 다루기 때문에 문자셋이 중요합니다. 일반적으로는 utf8mb4 계열을 사용하는 경우가 많습니다. 백업 파일을 만들 때와 복구할 때의 문자셋이 맞지 않으면 글자 깨짐이 발생할 수 있습니다.

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

문자셋 문제는 백업을 만든 뒤 한참 지나서 발견하면 더 당황스럽습니다. 그래서 복구 테스트를 할 때는 단순히 데이터가 들어갔는지만 보지 말고, 실제 글 제목과 본문이 정상적으로 보이는지도 확인해야 합니다.

⑥ Docker Volume과 저장 위치를 혼동하는 경우

Docker에서는 컨테이너와 데이터 저장 위치를 구분해야 합니다. 컨테이너는 삭제하고 다시 만들 수 있지만, 실제 데이터는 Volume이나 바인드 마운트 경로에 저장됩니다.

복구를 했다고 생각했는데 사이트가 바뀌지 않는다면, 예상과 다른 데이터베이스 컨테이너에 복구했거나, WordPress가 다른 MariaDB를 바라보고 있을 가능성도 있습니다.

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

# Compose 서비스 상태 확인
docker compose ps

# Volume 목록 확인
docker volume ls

Compose 파일에서 WordPress와 MariaDB가 같은 네트워크에 있고, WordPress가 어떤 DB_HOST를 바라보는지도 확인해야 합니다.

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

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

이런 구조를 확인하지 않으면 복구는 했는데 실제 서비스에는 반영되지 않는 것처럼 보일 수 있습니다. 복구는 SQL 파일만의 문제가 아니라, 서비스 연결 구조와도 함께 봐야 합니다.

⑦ SQL 파일 자체가 손상되었을 수도 있다

복구가 실패할 때 SQL 파일 자체를 확인해야 하는 경우도 있습니다. 파일이 중간에 잘렸거나, 0바이트이거나, 백업 과정에서 오류 메시지가 섞여 들어갔다면 정상적으로 복구하기 어렵습니다.

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

ls -lh backup.sql

그리고 앞부분과 뒷부분을 확인합니다.

head -n 20 backup.sql
tail -n 20 backup.sql

SQL 파일은 텍스트 파일이기 때문에 일부 내용을 확인할 수 있습니다. 물론 큰 파일을 편집기로 바로 열면 불편할 수 있으니 head, tail, grep 같은 명령으로 필요한 부분만 확인하는 편이 좋습니다.

• 파일 크기가 0바이트가 아닌지 확인합니다.
• SQL 파일 안에 오류 메시지가 섞여 있지 않은지 확인합니다.
• 파일 끝부분까지 정상적으로 기록되었는지 확인합니다.
• 압축 파일이라면 압축 해제가 정상적으로 되는지 확인합니다.
• 가능하면 별도 테스트 DB에 먼저 복구해봅니다.

⑧ 복구 테스트가 필요한 이유

백업과 복구에서 가장 중요한 습관은 실제로 복구해보는 것입니다. 운영 중인 서비스에 바로 복구 테스트를 하기는 어렵기 때문에, 가능하다면 별도의 테스트 환경이나 임시 데이터베이스를 만들어 확인하는 편이 안전합니다.

예를 들어 wordpress_test 같은 테스트용 데이터베이스를 만들고, 백업 파일을 그곳에 넣어보는 방식입니다.

CREATE DATABASE wordpress_test;

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

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

USE wordpress_test;
SHOW TABLES;

이런 복구 테스트를 해보면 백업 파일을 훨씬 더 믿을 수 있습니다. 실제 장애 상황에서는 시간이 부족하고 마음도 급해지기 때문에, 평소에 복구 과정을 한 번이라도 경험해두는 것이 중요합니다.

운영노트

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

점검 항목	확인 방법	운영 판단
컨테이너 이름	docker ps	복구 대상 컨테이너 확인
DB 이름	SHOW DATABASES;	복구 대상 DB 존재 여부 확인
사용자 권한	접속 테스트	읽기와 쓰기 권한 확인
문자셋	utf8mb4 확인	한글 깨짐 예방
SQL 파일	ls, head, tail	파일 손상 여부 확인
테스트 복구	임시 DB 복원	실제 복구 가능성 확인

에디터의 해석노트

백업 파일을 만들면 어느 정도 안심이 됩니다. 하지만 이번 글을 정리하면서 파일이 있다는 사실과 실제로 복구할 수 있다는 사실은 다르다는 점을 다시 느꼈습니다.

특히 Docker 환경에서는 컨테이너 이름, 데이터베이스 이름, Volume 위치, 환경변수처럼 확인해야 할 요소가 여러 개로 나뉩니다. 하나만 맞지 않아도 복구가 막히거나, 복구했다고 생각했는데 실제 서비스에는 반영되지 않을 수 있습니다.

앞으로는 백업 파일을 만들면 파일 크기만 보는 것이 아니라, 테스트 복구까지 하나의 과정으로 생각해야겠습니다. 백업은 보관이 아니라 복구를 위한 준비라는 말이 조금 더 현실적으로 다가왔습니다.

참고 링크 (References)

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

트러블슈팅

문제: MariaDB 백업 파일을 복구하려고 했지만 오류가 발생하거나 복구 후 WordPress가 정상적으로 보이지 않음

백업 파일이 있어도 복구 과정에서 여러 문제가 발생할 수 있습니다. 먼저 오류 메시지를 확인하고, 컨테이너 이름, 데이터베이스 이름, 사용자 권한, 문자셋, SQL 파일 상태를 순서대로 점검하는 것이 좋습니다.

확인: 컨테이너 상태, DB 목록, 사용자 권한, SQL 파일 상태, 문자셋, Volume 연결 구조를 차례대로 점검

# 컨테이너 상태 확인
docker ps

# Compose 서비스 확인
docker compose ps

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

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

# 백업 파일 크기 확인
ls -lh backup.sql

# 백업 파일 일부 확인
head -n 20 backup.sql

원인: 컨테이너 이름 불일치, DB 이름 오타, 권한 부족, 문자셋 불일치, SQL 파일 손상, 잘못된 Volume 또는 다른 MariaDB 컨테이너에 복구

해결: 실제 운영 DB에 바로 복구하기 전에 테스트용 DB를 만들어 복구를 확인합니다. 복구 후에는 테이블 목록과 주요 데이터, 한글 표시 여부를 함께 확인합니다.

• Unknown database: 복구 대상 DB가 존재하는지 확인합니다.
• Access denied: 사용자 계정과 권한을 확인합니다.
• 한글 깨짐: utf8mb4 문자셋 설정을 확인합니다.
• 복구 후 변화 없음: WordPress가 연결된 DB_HOST와 DB_NAME을 확인합니다.
• 복구 중 중단: SQL 파일 손상 여부와 파일 끝부분을 확인합니다.

복구 실패는 백업이 실패했다는 뜻만은 아닙니다. 복구 대상 환경이 맞지 않거나, 연결 정보가 다르거나, 파일을 넣는 위치가 잘못되었을 수도 있습니다. 그래서 복구는 항상 환경 확인과 함께 진행해야 합니다.

마무리

이번 글에서는 백업 파일이 있어도 복구가 실패할 수 있는 이유를 살펴봤습니다. 데이터베이스 이름, 사용자 권한, 문자셋, SQL 파일 상태, Docker Volume과 연결 구조처럼 확인해야 할 지점이 생각보다 많았습니다.

백업 파일은 중요한 출발점이지만, 그것만으로 충분하지는 않았습니다. 실제로 복구할 수 있는지 확인해야 비로소 믿을 수 있는 백업이 됩니다. 특히 홈서버처럼 직접 운영하는 환경에서는 복구 테스트가 운영자의 가장 중요한 습관 중 하나가 될 수 있습니다.

다음 글에서는 이 백업 과정을 매번 손으로 실행하지 않도록, cron과 Docker를 이용해 자동 백업 구조를 만드는 방법을 살펴보겠습니다.