NFS 콜드백업 서버 구축 — IronWolf 12TB로 데이터 보호
16대 서버 인프라를 운영하면서 가장 두려운 순간은 데이터가 날아가는 겁니다. RAID는 디스크 고장을 버텨주지만, 랜섬웨어나 실수로 인한 삭제는 막지 못합니다.별도의 백업 서버를 두고 주기적으로 데이터를 복제해야 합니다. 저전력 CPU에 IronWolf 12TB 두 대를 넣은 NFS 콜드백업 서버를 구축한 과정을 공유합니다.
24TB
총 저장 용량
12TB
RAID 1 가용 용량
~15W
평균 소비전력
매일 2AM
자동 백업
1왜 콜드백업 서버인가
백업의 핵심 원칙은 3-2-1 전략입니다: 데이터 3개 사본, 2종류의 미디어, 1개는 오프사이트. NFS 콜드백업 서버는 이 전략의 핵심인 “별도의 미디어에 복사본 유지”를 담당합니다. AI 서버용 3-Tier 스토리지 전략과 조합하면 효율적인 저장 구조를 구성할 수 있습니다.
| 백업 방식 | 장점 | 단점 | 비용 (12TB 기준) |
|---|---|---|---|
| 상용 NAS | GUI 관리, 앱 생태계 | 고가, 벤더 종속 | 80~150만원 |
| 클라우드 백업 | 오프사이트, 무제한 확장 | 월 과금, 복구 시간 | 월 3~10만원 |
| NFS 자체 구축 | 완전한 커스텀, 저비용 | 수동 설정 필요 | 40~60만원 (일회성) |
16대 서버 인프라처럼 여러 대의 서버를 백업해야 하는 환경에서는 NFS 콜드백업 서버가 실용적입니다.
NFS를 선택한 이유
Linux 서버 간 파일 공유에서 NFS는 프로토콜 오버헤드가 가장 적습니다. SMB/CIFS보다 빠르고, iSCSI보다 설정이 간단합니다. 백업 서버와 운영 서버가 같은 LAN에 있는 환경에서 최적의 선택입니다.
2하드웨어 구성
| 부품 | 모델 | 비고 |
|---|---|---|
| CPU | 저전력 CPU (N100급) | 백업 서버에 고성능 불필요 |
| RAM | 32GB DDR4 | NFS 캐싱에 여유로운 용량 |
| HDD | Seagate IronWolf 12TB x 2 | NAS/서버 전용, 24/7 운영 설계 |
| NIC | 2.5GbE x 2포트 | 업무 + 백업 트래픽 분리 |
| RAID | 소프트웨어 RAID 1 (mdadm) | 디스크 1대 고장 시 데이터 보존 |
| 소비전력 | 유휴 ~10W / 백업 시 ~20W | 월 전기세 약 2,000원 |
왜 IronWolf인가
IronWolf는 Seagate의 NAS/서버 전용 HDD 라인업입니다. 24/7 구동에 최적화된 펌웨어, 진동 센서 내장, 워크로드 한도 180TB/년으로 일반 데스크톱 HDD보다 서버 환경에서의 내구성이 월등합니다. 12TB 모델은 가격 대비 용량이 가장 효율적인 구간입니다.
3NFS 서버 설정
RAID 1 구성
# 디스크 확인 lsblk # sda: 12TB (IronWolf #1) # sdb: 12TB (IronWolf #2) # RAID 1 생성 (미러링) # 참고: 프로덕션 환경에서는 디스크 전체(/dev/sda) 대신 # 파티션(/dev/sda1)을 사용하는 것이 권장됩니다. # 파티션을 먼저 생성하면 디스크 교체 시 호환성이 높아집니다. sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb # 파일시스템 생성 sudo mkfs.ext4 /dev/md0 # 마운트 포인트 생성 및 마운트 sudo mkdir -p /backup sudo mount /dev/md0 /backup # /etc/fstab에 영구 마운트 등록 echo '/dev/md0 /backup ext4 defaults 0 2' | sudo tee -a /etc/fstab # RAID 설정 저장 sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
NFS 서버 설치 및 설정
# NFS 서버 설치 sudo apt install nfs-kernel-server # 공유 디렉토리 설정 sudo mkdir -p /backup/server-a sudo mkdir -p /backup/server-b sudo mkdir -p /backup/server-c # /etc/exports 설정 # 서버 서브넷(10.x.10.0/24)에서만 접근 허용 echo '/backup/server-a 10.x.10.0/24(rw,sync,no_subtree_check,root_squash)' | sudo tee -a /etc/exports echo '/backup/server-b 10.x.10.0/24(rw,sync,no_subtree_check,root_squash)' | sudo tee -a /etc/exports echo '/backup/server-c 10.x.10.0/24(rw,sync,no_subtree_check,root_squash)' | sudo tee -a /etc/exports # root_squash: 클라이언트의 root 요청을 nobody로 매핑하여 보안 강화 # 백업 스크립트에서 파일 소유권이 필요하면 rsync --no-perms 옵션을 사용하세요 # 설정 적용 sudo exportfs -ra # NFS 서비스 시작 sudo systemctl enable nfs-kernel-server sudo systemctl start nfs-kernel-server # 공유 확인 showmount -e localhost
4클라이언트 자동 마운트
# 각 서버(클라이언트)에서 실행 # NFS 클라이언트 설치 sudo apt install nfs-common # 마운트 포인트 생성 sudo mkdir -p /mnt/backup # 수동 마운트 테스트 sudo mount -t nfs 10.x.10.20:/backup/server-a /mnt/backup # 마운트 확인 df -h /mnt/backup # 10.x.10.20:/backup/server-a 12T 1.2T 11T 10% /mnt/backup # /etc/fstab에 영구 마운트 등록 echo '10.x.10.20:/backup/server-a /mnt/backup nfs defaults,_netdev,soft,timeo=150 0 0' | sudo tee -a /etc/fstab # _netdev: 네트워크가 준비된 후 마운트 # soft: NFS 서버 다운 시 타임아웃 (hard는 무한 대기) # timeo=150: 15초 타임아웃
soft vs hard 마운트
soft는 NFS 서버가 응답하지 않으면 일정 시간 후 에러를 반환합니다. hard는 서버가 응답할 때까지 무한 대기합니다. 백업용으로는 soft가 적합합니다. 백업 서버 장애 시 운영 서버까지 멈추는 것을 방지합니다.
5rsync + cron 자동 백업
rsync는 변경된 파일만 전송하는 증분 백업이 가능합니다. 처음에만 전체 복사가 이루어지고, 이후에는 변경분만 동기화하므로 빠릅니다.
백업 스크립트
#!/bin/bash
# /usr/local/bin/backup.sh
BACKUP_DIR="/mnt/backup"
LOG_FILE="/var/log/backup.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')
# NFS 마운트 확인
if ! mountpoint -q $BACKUP_DIR; then
echo "[$DATE] ERROR: NFS not mounted" >> $LOG_FILE
exit 1
fi
# 중요 디렉토리 백업
rsync -avz --delete \
--exclude='.cache' \
--exclude='node_modules' \
--exclude='__pycache__' \
/home/ $BACKUP_DIR/home/ \
>> $LOG_FILE 2>&1
rsync -avz --delete \
/etc/ $BACKUP_DIR/etc/ \
>> $LOG_FILE 2>&1
rsync -avz --delete \
/var/lib/docker/volumes/ $BACKUP_DIR/docker-volumes/ \
>> $LOG_FILE 2>&1
# 데이터베이스 덤프 후 백업
pg_dumpall -U postgres > /tmp/db_backup.sql 2>/dev/null
if [ -f /tmp/db_backup.sql ]; then
rsync -avz /tmp/db_backup.sql $BACKUP_DIR/db/ >> $LOG_FILE 2>&1
rm /tmp/db_backup.sql
fi
echo "[$DATE] Backup completed" >> $LOG_FILEcron 등록
# 실행 권한 부여 sudo chmod +x /usr/local/bin/backup.sh # crontab 등록 (매일 새벽 2시) sudo crontab -e # 추가할 내용: 0 2 * * * /usr/local/bin/backup.sh # cron 로그 확인 tail -f /var/log/backup.log
rsync --delete 옵션 주의
--delete는 원본에서 삭제된 파일을 백업에서도 삭제합니다. 실수로 파일을 지운 경우 백업에서도 사라질 수 있으므로, 일별 스냅샷 디렉토리를 추가하거나 --backup 옵션을 사용하는 것도 고려하세요.
6듀얼 NIC로 백업 트래픽 분리
백업 시 대량의 데이터가 이동하면 업무 네트워크에 영향을 줄 수 있습니다. 백업 서버에 NIC 2개를 장착하여, 한쪽은 업무용, 다른 쪽은 백업 전용으로 분리합니다.
| NIC | 용도 | 서브넷 | VLAN |
|---|---|---|---|
| eth0 (2.5GbE) | 업무 네트워크 | 10.x.10.0/24 | VLAN 10 |
| eth1 (2.5GbE) | 백업 전용 | 10.x.50.0/24 | VLAN 50 |
# 백업 서버 네트워크 설정 (/etc/netplan/01-config.yaml)
network:
ethernets:
eth0:
addresses: [10.x.10.20/24]
routes:
- to: default
via: 10.x.10.1
eth1:
addresses: [10.x.50.20/24]
# 백업 전용 NIC는 기본 게이트웨이 없음
# 운영 서버에서 NFS 마운트 시 백업 전용 IP 사용
sudo mount -t nfs 10.x.50.20:/backup/server-a /mnt/backup트래픽 분리 효과
백업 트래픽이 별도 NIC/서브넷으로 흐르므로, 새벽 2시에 수 TB 규모의 백업이 진행되어도 업무 네트워크(VLAN 10)의 속도에는 영향이 없습니다.
7백업 상태 모니터링
HDD 상태 모니터링 (SMART)
# smartmontools 설치 sudo apt install smartmontools # SMART 상태 확인 sudo smartctl -a /dev/sda # 주요 확인 항목: # Reallocated_Sector_Ct: 재할당 섹터 (0이어야 정상) # Current_Pending_Sector: 대기 중 불량 섹터 (0이어야 정상) # Temperature_Celsius: HDD 온도 (40°C 이하 권장) # Power_On_Hours: 가동 시간 # RAID 상태 확인 cat /proc/mdstat # md0 : active raid1 sda[0] sdb[1] # [UU] ← 둘 다 정상
백업 완료 확인 스크립트
#!/bin/bash
# /usr/local/bin/backup-check.sh
LOG="/var/log/backup.log"
TODAY=$(date '+%Y-%m-%d')
# 오늘 백업 로그 확인
if grep -q "$TODAY.*Backup completed" $LOG; then
echo "OK: 백업 완료"
else
echo "WARNING: 오늘 백업 미완료!"
# 알림 발송 (선택)
# curl -X POST "https://hooks.slack.com/..." -d '{"text":"백업 미완료 경고"}'
fi
# 디스크 사용량 확인
USAGE=$(df -h /backup | tail -1 | awk '{print $5}' | tr -d '%')
if [ "$USAGE" -gt 85 ]; then
echo "WARNING: 백업 디스크 $USAGE% 사용"
fi
# RAID 상태 확인
if ! grep -q "\[UU\]" /proc/mdstat; then
echo "CRITICAL: RAID 디스크 장애 감지!"
fi백업은 검증하지 않으면 의미 없음
“백업을 했는데 복원이 안 된다”는 최악의 시나리오입니다. 분기별로 실제 백업 데이터로 복원 테스트를 수행하세요. 파일 몇 개를 백업에서 꺼내 원본과 비교하는 것만으로도 충분합니다.
정리
NFS 콜드백업 서버 구축 체크리스트
- 저전력 CPU + 32GB RAM + IronWolf 12TB x 2 (RAID 1) 구성
- mdadm으로 소프트웨어 RAID 1 생성 — 디스크 1대 고장 시 데이터 보존
- NFS 서버 설치 및 /etc/exports에 공유 디렉토리 설정
- 클라이언트에서 /etc/fstab으로 자동 마운트 (soft 옵션 권장)
- rsync + cron으로 매일 새벽 자동 백업
- 듀얼 NIC로 백업 트래픽을 업무 네트워크와 분리
- smartctl로 HDD SMART 상태 정기 확인
- 분기별 백업 복원 테스트로 실제 복구 가능 여부 검증
데이터 백업은 보험과 같습니다. 사고가 나기 전에는 비용으로 느껴지지만, 사고가 난 후에는 가장 가치 있는 투자입니다. IronWolf 12TB 두 대와 저전력 CPU를 조합하면, 월 전기세 2,000원 정도로 12TB 규모의 안전한 백업 시스템을 운영할 수 있습니다.
본 글은 실제 사무실 환경에서 NFS 백업 서버를 운영한 경험을 기반으로 작성되었습니다. IP 주소, 디렉토리 경로 등은 예시이며 실제 환경에 맞게 변경해야 합니다. RAID는 백업을 대체하지 않습니다. RAID와 별도 백업은 각각 필요합니다. 본 콘텐츠의 비상업적 공유는 자유이나, 상업적 이용 시 문의 페이지를 통해 연락 바랍니다.
데이터 백업 체계가 필요하신가요?
Treeru는 NFS/NAS 백업 서버 구축, 자동 백업 설정, 재해 복구 계획 수립까지 지원합니다. 소중한 데이터를 안전하게 보호하세요.
백업 시스템 상담댓글
(5개)로그인하면 댓글을 작성할 수 있습니다.
3-2-1 백업 전략 설명이 간결합니다. 클라우드 백업은 비용이 너무 나가서, 로컬 콜드백업 + 주요 데이터만 클라우드라는 조합이 현실적이에요.
rsync + cron 조합이 심플하면서도 강력합니다. 증분 백업이라 매일 돌려도 시간이 얼마 안 걸린다는 게 좋네요. 바로 적용했습니다.
듀얼 NIC로 백업 트래픽을 분리하는 아이디어가 인상적입니다. 백업 시간에 업무 네트워크가 느려지는 문제를 이걸로 해결할 수 있겠네요.
관련 글
© 2026 TreeRU. All rights reserved.
본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.