treeru.com
네트워크

NFS 콜드백업 서버 구축 — IronWolf 12TB로 데이터 보호

2026-02-11
Treeru

16대 서버 인프라를 운영하면서 가장 두려운 순간은 데이터가 날아가는 겁니다. RAID는 디스크 고장을 버텨주지만, 랜섬웨어나 실수로 인한 삭제는 막지 못합니다.별도의 백업 서버를 두고 주기적으로 데이터를 복제해야 합니다. 저전력 CPU에 IronWolf 12TB 두 대를 넣은 NFS 콜드백업 서버를 구축한 과정을 공유합니다.

24TB

총 저장 용량

12TB

RAID 1 가용 용량

~15W

평균 소비전력

매일 2AM

자동 백업

1왜 콜드백업 서버인가

백업의 핵심 원칙은 3-2-1 전략입니다: 데이터 3개 사본, 2종류의 미디어, 1개는 오프사이트. NFS 콜드백업 서버는 이 전략의 핵심인 “별도의 미디어에 복사본 유지”를 담당합니다. AI 서버용 3-Tier 스토리지 전략과 조합하면 효율적인 저장 구조를 구성할 수 있습니다.

백업 방식장점단점비용 (12TB 기준)
상용 NASGUI 관리, 앱 생태계고가, 벤더 종속80~150만원
클라우드 백업오프사이트, 무제한 확장월 과금, 복구 시간월 3~10만원
NFS 자체 구축완전한 커스텀, 저비용수동 설정 필요40~60만원 (일회성)

16대 서버 인프라처럼 여러 대의 서버를 백업해야 하는 환경에서는 NFS 콜드백업 서버가 실용적입니다.

NFS를 선택한 이유

Linux 서버 간 파일 공유에서 NFS는 프로토콜 오버헤드가 가장 적습니다. SMB/CIFS보다 빠르고, iSCSI보다 설정이 간단합니다. 백업 서버와 운영 서버가 같은 LAN에 있는 환경에서 최적의 선택입니다.

2하드웨어 구성

부품모델비고
CPU저전력 CPU (N100급)백업 서버에 고성능 불필요
RAM32GB DDR4NFS 캐싱에 여유로운 용량
HDDSeagate IronWolf 12TB x 2NAS/서버 전용, 24/7 운영 설계
NIC2.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_FILE

cron 등록

# 실행 권한 부여
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/24VLAN 10
eth1 (2.5GbE)백업 전용10.x.50.0/24VLAN 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 백업 서버 구축, 자동 백업 설정, 재해 복구 계획 수립까지 지원합니다. 소중한 데이터를 안전하게 보호하세요.

백업 시스템 상담
T

Treeru

웹 개발, IT 인프라, AI 솔루션 분야의 실무 인사이트를 공유합니다. 기업의 디지털 전환을 돕는 IT 파트너, Treeru입니다.

공유

댓글

(5개)
4.50/ 5

로그인하면 댓글을 작성할 수 있습니다.

2026-02-25
4.554.5

3-2-1 백업 전략 설명이 간결합니다. 클라우드 백업은 비용이 너무 나가서, 로컬 콜드백업 + 주요 데이터만 클라우드라는 조합이 현실적이에요.

2026-02-22
454.0

rsync + cron 조합이 심플하면서도 강력합니다. 증분 백업이라 매일 돌려도 시간이 얼마 안 걸린다는 게 좋네요. 바로 적용했습니다.

2026-02-18
555.0

듀얼 NIC로 백업 트래픽을 분리하는 아이디어가 인상적입니다. 백업 시간에 업무 네트워크가 느려지는 문제를 이걸로 해결할 수 있겠네요.

관련 글

© 2026 TreeRU. All rights reserved.

본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.