매일 자동으로 백업하기 : cron과 Docker 자동화

 

 

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

매일 자동으로 백업하기 : cron과 Docker 자동화

도입

처음 홈서버를 운영할 때는 백업을 직접 실행했습니다. mysqldump 명령을 입력하고 SQL 파일이 생성되는 것을 확인하면 마음이 놓였습니다. 하지만 며칠 지나자 현실은 달랐습니다. 퇴근 후 다른 작업을 하다 보면 백업을 잊어버리는 날이 생겼고, 어느새 마지막 백업이 일주일 전인 경우도 있었습니다.

백업은 한 번 성공하는 것보다 꾸준히 이어지는 것이 더 중요합니다. 장애는 미리 알려주지 않기 때문입니다. 서버가 정상일 때는 백업의 중요성을 잊기 쉽지만, 문제가 발생하는 순간에는 "어제만 백업했어도..."라는 후회를 하게 됩니다.

그래서 저는 백업을 사람이 기억해서 하는 작업이 아니라, 시스템이 알아서 실행하는 작업으로 바꾸는 것이 필요하다고 느꼈습니다. 이번 글에서는 Docker 환경에서 MariaDB 백업을 자동화하는 가장 기본적인 흐름을 정리해 보겠습니다.

cron과 Shell Script를 이용해 Docker 환경의 MariaDB를 매일 자동으로 백업하고, 날짜별 SQL 파일 생성, 백업 로그 기록, 오래된 백업 삭제까지 자동화하는 전체 운영 흐름을 정리했습니다.

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

본문

① 왜 자동 백업이 필요할까?

사람은 반복되는 작업을 자주 잊어버립니다. 특히 홈서버처럼 본업과 함께 운영하는 환경에서는 더욱 그렇습니다. 매일 저녁 백업하기로 마음먹어도 야근이나 약속이 생기면 쉽게 미뤄집니다.

하루 이틀은 괜찮다고 생각할 수 있습니다. 하지만 백업을 미루는 시간이 길어질수록 장애가 발생했을 때 되돌아갈 수 있는 시점도 멀어집니다. 마지막 백업이 어제인지, 일주일 전인지, 한 달 전인지에 따라 복구 후 손실되는 데이터의 양도 달라집니다.

자동화는 이런 실수를 줄여줍니다. 한 번만 제대로 설정해 두면 정해진 시간마다 같은 방식으로 백업을 수행하기 때문입니다. 운영자는 매일 명령어를 입력하는 대신, 정상적으로 실행됐는지만 확인하면 됩니다.

• 백업을 잊어버리는 일을 줄일 수 있습니다.
• 정해진 시간에 같은 방식으로 백업을 실행할 수 있습니다.
• 날짜별 파일을 남겨 복구 시점을 선택할 수 있습니다.
• 로그를 남겨 백업 성공 여부를 확인할 수 있습니다.
• 오래된 백업을 정리해 디스크 용량을 관리할 수 있습니다.

좋은 백업은 사람이 기억해서 하는 것이 아니라, 시스템이 반복해서 수행하는 구조에 가깝습니다.

② Shell Script로 백업 작업 만들기

자동화를 위해서는 먼저 백업 과정을 하나의 스크립트로 만들어야 합니다. 매번 긴 명령어를 직접 입력하는 대신, 백업 명령과 저장 위치, 파일 이름 규칙을 스크립트 안에 정리해 두는 방식입니다.

예를 들어 backup-mariadb.sh라는 파일을 만들고, 그 안에 MariaDB 덤프 명령을 넣을 수 있습니다.

#!/bin/bash

BACKUP_DIR="/home/user/backups/mariadb"
DATE=$(date +%Y%m%d)
CONTAINER_NAME="mariadb"
DB_NAME="wordpress"
DB_USER="root"

mkdir -p "$BACKUP_DIR"

docker exec "$CONTAINER_NAME" mysqldump \
  -u "$DB_USER" -p "$DB_NAME" \
  > "$BACKUP_DIR/${DB_NAME}_${DATE}.sql"

위 예시는 기본 구조를 보여주기 위한 형태입니다. 실제 운영에서는 비밀번호를 어떻게 입력할지, 전용 사용자 계정을 사용할지, 백업 파일을 압축할지 등을 환경에 맞게 정해야 합니다.

중요한 것은 백업 파일 이름에 날짜를 넣는 것입니다. 예를 들어 오늘 백업은 wordpress_20260623.sql처럼 저장하고, 내일 백업은 wordpress_20260624.sql처럼 저장하면 이력 관리가 쉬워집니다.

③ 스크립트 실행 권한 설정하기

