MariaDB 백업은 어떻게 해야 할까? Docker 환경 백업 전략 정리

 

 

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

MariaDB 백업은 어떻게 해야 할까? Docker 환경 백업 전략 정리

도입

6주차 월요일에는 홈서버에 어떤 데이터베이스가 어울릴지 고민해봤습니다. 화요일에는 Docker Compose를 활용해 MariaDB를 설치했고, 수요일엔 사용자와 권한 설정에 대해 정리했습니다. 목요일에는 인덱스를 비롯해 성능을 어떻게 높일 수 있는지 기본적인 내용을 살펴봤습니다

금요일에는 MariaDB 백업 전략을 한 번 정리해볼 생각입니다. 데이터베이스 프로그램 자체야 다시 설치하면 되지만, 그 안에 담긴 데이터는 잃어버리면 다시 복구하기 쉽지 않습니다. 게시글이나 사용자 정보, 설정값, 실행 기록처럼 서비스가 시간이 지날수록 쌓아온 데이터는 점점 더 소중해집니다. 운영 기간이 길어질수록 이런 데이터의 중요성도 커지죠.

이번 글에서 가장 중요한 점은 아주 간단합니다. 데이터베이스(DB)는 다시 설치할 수 있지만, 한 번 사라진 데이터는 다시 복구할 수 없다는 겁니다. 그래서 MariaDB를 운영할 때 구축, 권한, 성능 같은 요소들을 챙긴 뒤에는 꼭 백업까지 신경 써야 합니다. 백업이야말로 데이터 보호의 마지막 방패이기 때문입니다.

MariaDB Docker 환경에서 mysqldump 기반 SQL 백업, 데이터 디렉터리 보관, 외부 저장소 활용, 복구 테스트까지 정리한 Intel N100 홈서버 운영 다이어그램입니다.

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

본문

왜 백업이 필요할까?

MariaDB를 처음 설정할 때는 주로 컨테이너가 잘 실행되는지, 접속이 제대로 되는지, 권한이 올바르게 적용됐는지에 신경을 많이 쓰게 됩니다. 하지만 실제로 서비스를 운영하다 보면, 가장 두려운 문제 중 하나는 바로 데이터가 사라지는 일입니다.

데이터베이스 손실은 다양한 상황에서 일어날 수 있습니다. 예를 들어, 실수로 테이블을 삭제하거나 디스크에 문제가 생길 수도 있고, 업데이트 도중 예상치 못한 오류가 날 때도 있습니다. 또, Docker 환경에서는 컨테이너와 데이터 저장 위치를 헷갈려서 데이터가 사라지는 일이 생기기도 합니다.

• 실수로 데이터베이스나 테이블을 삭제한 경우
• 디스크 또는 저장장치에 문제가 생긴 경우
• 컨테이너 재생성 과정에서 데이터 경로를 잘못 지정한 경우
• 업데이트 후 서비스가 정상적으로 동작하지 않는 경우
• 권한 설정이나 설정 파일 변경으로 접속이 불가능해진 경우

이런 상황을 떠올려보면, 백업은 선택이 아니라 거의 필수에 가깝다고 할 수 있습니다. 특히 홈서버의 경우에는 별도의 전문 운영팀이 있는 것도 아니라서, 운영자가 직접 복구할 수 있는 기준을 미리 마련해두는 게 중요했습니다.

Docker 환경에서 데이터는 어디에 저장될까?

MariaDB 컨테이너 안에서 실제 데이터는 보통 /var/lib/mysql 경로에 저장됩니다. Docker 컨테이너 안에만 데이터를 보관하면, 컨테이너를 삭제하거나 다시 만들 때 데이터가 사라질 위험이 있습니다. 이런 이유로, 화요일에 작성한 구축 방법에서는 호스트의 경로와 연결해서 데이터를 보존할 수 있도록 했습니다.

volumes:
  - ./data:/var/lib/mysql

이 구조에서는 컨테이너 내부의 /var/lib/mysql이 호스트의 ./data 디렉터리와 연결됩니다. 즉 컨테이너 자체보다 중요한 것은 이 데이터 디렉터리입니다.

# 데이터 디렉터리 확인
ls -la /opt/docker/mariadb/data

# 데이터 디렉터리 용량 확인
du -sh /opt/docker/mariadb/data

Docker 환경에서 백업을 준비할 때는 컨테이너 이름보다 데이터가 저장된 위치를 먼저 확인하는 게 중요합니다. 컨테이너는 필요하다면 언제든 새로 만들 수 있지만, 데이터 디렉터리를 잃어버리면 복구하기가 쉽지 않기 때문입니다.

mysqldump란 무엇일까?

MariaDB 백업에서 자주 사용하는 방법 중 하나는 mysqldump입니다. mysqldump는 데이터베이스 내용을 SQL 파일 형태로 내보내는 도구입니다. 이렇게 만들어진 파일은 나중에 다시 MariaDB에 입력해 복구할 수 있습니다.

이 방법은 논리적 백업에 해당합니다. 데이터 파일을 직접 복사하는 것이 아니라, 테이블 구조와 데이터를 SQL 문장 형태로 저장합니다.

