서버 보안기술 정보 확인 2026-10-24수정 2026-10-24

서버 백업 방법, 3-2-1 원칙과 파일 DB 자동 백업

서버는 언젠가 고장 나거나, 실수로 파일이 지워지거나, 해킹으로 망가질 수 있습니다. 이때 서버를 원래대로 되돌릴 수 있는 마지막 수단이 백업입니다. 보안 설정을 아무리 잘해도 백업이 없으면 한 번의 사고가 곧 사이트의 끝이 됩니다.

백업은 “만들었다”에서 끝나지 않습니다. 어디에 두는지, 자동으로 도는지, 실제로 복구되는지까지 확인해야 백업입니다. 이 글은 파일과 DB를 나눠서 받는 기본 방법과 확인 순서를 정리합니다.

무엇을 백업할까

사이트를 다시 세우는 데 필요한 것을 기준으로 나눕니다.

워드프레스라면 wp-config.php와 wp-content 폴더, DB 세 가지가 핵심입니다. 코어 파일은 다시 내려받을 수 있지만 업로드 이미지와 DB는 다시 만들 수 없습니다. 반대로 임시 캐시 폴더는 백업에서 빼 용량을 줄일 수 있습니다.

3-2-1 원칙

백업 업계에서 흔히 쓰는 기준으로, 데이터 사본 3개를 2종류의 저장 매체에 두고 그중 1개는 다른 장소에 보관하자는 원칙입니다. 이 숫자 자체를 설명한 문서는 이 글을 쓰며 확인하지 못했지만, 같은 취지의 설명은 확인했습니다. Ubuntu 서버 문서는 중요한 백업을 재해에 대비해 다른 장소에 보관하는 것이 좋다고 하고, CISA의 랜섬웨어 안내서는 오프라인으로 암호화한 백업을 유지하라고 합니다. 또 많은 랜섬웨어가 접근 가능한 백업을 찾아 지우거나 암호화한다고 경고합니다.

• 서버 디스크에 만든 백업 파일 하나로는 서버가 망가질 때 같이 사라집니다.
• 다른 서버나 오브젝트 저장소에 보낸 사본을 두면 서버 장애와 해킹에서 모두 살아남습니다.
• 서버에서 백업 저장소를 항상 쓰기 가능 상태로 연결해 두면 침해 시 함께 지워질 수 있으니, 접근 권한을 최소로 줍니다.

파일 백업 rsync

rsync는 변경된 파일만 복사하는 도구입니다. 매뉴얼 기준으로 -a는 하위 폴더 포함 복사하면서 권한·시간 등 대부분의 속성을 유지하는 옵션입니다. 단 ACL, xattr, 하드링크는 포함하지 않습니다.

# 먼저 -n으로 시험 실행(실제 복사 없음)
rsync -avn /var/www/html/ /backup/html/

# 문제 없으면 -n을 빼고 실행
rsync -av /var/www/html/ /backup/html/

# 다른 서버로 SSH 전송
rsync -av -e ssh /var/www/html/ backupuser@백업서버:/backup/html/

원본 경로 끝의 슬래시에 따라 결과가 달라집니다. 슬래시가 없으면 폴더 이름까지 대상 안에 생기고, 있으면 폴더 내용만 들어갑니다. --delete는 원본에 없는 파일을 대상에서도 지우므로 처음에는 쓰지 않거나 반드시 -n으로 먼저 확인합니다. 원본에서 실수로 지운 파일이 백업에서도 사라지기 때문입니다.

DB 백업 mysqldump

MySQL 문서의 기본 형식은 mysqldump [options] db_name이며 DB 전체를 받을 때는 --databases를 씁니다.

mysqldump -u 사용자 -p --single-transaction --databases 데이터베이스명 > db_backup.sql

--single-transaction은 InnoDB 테이블을 한 시점의 일관된 상태로 받는 옵션으로 쓰는데, MyISAM 테이블은 이 방식으로 일관성이 보장되지 않습니다. 사용 중인 저장 엔진을 확인하고, 이 옵션의 정확한 동작은 사용 중인 MySQL·MariaDB 버전 문서에서 확인하세요. 복구는 일반적으로 mysql -u 사용자 -p < db_backup.sql로 하는데, 덤프를 다시 올리려면 그 안의 문장을 실행할 권한이 필요하다고 문서에 나옵니다.

비밀번호를 명령줄에 직접 적으면 기록에 남으니, 옵션 파일(권한 600)을 쓰는 방법을 알아 두면 좋습니다. 이 부분은 이 글에서 문서를 확인하지 않아 상세 설정은 적지 않았습니다.

자동화 cron

손으로 하는 백업은 어느 날 빠집니다. 스크립트를 만들어 cron(정해진 시간에 자동 실행하는 기능)에 등록합니다.

#!/bin/bash
# /usr/local/bin/backup.sh
set -e
DATE=$(date +%F)
mysqldump --defaults-extra-file=/root/.my.cnf --single-transaction --databases mydb | gzip > /backup/db_$DATE.sql.gz
rsync -a /var/www/html/ /backup/html/
find /backup -name 'db_*.sql.gz' -mtime +14 -delete

sudo crontab -e
# 매일 새벽 3시 실행
0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

마지막 줄의 find ... -delete는 14일 지난 DB 덤프를 지우는 정리 단계입니다. 경로를 잘못 적으면 엉뚱한 파일이 지워지니 처음에는 -delete 대신 -print로 대상 목록을 보고 시작합니다. 스크립트 실행 결과를 로그에서 매주 확인해야 조용히 실패하는 일을 막을 수 있습니다.

복구 테스트가 진짜 백업이다

CISA 안내서는 백업의 가용성과 무결성을 정기적으로 시험하라고 권합니다. 최소한 다음을 해 봅니다.

1. 백업 파일의 크기와 날짜가 정상인지 봅니다. 0바이트나 갑자기 줄어든 파일이 신호입니다.
2. 테스트용 서버나 로컬 환경에 파일과 DB를 복구해 사이트가 열리는지 확인합니다.
3. 복구에 걸린 시간과 순서를 기록해 둡니다. 사고 때 이 문서가 큰 도움이 됩니다.

해킹 뒤 복구라면 어느 시점 백업을 쓸지가 중요합니다. 워드프레스 해킹 복구 글에서 순서를 이어서 봅니다. 업데이트 전에는 수동 백업을 하나 더 만들어 두세요(워드프레스 안전 업데이트 글). 전체 점검표는 리눅스 서버 보안 체크리스트에 있습니다.

클라우드 스냅샷, restic·borg 같은 백업 도구는 이 글에서 직접 문서를 확인하지 못해 다루지 않았습니다.