Shell Script 파일을 만들었다면 실행 권한을 부여해야 합니다. 권한이 없으면 cron이 스크립트를 호출해도 실행되지 않을 수 있습니다.

chmod +x backup-mariadb.sh

그리고 cron에 등록하기 전에 먼저 직접 실행해보는 것이 좋습니다.

./backup-mariadb.sh

직접 실행했을 때 백업 파일이 생성되는지 확인합니다.

ls -lh /home/user/backups/mariadb

자동화에서 가장 흔한 실수는 스크립트 자체가 정상인지 확인하지 않고 바로 cron에 등록하는 것입니다. 수동 실행이 먼저 성공해야 자동 실행도 안정적으로 점검할 수 있습니다.

④ cron으로 매일 자동 실행하기

Linux에서는 cron을 이용해 정해진 시간에 명령을 실행할 수 있습니다. 홈서버 운영에서는 백업, 로그 정리, 상태 점검 같은 반복 작업에 자주 사용됩니다.

crontab을 편집하려면 아래 명령을 사용합니다.

crontab -e

예를 들어 매일 새벽 2시에 백업 스크립트를 실행하려면 다음과 같이 등록할 수 있습니다.

0 2 * * * /home/user/scripts/backup-mariadb.sh

항목	의미
0	0분
2	새벽 2시
*	매일
*	매월
*	요일 제한 없음

이 설정은 매일 새벽 2시 0분에 지정한 스크립트를 실행하라는 의미입니다. 새벽 시간은 일반적으로 사용량이 적기 때문에 백업 작업을 예약하기에 적합합니다.

⑤ 오래된 백업 자동 삭제하기

자동 백업만 설정하면 시간이 지날수록 백업 파일이 계속 늘어납니다. 백업은 중요하지만 저장 공간도 함께 관리해야 합니다.

예를 들어 하루에 한 번씩 백업하면 한 달 뒤에는 30개의 SQL 파일이 쌓입니다. 여러 데이터베이스를 운영한다면 용량은 더 빠르게 증가할 수 있습니다.

그래서 일정 기간이 지난 백업 파일은 자동으로 삭제하도록 설정하는 것이 좋습니다. 예를 들어 30일이 지난 SQL 파일을 삭제하려면 스크립트에 다음과 같은 명령을 추가할 수 있습니다.

find "$BACKUP_DIR" -type f -name "*.sql" -mtime +30 -delete

이 명령은 지정한 백업 폴더에서 30일보다 오래된 .sql 파일을 찾아 삭제합니다. 다만 보관 기간은 운영 환경에 따라 신중하게 정해야 합니다. 너무 짧게 잡으면 필요한 시점의 백업이 사라질 수 있고, 너무 길게 잡으면 디스크 용량이 빠르게 줄어들 수 있습니다.

⑥ 로그를 남기는 습관

자동화에서 가장 중요한 것은 정말 실행되었는지 확인하는 것입니다. 백업 스크립트가 등록되어 있다고 해서 매일 성공한다고 볼 수는 없습니다.

컨테이너 이름이 바뀌었거나, DB 비밀번호가 달라졌거나, 백업 폴더 권한이 바뀌면 자동 백업은 실패할 수 있습니다. 그래서 실행 결과를 로그 파일에 남기는 습관이 필요합니다.

LOG_FILE="/home/user/backups/mariadb/backup.log"

echo "[$(date '+%Y-%m-%d %H:%M:%S')] Backup start" >> "$LOG_FILE"

docker exec "$CONTAINER_NAME" mysqldump \
  -u "$DB_USER" -p "$DB_NAME" \
  > "$BACKUP_DIR/${DB_NAME}_${DATE}.sql" 2>> "$LOG_FILE"

echo "[$(date '+%Y-%m-%d %H:%M:%S')] Backup end" >> "$LOG_FILE"

로그를 남기면 나중에 문제가 생겼을 때 백업이 언제부터 실패했는지 확인할 수 있습니다. 자동화는 설정하는 것보다 확인하는 습관이 더 중요합니다.

⑦ 실제 운영 흐름으로 정리하기

이번 글에서 만든 자동 백업 흐름을 정리하면 아래와 같습니다.

매일 새벽 2시
↓
cron이 백업 스크립트 실행
↓
Docker 컨테이너 안에서 mysqldump 실행
↓
날짜별 SQL 파일 생성
↓
오래된 백업 파일 삭제
↓
실행 결과 로그 저장
↓
주기적으로 복구 테스트

처음부터 복잡한 백업 시스템을 만들 필요는 없습니다. 오히려 매일 한 번 안정적으로 실행되는 단순한 자동 백업이 더 현실적일 수 있습니다.

운영 철학

자동화는 편리함을 위한 기능이 아니라, 데이터를 지키기 위한 최소한의 안전장치입니다.

