IT 인프라를 운영하는 시스템 엔지니어에게 시스템 다운타임과 데이터 유실은 언제든 발생할 수 있는 가장 치명적인 위험 요소입니다. 하드웨어 장애, 랜섬웨어 감염, 관리자의 명령어 실수(예: rm -rf), 혹은 지진이나 화재 같은 자연재해까지, 서비스 중단을 일으키는 원인은 다양합니다.
이러한 위기 상황에서 비즈니스의 연속성을 유지하고 자산을 안전하게 보호할 수 있는 최후의 보루가 바로 백업(Backup)과 재해 복구(DR, Disaster Recovery) 전략입니다. 리눅스 환경에서의 효율적인 백업 아키텍처 수립과 스크립트 기반 실무 예제, 그리고 재해 복구 가동을 위한 필수 보안 점검 체크리스트까지 종합적으로 다루어 보겠습니다.
성공적인 백업 시스템을 설계할 때 업계 표준으로 통용되는 최우선 원칙은 '3-2-1 백업 법칙'입니다. 이 법칙은 데이터 유실 확률을 수학적으로 제로에 가깝게 줄이기 위한 격리 전략입니다.
3 (Three Copies): 원본 데이터를 포함하여 최소 3개 이상의 복사본을 유지합니다.
2 (Two Different Media): 최소 2가지 이상의 서로 다른 매체(미디어)에 데이터를 저장합니다. 예를 들어 내부 서버의 로컬 디스크(SSD/HDD)에 하나를 저장했다면, 다른 하나는 네트워크 연결 스토리지(NAS)나 외장 테이프 장치에 보관하는 방식입니다. 한쪽 매체가 물리적으로 손상되더라도 다른 매체에서 복구하기 위함입니다.
1 (One Offsite Location): 최소 1개 이상의 복사본은 완전히 분리된 원격지(Offsite)에 보관합니다. 주 데이터센터에 화재나 홍수가 발생했을 때 내부의 모든 물리 매체가 동시에 파괴될 수 있으므로, 원격지 DR 센터나 퍼블릭 클라우드(AWS S3, 삼성 클라우드 플랫폼 등)의 독립된 리전에 데이터를 실시간 또는 주기적으로 동기화해야 합니다.
리눅스 시스템은 강력한 내장 명령어를 활용하여 추가 비용 없이 고성능 백업 시스템을 구축할 수 있습니다. 가장 대중적으로 쓰이는 세 가지 도구는 다음과 같습니다.
tar: 여러 파일과 디렉토리를 하나의 아카이브 파일로 묶고 압축(gzip, bzip2 등)할 때 사용합니다. 소규모 설정 파일 백업에 유리합니다.
rsync: 파일의 변경된 부분(Delta)만 비교하여 원격지 또는 다른 디렉토리로 동기화하는 증분 백업의 최강자입니다. 대용량 데이터 전송 시 대역폭을 크게 절약합니다.
dd: 블록 디바이스(디스크 파티션 전체)를 비트 단위로 그대로 복사하는 이미지 백업 도구입니다. 운영체제(OS) 환경 전체를 통째로 백업하고 복구할 때 필수적입니다.
주요 웹 서비스 디렉토리와 데이터베이스 덤프 파일을 주기적으로 백업하고, 네트워크를 통해 안전한 원격 백업 서버로 동기화하는 현업 레벨의 Bash 스크립트 예제입니다.
Bash
#!/bin/bash
# 1. 환경 변수 정의
SERVER_NAME="WEB-PROD-01"
SOURCE_DIR="/var/www/html"
DB_USER="backup_user"
DB_NAME="service_db"
BACKUP_DIR="/backup/local"
REMOTE_SERVER="172.16.50.20"
REMOTE_USER="backup_admin"
REMOTE_DIR="/backup/remote/$SERVER_NAME"
DATE=$(date +%Y%m%d_%H%m%s)
# 로그 기록 시작
echo "=== BACKUP STARTED FOR $SERVER_NAME AT $(date) ===" >> /var/log/backup.log
# 2. 로컬 백업 디렉토리 생성 확인
mkdir -p $BACKUP_DIR
# 3. 데이터베이스(MySQL/MariaDB) 안전하게 덤프
# 서비스 중단을 최소화하기 위해 single-transaction 옵션 사용
mysqldump --single-transaction -u$DB_USER $DB_NAME > $BACKUP_DIR/db_dump_$DATE.sql 2>> /var/log/backup.log
if [ $? -eq 0 ]; then
echo "SUCCESS: Database dump completed." >> /var/log/backup.log
else
echo "ERROR: Database dump failed." >> /var/log/backup.log
exit 1
fi
# 4. rsync를 이용한 원격지 보안 동기화 (SSH 포트 22번 활용)
# -a: 아카이브 모드 (권한, 소유권, 타임스탬프 유지)
# -v: 진행 상황 상세 출력
# -z: 데이터 전송 시 압축 수행
# --delete: 원본에서 삭제된 파일은 원격지에서도 삭제하여 동기화 유지
rsync -avz --delete -e "ssh -i /root/.ssh/id_rsa_backup" $SOURCE_DIR $REMOTE_USER@$REMOTE_SERVER:$REMOTE_DIR/web_source/ 2>> /var/log/backup.log
rsync -avz -e "ssh -i /root/.ssh/id_rsa_backup" $BACKUP_DIR/ $REMOTE_USER@$REMOTE_SERVER:$REMOTE_DIR/db_dump/ 2>> /var/log/backup.log
if [ $? -eq 0 ]; then
echo "SUCCESS: Remote synchronization completed successfully." >> /var/log/backup.log
else
echo "ERROR: Remote synchronization failed." >> /var/log/backup.log
exit 1
fi
# 5. 로컬 서버의 디스크 공간 관리를 위해 7일이 지난 예전 DB 덤프 파일 삭제
find $BACKUP_DIR -name "db_dump_*.sql" -mtime +7 -exec rm -f {} \;
echo "=== BACKUP FINISHED AT $(date) ===" >> /var/log/backup.log
재해 복구 전략을 수립할 때 비즈니스 요구사항에 따라 반드시 사전에 정의해야 하는 두 가지 지표가 있습니다. 복구 목표 지점(RPO)과 복구 목표 시간(RTO)입니다.
정의: 재해 발생 시 "얼마나 많은 데이터를 잃어도 감수할 수 있는가"에 대한 기준점입니다.
설명: 만약 백업을 매일 밤 12시에 한 번만 수행한다면, 다음 날 오후 11시에 재해가 발생했을 때 최대 23시간 분량의 데이터가 유실됩니다. 이 경우 비즈니스의 RPO는 24시간이 됩니다. 실시간 금융 거래 시스템처럼 데이터 유실이 절대 용납되지 않는 서비스는 RPO가 0에 가까워야 하므로 블록 레벨의 실시간 동기화(예: DRBD, 스토리지 복제)가 필요합니다.
정의: 재해 발생 시 "서비스를 얼마나 빨리 정상 가동 상태로 복구해야 하는가"에 대한 기준점입니다.
설명: 시스템이 완전히 무너진 순간부터 대체 서버를 켜고, 운영체제를 구성하고, 백업 데이터를 복원하여 사용자가 다시 서비스에 접속할 수 있을 때까지 걸리는 총시간입니다. 대형 이커머스나 공공 서비스의 경우 RTO는 수 분 이내여야 하므로, 주 센터와 부 센터가 동시에 가동되는 Active-Active 구조나 대기 상태인 Active-Standby(Hot Site) 구조를 취해야 합니다.
실제 대규모 장애나 재해가 발생했을 때 엔지니어가 우왕좌왕하지 않고 기계적으로 대응할 수 있도록 표준 운영 절차(SOP)가 마련되어 있어야 합니다.
주 센터의 시스템 제어가 불가능하다고 판단되면 즉시 DR 상황을 선포합니다.
2차 피해(예: 랜섬웨어의 확산 등)를 막기 위해 감염되거나 파괴된 주 센터의 네트워크 연결을 물리적/논리적으로 전면 차단합니다.
미리 준비된 DR 인프라(클라우드 VM 또는 원격지 물리 서버)를 기동합니다.
재해 발생 직전까지 원격지로 안전하게 복제해 둔 백업 데이터(OS 이미지 및 데이터베이스 덤프)를 기반으로 시스템 무결성을 확인하며 복원을 수행합니다.
내부 인프라 복원이 완료되면 외부 사용자의 트래픽을 DR 센터로 유도해야 합니다.
글로벌 서버 로드 밸런싱(GSLB) 정책을 변경하거나 공인 DNS의 A 레코드 주소를 DR 서버의 IP로 전환합니다. TTL(Time to Live) 값이 지나면 전 세계 사용자가 새로운 안전 지대의 서버로 접속하게 됩니다.
아무리 백업 스크립트를 완벽하게 짜두었어도, 백업본 자체가 오염되거나 권한 관리가 부실하면 재해 상황에서 아무런 도움이 되지 않습니다. 다음의 체크리스트를 주기적으로 점검해야 합니다.
[ ] 백업 데이터 암호화 여부: 백업 파일(tar.gz, sql 등)은 원본 데이터의 집합체이므로 유출 시 치명적입니다. GnuPG나 OpenSSL을 이용해 백업본 자체가 암호화되어 저장되는지 점검합니다.
[ ] 백업 저장소 접근 권한 제한: 백업 파일이 저장되는 디렉토리의 권한이 777 등으로 방치되어 있지 않은지 확인합니다. 오직 백업 전용 특수 계정만 접근할 수 있도록 권한을 최소화(700 또는 600)해야 합니다.
[ ] 에어 갭(Air-Gap) 백업 존재 여부: 네트워크로 연결된 모든 백업본은 랜섬웨어 공격자가 서버를 장악했을 때 동시에 암호화되어 파괴될 수 있습니다. 네트워크와 완전히 물리적으로 절연된 오프라인 백업(Immutable Storage 또는 분리된 클라우드 버킷)이 1개 이상 존재해야 합니다.
[ ] 핵심 설정 파일(/etc) 포함 여부: 사용자 데이터뿐만 아니라 /etc/fstab, /etc/passwd, /etc/sysconfig/, /etc/resolv.conf 등 서버 운영에 핵심적인 환경 설정 파일들이 백업 대상에 누락 없이 포함되어 있는지 점검합니다.
[ ] 크론탭(Crontab) 및 자동화 스크립트 백업: 각 계정별 크론탭 설정 파일(/var/spool/cron/)과 시스템 관리용 커스텀 스크립트 경로가 안전하게 복사되고 있는지 확인합니다.
[ ] 정기적 모의 복구 훈련 실시: 복구되지 않는 백업은 백업이 아닙니다. 최소 분기별 혹은 반기별로 1회 이상 백업 데이터를 빈 서버에 실제로 복원하여 서비스가 정상 구동되는지 검증하는 'Failover 모의 훈련'을 수행하고 문서화해야 합니다.
[ ] 자동 모니터링 및 알림 구성: 백업 스크립트가 디스크 공간 부족이나 네트워크 단절로 인해 실패했을 때, 관리자가 로그를 열어보기 전에 시스템 경고 메시지나 이메일, 사내 메신저 웹훅 등을 통해 실패 사실이 즉시 전송되는지 점검합니다.
리눅스 시스템 운영에서 백업과 재해 복구 전략은 단순히 기술적인 스크립트 몇 줄을 작성하는 것에 그치지 않습니다. 비즈니스를 안정적으로 지탱하는 프로세스이자 거대한 방어 체계입니다.
매일 돌아가는 백업 스크립트의 실행 상태를 상시 모니터링하고, 백업 저장소의 보안 권한을 꼼꼼하게 통제하며, 최악의 시나리오를 가정한 복구 훈련을 멈추지 않는 것만이 예측 불가능한 재해의 순간에 인프라와 비즈니스를 원상태로 복구해낼 수 있는 유일한 열쇠입니다.