• 장점 : 사람이 읽을 수 있는 SQL 파일로 저장 가능
• 장점 : 특정 데이터베이스 단위로 백업하기 쉬움
• 주의 : 데이터가 매우 크면 시간이 오래 걸릴 수 있음
• 주의 : 백업 중 변경이 많은 서비스는 일관성 확인 필요

홈서버 규모에서는 mysqldump가 가장 이해하기 쉬운 백업 출발점으로 보였습니다.

MariaDB 데이터베이스 백업하기

Docker로 실행 중인 MariaDB 컨테이너에서 mysqldump를 실행하려면 docker exec를 사용할 수 있습니다. 아래 예시는 homelab 데이터베이스를 백업하는 흐름입니다.

# 백업 디렉터리 생성
mkdir -p /opt/backup/mariadb

# 특정 DB 백업 예시
docker exec mariadb \
  mysqldump -u root -p homelab \
  > /opt/backup/mariadb/homelab_backup.sql

해당 명령을 실행하면 root 비밀번호를 입력하라는 메시지가 나올 수 있습니다. 자동화 과정에서는 비밀번호 입력을 어떻게 처리할지 따로 방법을 생각해야 하지만, 처음에는 직접 비밀번호를 입력하면서 백업 파일이 만들어지는 과정을 먼저 익히는 것이 좋습니다.

모든 데이터베이스를 백업해야 하는 경우에는 --all-databases 옵션을 사용할 수 있습니다.

docker exec mariadb \
  mysqldump -u root -p --all-databases \
  > /opt/backup/mariadb/all_databases_backup.sql

실제 운영 환경에서는 전체를 한 번에 백업할지, 아니면 서비스별로 나누어 백업할지 상황에 따라 적절한 방법을 선택하는 게 좋습니다.

SQL 백업과 데이터 디렉터리 백업의 차이

MariaDB를 백업할 때는 SQL 백업과 데이터 디렉터리 백업을 따로 생각해야 합니다. 두 방법은 각각 목적도 다르고, 진행 방식에도 차이가 있습니다.

구분	SQL 백업	데이터 디렉터리 백업
대표 방식	mysqldump	/var/lib/mysql 또는 연결된 호스트 경로 복사
장점	DB 단위 복구와 이동이 비교적 쉬움	전체 데이터 파일을 보존 가능
주의점	대용량에서는 시간이 오래 걸릴 수 있음	실행 중 복사 시 일관성 문제 주의
홈서버 활용	정기 백업에 적합	전체 복구용 보조 백업으로 검토

초보 운영자 입장에서는 먼저 mysqldump 기반 백업을 이해하고, 이후 데이터 디렉터리 백업과 스냅샷 방식을 보조적으로 검토하는 흐름이 더 안전했습니다.

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

백업 파일을 같은 서버에만 두면 관리가 편하긴 하지만, 만약 디스크에 문제가 생기면 백업도 함께 사라질 수 있습니다. 이런 위험을 줄이려면 백업을 다른 위치에도 나눠서 보관하는 것이 안전합니다.

• 홈서버 내부 : 가장 빠르게 확인 가능하지만 같은 장비 장애에 취약
• 외장 SSD/HDD : 분리 보관 가능, 수동 백업에 적합
• NAS : 홈 네트워크 내 별도 저장소로 활용 가능
• 클라우드 : 외부 보관 가능, 민감정보 암호화 필요

홈서버를 사용할 때는 원본 데이터와 백업 파일을 같은 위치에 두지 않는 것이 가장 기본적인 원칙이에요. 만약 가능하다면, 장비 내부에 한 번 백업하고 또 외부 저장장치에도 따로 저장해 두면 훨씬 더 안전하게 데이터를 지킬 수 있습니다.

복구 테스트가 더 중요했다

백업 파일이 있다고 해서 무조건 복구할 수 있는 것은 아닙니다. 백업이 있어도 파일이 손상됐거나, 꼭 필요한 데이터베이스가 포함되어 있지 않거나, 복구 방법을 모르면 실제로 문제가 생겼을 때 별 도움이 되지 않습니다.

# 복구 예시
docker exec -i mariadb \
  mariadb -u root -p homelab \
  < /opt/backup/mariadb/homelab_backup.sql

실제 운영 데이터에 바로 복구 테스트를 하는 것은 위험할 수 있습니다. 가능하면 테스트용 데이터베이스를 만들고, 백업 파일을 복원해보면서 복구 흐름을 확인하는 것이 좋습니다.

# 테스트 DB 생성 예시
CREATE DATABASE restore_test;

이 과정을 거치면 백업 파일이 제대로 열리는지, 그리고 테이블 구조와 데이터가 잘 복구되는지도 확인할 수 있습니다. 백업은 단순히 파일을 만드는 게 아니라, 언제든 복구할 수 있는 상태를 준비해 두는 일에 더 가깝다고 볼 수 있습니다.

정기 백업을 위한 기본 방향