운영노트

아래 표는 Docker 환경에서 MariaDB 자동 백업을 설계할 때 확인할 수 있는 항목입니다. 실제 경로와 컨테이너 이름은 운영 환경에 맞게 조정해야 합니다.

확인 항목	운영 기준	확인 방법
스크립트 위치	고정 경로 사용	/home/user/scripts 등
실행 권한	chmod +x 적용	수동 실행 테스트
백업 주기	매일 1회	crontab -e
파일명	날짜 포함	YYYYMMDD 형식
보관 기간	예: 30일	find -mtime
로그	성공과 오류 기록	backup.log

에디터의 해석노트

처음에는 백업 명령을 직접 실행하는 것만으로도 충분하다고 생각했습니다. 하지만 운영이 길어질수록 사람이 기억해서 하는 백업은 오래 유지하기 어렵다는 것을 느꼈습니다.

자동화는 단순히 시간을 아끼는 기능이 아니었습니다. 반복되는 작업에서 사람이 실수할 가능성을 줄여주는 장치에 가까웠습니다. 특히 백업처럼 놓치면 큰 문제가 되는 작업은 자동화의 효과가 더 크게 느껴집니다.

다만 자동화했다고 끝은 아니었습니다. 로그를 확인하고, 파일이 정상적으로 만들어졌는지 보고, 일정 주기로 복구 테스트까지 해야 자동 백업을 믿을 수 있습니다.

참고 링크 (References)

1. crontab Manual Page
2. MariaDB Dump Documentation
3. MariaDB Backup and Restore Overview
4. Docker exec Reference
5. Docker Compose Documentation

트러블슈팅

문제: cron에 등록했는데 MariaDB 자동 백업 파일이 생성되지 않음

자동 백업이 실패할 때는 cron 자체의 문제인지, Shell Script 문제인지, Docker 명령 문제인지 나누어 확인해야 합니다. 먼저 스크립트를 직접 실행해보고, 그다음 cron 실행 환경을 점검하는 것이 좋습니다.

확인: 스크립트 실행 권한, 경로, Docker 컨테이너 이름, 로그 파일을 순서대로 확인합니다.

# crontab 등록 내용 확인
crontab -l

# 스크립트 실행 권한 확인
ls -l /home/user/scripts/backup-mariadb.sh

# 직접 실행 테스트
/home/user/scripts/backup-mariadb.sh

# Docker 컨테이너 이름 확인
docker ps

# 로그 확인
tail -n 50 /home/user/backups/mariadb/backup.log

원인: cron 경로 문제, 스크립트 실행 권한 없음, Docker 명령 경로 문제, 컨테이너 이름 변경, 백업 폴더 권한 문제, 비밀번호 입력 방식 문제

해결: cron에 등록하기 전에 스크립트를 수동으로 실행해 성공 여부를 확인합니다. cron에서는 환경변수가 다르게 적용될 수 있으므로 가능하면 절대 경로를 사용하고, 실행 결과를 로그로 남깁니다.

• 스크립트가 실행되지 않음: chmod +x 권한을 확인합니다.
• cron에서는 실패: 명령어와 파일 경로를 절대 경로로 바꿔 확인합니다.
• 컨테이너를 찾지 못함: docker ps로 실제 컨테이너 이름을 확인합니다.
• 백업 파일이 0바이트: mysqldump 오류가 발생했는지 로그를 확인합니다.
• 디스크 용량 부족: 오래된 백업 삭제 규칙을 점검합니다.

자동화는 한 번 등록하고 잊어버리는 기능이 아닙니다. 제대로 실행되고 있는지 정기적으로 확인해야 운영에 사용할 수 있는 자동 백업이 됩니다.

마무리

이번 글에서는 cron과 Shell Script를 이용해 Docker 환경의 MariaDB 백업을 자동화하는 기본 흐름을 살펴봤습니다. 백업 스크립트를 만들고, 날짜별 파일을 생성하고, cron으로 매일 실행하며, 오래된 백업 파일과 로그까지 함께 관리하는 구조였습니다.

백업은 한 번 성공하는 것보다 꾸준히 이어지는 것이 중요합니다. 사람이 매일 기억해서 실행하는 방식은 언젠가 빠질 수 있습니다. 그래서 백업은 시스템이 반복하도록 맡기고, 운영자는 결과를 확인하는 방향으로 가는 것이 더 안정적입니다.

다음 글에서는 이렇게 만들어진 백업 파일을 어디에 보관해야 안전한지 살펴보겠습니다. 서버 내부에만 둘 것인지, 외장하드와 NAS, 클라우드를 어떻게 함께 사용할 것인지 정리해보겠습니다.