수동 백업 과정을 이해했다면 이제 정기적인 백업 단계로 넘어갈 차례입니다. 처음부터 복잡하게 자동화하는 것보다, 우선 어떤 데이터를 어떤 주기로 어디에 저장할지부터 결정하는 게 좋습니다.

항목	권장 방향	운영 이유
백업 주기	일 단위 또는 주 단위 검토	데이터 변경 빈도에 따라 조정
보관 위치	서버 내부 + 외부 저장소	장비 장애 대비
파일명	날짜 포함	복구 시점 확인
복구 테스트	정기적으로 확인	백업 파일 유효성 검증
민감정보	접근 권한 관리	DB 백업 파일 노출 방지

DB 백업 파일에는 종종 사용자 정보나 서비스 설정값이 담겨 있을 수 있습니다. 그래서 이런 백업 파일을 클라우드나 외부 저장소에 저장할 때는 접근 권한을 잘 설정하고, 암호화가 제대로 되어 있는지도 꼭 확인해야 합니다.

운영 로그

아래 표는 6주차 금요일을 기준으로 MariaDB Docker 환경의 백업 점검 항목을 정리한 것입니다. 실제로 백업 방법이나 주기는 데이터의 중요도, 서비스 이용량, 저장 방식, 그리고 복구 목표 등에 따라 달라질 수 있습니다.

점검 항목	확인 방법	운영 판단
MariaDB 상태	docker compose ps	백업 전 컨테이너 실행 상태 확인
데이터 위치	./data:/var/lib/mysql	실제 데이터 저장 경로 확인
SQL 백업	mysqldump	DB 단위 백업 기준
보관 위치	내부 저장소, 외장 SSD, NAS 등	단일 장애점 방지
복구 테스트	테스트 DB에 복원	백업 파일 유효성 확인

에디터의 해석 노트 (Editor's Lab Note)

• 처음에는 백업을 나중에 생각해도 된다고 느꼈습니다.
• 하지만 데이터베이스는 운영 기간이 길어질수록 구축보다 데이터 보존이 더 중요해졌습니다.
• Docker 환경에서는 컨테이너보다 데이터 위치를 먼저 이해하는 것이 필요했습니다.
• 백업은 문제가 생긴 뒤에 만드는 것이 아니라, 문제가 생기기 전에 준비하는 운영 습관에 가까웠습니다.

참고 링크 (References)

1. MariaDB dump documentation
2. MariaDB Backup and Restore Overview
3. MariaDB Official Docker Image
4. Docker volumes documentation
5. Docker Compose documentation

트러블슈팅

문제: 컨테이너 삭제 후 데이터가 사라진 것처럼 보임

MariaDB 컨테이너를 삭제하거나 다시 만들었더니 데이터가 없어졌다고 느껴진다면, 가장 먼저 데이터가 실제로 어디에 저장되어 있었는지 살펴봐야 합니다. 데이터가 컨테이너 내부에만 저장됐거나, 새로 만든 Compose 파일이 기존과 다른 경로를 참조하고 있을 수도 있습니다. 이 부분을 잘 확인하는 게 중요합니다.

확인: Volume 또는 Bind Mount 사용 여부, 백업 파일 존재 여부, Compose 설정을 순서대로 점검

# Compose 설정 확인
docker compose config

# 데이터 디렉터리 확인
ls -la /opt/docker/mariadb/data

# 백업 파일 확인
ls -lh /opt/backup/mariadb

# 컨테이너 로그 확인
docker compose logs mariadb --tail=100

원인: 컨테이너만 믿고 데이터 경로를 분리하지 않았거나, 백업 파일이 없거나, 재생성 시 다른 경로를 연결함

해결: mysqldump 백업과 데이터 디렉터리 백업을 함께 검토하고, 정기 백업과 복구 테스트를 운영 루틴에 포함

현재 구성에서는 컨테이너 실행 여부보다 데이터 위치와 백업 파일 존재 여부를 먼저 확인하는 편이 더 안전했습니다.

마무리

MariaDB 백업 전략을 정리하면서 가장 크게 느낀 점은, 데이터베이스 운영에서 진짜 중요한 건 설치 과정이 아니라 데이터를 안전하게 지키는 일이라는 것입니다. MariaDB는 필요하면 언제든지 다시 설치할 수 있지만, 한 번 잃어버린 데이터는 되돌릴 방법이 거의 없거든요. 그래서 백업의 중요성을 다시 한 번 실감하게 됩니다.

화요일에는 MariaDB를 설치했고, 수요일에는 사용자 계정과 권한을 설정했습니다. 목요일에는 성능을 높이는 방법과 인덱스의 기본에 대해 알아봤습니다. 그리고 금요일에는 데이터를 어떻게 안전하게 지킬 수 있을지 고민해보았습니다.

화요일에는 MariaDB를 설치했고, 수요일에는 사용자 계정과 권한을 직접 설정해보았습니다. 목요일에는 데이터베이스 성능을 높이는 방법과 인덱스의 기본 개념을 살펴봤어요. 마지막으로 금요일에는 데이터를 안전하게 지키는 방법에 대해 고민했습니다.