13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] 홈랩 NAS

  • [Nas] NAS RAID 설정 트러블슈팅: 문제 진단부터 데이터 복구까지 완벽 가이드

    목차

    NAS RAID 문제, 언제 터질지 아무도 모릅니다

    새벽 2시, 갑자기 NAS에서 삐~ 소리가 납니다. 이메일 알림이 쏟아지고, “RAID degraded” 메시지가 화면을 가득 채웁니다. 13년 동안 인프라를 관리해오면서 이런 상황을 몇 번이나 겪었는지 모릅니다. 처음엔 손이 덜덜 떨리더니, 지금은 “아, 또 왔네” 하면서 커피 한 잔 내리고 시작합니다 ㅎㅎ

    NAS RAID 문제 해결은 제때 대응하면 데이터를 살릴 수 있지만, 잘못 건드리면 멀쩡한 디스크까지 날릴 수 있는 위험한 작업입니다. 이 글에서는 제가 직접 겪었던 RAID 설정 오류 상황들과 그 해결 과정을 솔직하게 풀어드리려고 합니다. 혹시 지금 NAS 화면에 빨간 경고등이 켜져 있다면, 일단 침착하게 이 글을 읽어보세요.

    ▲ NAS RAID 구성과 트러블슈팅 흐름도 — 디스크 오류 감지부터 데이터 복구까지의 전체 과정

    RAID가 뭔지 다시 한번 짚고 갑시다

    RAID(Redundant Array of Independent Disks, 독립 디스크 중복 배열)는 쉽게 말해 여러 개의 하드디스크를 하나처럼 묶어서 사용하는 기술입니다. 홈랩에서 Synology나 QNAP NAS를 쓰시는 분들은 대부분 이미 RAID를 사용 중이시죠.

    NAS에서 자주 쓰는 RAID 레벨을 표로 정리해봤습니다:

    RAID 레벨 최소 디스크 특징 허용 고장 디스크 수
    RAID 0 2개 스트라이핑, 성능 최우선 0개 (하나라도 고장 시 전멸)
    RAID 1 2개 미러링, 완전 복제 1개
    RAID 5 3개 패리티 분산, 균형잡힌 선택 1개
    RAID 6 4개 이중 패리티, 안전성 강화 2개
    RAID 10 4개 미러링 + 스트라이핑 각 미러 그룹에서 1개씩

    홈랩에서는 RAID 5나 RAID 1을 많이 쓰시는데, 저도 홈 NAS는 RAID 5로, 중요한 백업 NAS는 RAID 6으로 운영하고 있습니다. RAID 6는 디스크 2개가 동시에 나가도 버티거든요. 비용이 좀 더 들지만 마음이 훨씬 편해요.

    이런 증상이 보이면 RAID에 문제가 생긴 겁니다

    NAS RAID 오류는 보통 세 가지 형태로 나타납니다. 제가 경험했던 증상들을 솔직하게 정리해봤어요.

    1. Degraded 상태 (성능 저하 상태)

    가장 흔한 케이스입니다. 디스크 하나가 고장났지만 아직 RAID는 동작 중인 상태예요. RAID 5 기준으로 디스크 1개가 빠진 거죠. 이 상태에선 데이터는 멀쩡히 접근되는데, 지금 당장 추가 디스크 고장이 나면 데이터 전멸이라는 공포 속에 살게 됩니다.

    증상: NAS 관리 페이지에서 노란색/주황색 경고등, 이메일 알림, 느려진 전송 속도

    2. Failed 상태 (완전 실패 상태)

    RAID 어레이 자체가 죽어버린 상태입니다. RAID 5에서 디스크 2개 이상이 나가거나, RAID 1에서 2개 모두 나간 경우예요. 이럴 땐 데이터에 접근 자체가 안 됩니다. 처음 이 상황을 겪었을 때 솔직히 멍하더라고요 ㅎㅎ

    3. Rebuild 중 추가 오류 (최악의 시나리오)

    새 디스크로 RAID를 복구(리빌드)하는 중에 또 다른 디스크가 나가는 케이스. 제가 경험한 것 중에 가장 심장이 쫄깃했던 상황이었습니다. 리빌드 중에는 I/O가 엄청 늘어나서 이미 약해진 디스크에 스트레스를 더 주거든요.

    NAS RAID 트러블슈팅 단계별 가이드

    자, 이제 본격적으로 RAID 설정 문제를 어떻게 해결하는지 단계별로 알아보겠습니다. 급한 마음에 막 건드리다가 더 큰 일 납니다. 순서대로 차근차근 따라오세요.

    ▲ Synology NAS 스토리지 매니저에서 확인하는 RAID 어레이 상태 및 디스크 health 정보 화면

    Step 1: 현재 상태 정확히 파악하기

    먼저 NAS CLI(명령줄 인터페이스)에 접속해서 현재 RAID 상태를 정확히 봐야 합니다. Linux 기반 NAS라면 대부분 mdadm(MD RAID 관리 도구)을 사용합니다.

    # 현재 RAID 어레이 상태 확인
cat /proc/mdstat

# 특정 어레이 상세 정보
mdadm --detail /dev/md0

# 모든 어레이 스캔
mdadm --detail --scan

    cat /proc/mdstat 결과를 보면 이런 식으로 나와요:

    Personalities : [raid5] [raid6]
md0 : active raid5 sda1[0] sdc1[2] sdd1[3]
      [3/4] [UUU_]    # 언더스코어(_)가 문제 디스크 위치!

# U = 정상, _ = 고장/누락

    이 출력에서 [UUU_]처럼 언더스코어가 보이면, 그 위치의 디스크에 문제가 생긴 겁니다. 여기선 sdb가 빠진 거죠.

    Step 2: 디스크 S.M.A.R.T. 진단 실행

    SMART(Self-Monitoring, Analysis and Reporting Technology, 자가 모니터링 기술)로 각 디스크의 건강 상태를 체크합니다. 이걸 먼저 봐야 어떤 디스크가 진짜 고장인지, 아니면 일시적 오류인지 파악할 수 있어요.

    # SMART 빠른 테스트 (2~5분 소요)
smartctl -t short /dev/sdb

# 테스트 결과 확인
smartctl -a /dev/sdb | grep -E "SMART|Reallocated|Pending|Uncorrectable"

# 전체 상세 정보 출력
smartctl -a /dev/sdb

    주목해야 할 SMART 항목들:

    • Reallocated Sectors Count: 재할당된 섹터 수. 이게 높으면 디스크가 슬슬 죽어가는 중
    • Pending Sectors: 아직 재할당 대기 중인 불량 섹터
    • Uncorrectable Errors: 수정 불가능한 오류. 0이어야 정상
    • Power On Hours: 누적 가동 시간. 너무 오래됐으면 교체 고려

    Step 3: 오류 로그 분석

    시스템 로그에서 디스크 오류의 흔적을 찾아봅니다.

    # 시스템 로그에서 디스크 관련 오류 검색
dmesg | grep -E "error|failed|I/O" | tail -50

# syslog에서 RAID 관련 이벤트
grep -E "md|raid|disk" /var/log/syslog | tail -100

    여기서 찾아야 할 것: I/O error, read error, medium error 같은 메시지들. 이 오류들이 특정 디스크(sdb, sdc 등)에 집중된다면 그 디스크가 범인입니다.

    Step 4: 고장 디스크 교체 및 RAID 재구성

    원인 파악이 끝났으면 교체 작업을 시작합니다. 핫스왑(Hot-swap, 전원을 켠 채로 디스크 교체)이 지원되는 NAS라면 더 간단합니다.

    1. 문제 디스크를 어레이에서 제거
    # 고장 디스크를 어레이에서 제거
mdadm /dev/md0 --fail /dev/sdb1
mdadm /dev/md0 --remove /dev/sdb1
    1. 물리적으로 디스크 교체 (핫스왑 지원 시 전원 유지 가능)
    2. 새 디스크 파티션 구성
    # 기존 디스크 파티션 구조 확인
fdisk -l /dev/sda

# 기존 디스크의 파티션 테이블을 새 디스크에 복사
sfdisk -d /dev/sda | sfdisk /dev/sdb

# 파티션 확인
fdisk -l /dev/sdb
    1. 새 디스크를 어레이에 추가 (리빌드 시작)
    # 새 디스크를 어레이에 추가
mdadm /dev/md0 --add /dev/sdb1

# 리빌드 진행 상황 모니터링
watch -n5 cat /proc/mdstat

    리빌드 진행 중엔 이런 화면이 보입니다:

    md0 : active raid5 sdb1[4] sda1[0] sdc1[2] sdd1[3]
      [4/4] [UUUU]
      [==========>.......]  recovery = 47.3% (...)
      finish=142.3min speed=123456K/sec

    ⚠️ 경고: 리빌드 중에는 절대로 NAS를 재부팅하거나 전원을 끄지 마세요! 가능하면 다른 서비스 사용을 최소화해서 디스크 부하를 줄이는 게 좋습니다.

    데이터 복구: RAID가 완전히 실패한 경우

    만약 RAID 어레이 자체가 죽어버렸다면? 이건 더 복잡한 상황이지만 포기하지 마세요. 제가 실제로 고객사 서버에서 RAID 5 어레이가 완전히 죽은 상황에서 데이터를 살려낸 경험이 있습니다.

    방법 1: mdadm으로 어레이 재조립 시도

    # 슈퍼블록 정보 스캔 (각 디스크에서)
mdadm --examine /dev/sda1
mdadm --examine /dev/sdb1
mdadm --examine /dev/sdc1

# 어레이 재조립 시도
mdadm --assemble --scan /dev/md0

# 슈퍼블록 손상 시 강제 조립 (마지막 수단!)
mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1

    근데 여기서 중요한 포인트! –force 옵션은 정말 마지막 수단으로 써야 합니다. 잘못 쓰면 더 꼬일 수 있어요.

    방법 2: 디스크 이미지 먼저 뜨기 (필수!)

    데이터 복구 작업 전에 반드시 디스크 이미지를 먼저 떠두세요. 복구 작업 자체가 실패할 경우를 대비한 보험입니다.

    # ddrescue로 디스크 이미지 생성 (오류 내성이 좋음)
# apt-get install gddrescue 로 설치
ddrescue -f -n /dev/sda /mnt/backup/sda.img /mnt/backup/sda.log

# 2회차 (첫 번째 패스에서 실패한 섹터 재시도)
ddrescue -d -f -r3 /dev/sda /mnt/backup/sda.img /mnt/backup/sda.log

# 이미지 마운트 후 파일 접근
mount -o loop,ro /mnt/backup/sda.img /mnt/recovered

    dd보다 ddrescue가 훨씬 좋은 이유는, 불량 섹터를 만나도 거기서 멈추지 않고 계속 진행하면서 나중에 다시 시도하거든요. 저도 처음엔 그냥 dd만 썼다가 오류 나서 멈추는 바람에 삽질했었습니다 ㅎㅎ

    방법 3: TestDisk / PhotoRec 활용

    mdadm으로 안 된다면 오픈소스 복구 도구를 써볼 수 있습니다.

    # TestDisk 설치 및 실행 (파티션 테이블 복구)
apt-get install testdisk
testdisk /dev/sda

# PhotoRec (파일 시그니처 기반 복구)
photorec /dev/sda

    TestDisk는 파티션 테이블과 파일시스템 복구에 특화되어 있고, PhotoRec은 이미 손상된 파일을 카빙(carving, 파일 시그니처 기반 복구)해서 건져냅니다. 포맷이 됐더라도 꽤 건져낼 수 있어요.

    ▲ ddrescue를 이용한 디스크 이미지 생성 과정과 복구율 실시간 모니터링 화면

    자주 발생하는 NAS RAID 설정 문제와 해결법

    문제 1: RAID 리빌드가 너무 느려요

    리빌드 속도가 답답할 때 튜닝할 수 있는 방법입니다:

    # 현재 리빌드 속도 한계 확인 (KB/s 단위)
cat /proc/sys/dev/raid/speed_limit_max
cat /proc/sys/dev/raid/speed_limit_min

# 일시적으로 속도 제한 높이기
echo 300000 > /proc/sys/dev/raid/speed_limit_max
echo 100000 > /proc/sys/dev/raid/speed_limit_min

    💡 팁: 속도를 높이면 시스템 전체 성능에 영향을 줍니다. 업무 시간 이후에 속도 올리고, 낮에는 낮추는 방식으로 운영하면 좋아요.

    문제 2: 디스크는 정상인데 어레이가 Degraded

    가끔 디스크 자체는 멀쩡한데 어레이에서 빠지는 경우가 있습니다. 케이블 불량이나 컨트롤러 문제일 수 있어요.

    # 해당 디스크 슈퍼블록 확인
mdadm --examine /dev/sdb1

# 케이블/슬롯 점검 후 수동으로 다시 추가
mdadm --manage /dev/md0 --add /dev/sdb1

    문제 3: 파일시스템 오류 (RAID는 정상인데 마운트 안 됨)

    RAID 어레이 자체는 살아있는데 그 위의 파일시스템이 손상된 경우입니다.

    # ext4 파일시스템 검사 및 복구
# 반드시 언마운트 상태에서 실행!
fsck.ext4 -y /dev/md0

# XFS 파일시스템
xfs_repair /dev/md0

# Btrfs 파일시스템
btrfs check --repair /dev/md0

    ⚠️ fsck는 절대로 마운트된 파일시스템에 실행하면 안 됩니다. 더 크게 망가집니다. 꼭 언마운트 후에!

    문제 4: 재부팅 후 어레이가 자동으로 올라오지 않음

    mdadm 설정 파일에 어레이 정보가 없어서 생기는 문제입니다.

    # mdadm 설정 파일 재생성
mdadm --detail --scan >> /etc/mdadm/mdadm.conf

# 내용 확인
cat /etc/mdadm/mdadm.conf

# initramfs 업데이트 (Debian/Ubuntu)
update-initramfs -u

    RAID가 있어도 백업은 필수입니다 (제발요)

    13년 동안 인프라 일을 하면서 가장 많이 강조한 말이 있습니다: “RAID는 백업이 아닙니다.”

    RAID는 디스크 고장에 대한 가용성(availability)을 제공하지, 데이터 보호 자체를 보장하는 게 아닙니다. 다음 시나리오는 RAID로 막을 수 없어요:

    • 실수로 파일 삭제 → 전체 어레이에 즉시 반영됨
    • 랜섬웨어 감염 → 마운트된 모든 파일이 암호화됨
    • NAS 본체 고장 (화재, 침수, 전원 서지)
    • RAID 컨트롤러 고장으로 메타데이터 손상

    3-2-1 백업 원칙(3개의 복사본, 2가지 다른 미디어, 1개는 오프사이트)은 NAS RAID 운영에서도 기본 중의 기본입니다. 다음 글에서는 홈랩 NAS의 효율적인 백업 전략을 자세히 다룰 예정이니 참고하세요.

    ▲ NAS RAID 트러블슈팅 핵심 체크리스트와 3-2-1 백업 전략 요약 인포그래픽

    정리: NAS RAID 트러블슈팅 핵심 체크리스트

    마지막으로 RAID 문제가 생겼을 때 기억해야 할 핵심을 정리합니다.

    상황 우선 조치 주의사항
    RAID Degraded SMART 체크 → 고장 디스크 확인 후 교체 리빌드 전 백업 상태 반드시 확인
    RAID Failed 디스크 이미지 생성 → 복구 도구 활용 원본 디스크 보존, 복사본으로만 작업
    리빌드 중 추가 오류 즉시 중단 → 전문 복구 도구 또는 전문가 추가 작업 금지, 디스크 이미지 우선
    파일시스템 오류 언마운트 후 fsck 실행 마운트 상태에서 fsck 절대 금지
    자동 마운트 실패 mdadm.conf 재생성 후 initramfs 업데이트 설정 파일 백업 습관화

    NAS RAID 트러블슈팅은 경험이 쌓일수록 훨씬 침착하게 대응할 수 있게 됩니다. 처음엔 무섭지만, 체계적으로 접근하면 대부분의 상황은 해결됩니다. 중요한 건 패닉하지 말고 순서대로 진행하는 것이에요.

    혹시 지금 당장 NAS RAID 문제를 겪고 계신가요? 댓글로 상황을 공유해주시면 같이 해결해봅시다. 이런 거 함께 나누는 게 커뮤니티의 힘이라고 생각하거든요.

  • [Synology NAS] 데이터 복구 및 백업 전략: Hyper Backup과 Snapshot Replication 완벽 가이드

    [Synology NAS] 데이터 복구 및 백업 전략: Hyper Backup과 Snapshot Replication 완벽 가이드

    목차

    데이터 날린 그날, 저는 진짜 멘붕이었습니다

    몇 년 전 일인데요, 홈랩에서 운영하던 Synology NAS의 볼륨 하나가 갑자기 마운트가 안 되는 상황이 생겼습니다. 당시 저는 DSM(DiskStation Manager) 업데이트를 막 마친 참이었는데, 재부팅 후 볼륨 상태가 Degraded(저하됨)로 뜨더라고요. 식은땀이 났죠. 그 볼륨에는 수년 치 사진 원본 파일이랑 업무용 스크립트들이 잔뜩 들어있었거든요.

    다행히 그때는 Hyper Backup으로 주기적으로 백업을 해두고 있었고, 결국 데이터는 복구했습니다. 근데 그 경험이 저한테는 엄청난 교훈이 됐어요. “백업은 있는데 복구 테스트를 한 번도 안 해봤다”는 게 얼마나 위험한 건지 그날 뼈저리게 깨달았습니다.

    오늘은 Synology NAS 데이터 복구를 실제로 어떻게 준비하고 실행하는지, 제가 직접 써보고 정착시킨 백업 전략을 공유해 드리려고 합니다. Hyper Backup과 Snapshot Replication(스냅샷 복제), 이 두 도구를 어떻게 조합해서 쓰는지가 핵심입니다.

    Synology NAS 백업 전략 아키텍처 — Hyper Backup과 Snapshot Replication 이중 구성 다이어그램

    ▲ Synology NAS의 이중 백업 전략 — Hyper Backup과 Snapshot Replication을 레이어로 구성한 전체 아키텍처 개요

    먼저 개념부터: 왜 두 가지 도구가 필요한가요?

    처음에 저도 “백업 하나면 되는 거 아냐?” 싶었는데, 실제로 써보니까 두 도구가 커버하는 영역이 완전히 달라요. 쉽게 설명해 드릴게요.

    Hyper Backup — 장거리 안전망

    Hyper Backup은 NAS의 데이터를 외부 대상(다른 NAS, 외장 드라이브, 클라우드 등)으로 증분 백업(Incremental Backup)하는 도구입니다. 변경된 파일만 백업해서 저장 공간을 효율적으로 씁니다.

    • 백업 대상: 폴더, 패키지, 시스템 설정까지 포함 가능
    • 보관 기간: 버전 관리로 특정 시점으로 되돌리기 가능
    • 대상 저장소: 로컬 드라이브, 원격 NAS, Amazon S3, Backblaze B2, Google Drive 등
    • 복구 단위: 파일 단위 또는 전체 백업 세트 복구

    쉽게 말해, 몇 주 전 상태로 돌아가야 할 때 쓰는 도구예요. 랜섬웨어에 감염됐는데 3주 전 파일이 필요할 때 같은 상황이죠.

    Snapshot Replication — 단거리 빠른 복원

    Snapshot Replication(스냅샷 복제)은 Btrfs 파일 시스템 기반의 볼륨/공유 폴더 스냅샷을 찍어두는 기능입니다. 운영 중인 상태를 그대로 순간 포착해두는 거죠.

    • 스냅샷 간격: 최소 5분 단위까지 설정 가능
    • 복구 속도: 거의 즉각적 (파일 시스템 레벨 작업)
    • 복구 단위: 공유 폴더 전체 또는 개별 파일
    • 전제 조건: Btrfs 파일 시스템으로 포맷된 볼륨 필요

    오늘 오전에 실수로 파일을 지웠는데 바로 되돌려야 할 때, 이게 훨씬 빠르고 편합니다. “어? 방금 지웠는데?” 싶을 때 쓰는 거죠.

    구분 Hyper Backup Snapshot Replication
    주요 용도 장기 보존, 외부 백업 빠른 단기 복원
    복구 속도 상대적으로 느림 (파일 복사) 매우 빠름 (메타데이터 조작)
    저장 위치 외부 대상 필수 동일 볼륨 내 가능
    파일 시스템 ext4, Btrfs 모두 지원 Btrfs 전용
    버전 관리 최대 수십~수백 버전 설정에 따라 수십 개
    재해 복구 강함 (오프사이트 가능) 약함 (NAS 자체 장애시 무력)

    이 둘을 조합하는 게 핵심입니다. 스냅샷은 빠른 일상 복원용, Hyper Backup은 재해(Disaster) 상황 대비용이에요.

    Snapshot Replication 설정하기 — 먼저 이걸 켜두세요

    스냅샷은 설정이 간단하고 효과가 즉각적이라서 먼저 세팅해 두는 걸 추천드려요. 단, 앞서 말씀드린 것처럼 Btrfs 파일 시스템이 전제입니다. DSM에서 볼륨 생성할 때 Btrfs를 선택했어야 해요. ext4로 만들어뒀다면 Snapshot Replication은 쓸 수 없어요 — 이거 처음에 모르고 삽질했었습니다 ㅎㅎ.

    1단계: Snapshot Replication 패키지 설치

    1. DSM 패키지 센터(Package Center)에서 “Snapshot Replication” 검색 후 설치
    2. 설치 완료 후 패키지를 실행

    2단계: 공유 폴더(Shared Folder) 스냅샷 활성화

    1. Snapshot Replication 앱 실행
    2. 좌측 메뉴에서 스냅샷(Snapshots) 선택
    3. 스냅샷을 활성화할 공유 폴더 선택
    4. 설정(Settings) 클릭 → 스케줄 탭으로 이동

    저는 아래처럼 스케줄을 구성해서 쓰고 있어요:

    # Snapshot Replication 권장 스케줄 예시
# (DSM UI에서 설정하는 값 기준)

스냅샷 간격: 매시간 (1시간마다)
보관 정책 (Retention Policy):
  - 최근 24시간: 시간별 스냅샷 유지
  - 최근 30일: 일별 스냅샷 유지
  - 최근 12개월: 주별 스냅샷 유지

앱 일관성(Application Consistency): 활성화 권장
# → 데이터베이스 등 앱 실행 중에도 일관된 스냅샷 보장

    3단계: 사용자 셀프 서비스 복원 활성화

    이게 진짜 꿀기능인데요. 활성화해두면 일반 사용자도 Windows의 “이전 버전” 기능처럼 파일을 직접 복원할 수 있어요. 관리자한테 매번 요청 안 해도 되니까 가족이나 팀 구성원이 있는 환경에서 특히 편합니다.

    1. 공유 폴더 선택 → 설정 → 고급(Advanced) 탭
    2. “사용자가 이전 버전에 액세스할 수 있도록 허용” 체크
    3. SMB(Windows 파일 공유)로 접근 시 파일 우클릭 → “이전 버전” 탭에서 복원 가능
    Synology DSM Snapshot Replication 스케줄 및 보관 정책 설정 화면

    ▲ DSM의 Snapshot Replication 설정 화면 — 스케줄 간격과 보관 정책을 이렇게 구성하면 실수로 지운 파일도 빠르게 복원할 수 있습니다

    Hyper Backup 설정하기 — 진짜 백업은 이거예요

    Snapshot Replication은 NAS 자체가 고장나면 의미가 없어요. 진짜 재해 복구(Disaster Recovery)를 위해서는 반드시 오프사이트 백업(Off-site Backup)이 필요합니다. 저는 Hyper Backup으로 외부 NAS와 클라우드 두 곳에 백업을 보내고 있어요.

    1단계: 백업 대상 선택

    Hyper Backup이 지원하는 백업 대상은 다양합니다:

    • 로컬 폴더 및 USB 드라이브
    • 원격 NAS (rsync 또는 Synology 전용 프로토콜)
    • Amazon S3 및 S3 호환 스토리지 (Wasabi, MinIO 등)
    • Backblaze B2
    • Google Drive, Microsoft OneDrive, Dropbox
    • Azure Blob Storage

    저는 로컬 NAS → 외부 NAS(원격) + Backblaze B2(클라우드) 구조로 3-2-1 백업 전략을 구현하고 있어요.

    💡 3-2-1 백업 규칙: 데이터 3개 복사본, 2가지 다른 미디어, 1개는 오프사이트 보관. 백업의 황금 법칙입니다.

    2단계: Hyper Backup 작업 생성

    1. DSM 메인 메뉴 → Hyper Backup 실행
    2. 좌하단 + 버튼 → 데이터 백업 작업(Data Backup Task) 선택
    3. 백업 대상 유형 선택 (예: Synology C2, Amazon S3, 원격 NAS 등)
    4. 연결 정보 입력 후 다음

    3단계: 백업 폴더 및 애플리케이션 선택

    # Hyper Backup 백업 대상 선택 권장 항목

[공유 폴더]
✅ photo          # 사진 폴더
✅ documents      # 문서 폴더  
✅ homes          # 사용자 홈 폴더
✅ docker         # Docker 볼륨 (있는 경우)

[애플리케이션 (Application)]
✅ DSM 구성 (시스템 설정 백업)
✅ 사용 중인 패키지 설정들
# 예: Surveillance Station, Note Station 등

# 주의: Docker 컨테이너 데이터는
# 볼륨 폴더 백업과 병행해야 합니다

    4단계: 스케줄 및 버전 보관 정책 설정

    # Hyper Backup 권장 설정 값

백업 스케줄: 매일 새벽 3:00 AM
# 시스템 부하가 적은 시간대 권장

버전 보관 정책 (Smart Recycle):
  - 최근 1~7일: 매일 1개 버전 보관
  - 최근 1~4주: 매주 1개 버전 보관  
  - 최근 1~12개월: 매월 1개 버전 보관

암호화(Encryption): 활성화 강력 권장
# 클라우드 백업 시 특히 중요
# ⚠️ 암호화 키 분실 시 복구 불가 — 반드시 키 별도 보관!

알림(Notification): 이메일 또는 푸시 알림 설정
# 백업 실패 즉시 인지하기 위해 필수

    ⚠️ 중요 경고: 암호화를 활성화했다면 암호화 키를 반드시 NAS 외부에 별도로 저장해두세요. 저도 이걸 USB에 인쇄해서 물리적으로 보관하고 있어요. NAS가 날아가면 키도 같이 날아가니까요.

    ⚠️ 실제로 겪은 문제들과 해결법

    이론은 이론이고, 실제로 써보면 별별 문제가 다 생기더라고요. 제가 삽질했던 것들 몇 가지 공유해 드릴게요.

    문제 1: Snapshot이 안 찍힌다 — ext4 볼륨이었던 것

    Snapshot Replication 설정해놨는데 스냅샷이 하나도 안 생기는 거예요. 알고 보니 해당 볼륨이 ext4로 포맷되어 있었던 거였습니다. Btrfs가 아니면 스냅샷 자체가 불가능해요. 이 경우엔 볼륨을 다시 만들어야 하는데, 그럼 데이터 마이그레이션이 필요합니다.

    💡 확인 방법: DSM → 저장소 관리자(Storage Manager) → 볼륨 선택 → 파일 시스템 항목 확인

    문제 2: Hyper Backup 작업이 자꾸 실패

    클라우드 백업이 며칠째 실패 알림이 오는 거예요. 로그를 보니 연결 타임아웃이었는데, 원인은 백업 데이터가 너무 커서 업로드 중간에 끊기는 거였습니다. 해결책은 두 가지였어요:

    1. 첫 백업은 최대한 대상 데이터를 줄인 상태에서 실행 (초기 풀 백업 완료 후 증분만 돌리기)
    2. 백업 시간대를 네트워크 사용량이 적은 새벽으로 변경

    문제 3: 복구 테스트 안 했다가 낭패

    이게 제일 중요한 교훈인데요. 백업은 있는데 복구가 안 되면 의미가 없잖아요. 저는 6개월 동안 Hyper Backup을 돌리면서 한 번도 복구 테스트를 안 했었어요. 그러다 실제 복구가 필요한 상황이 왔을 때 백업 파일이 손상되어 있는 걸 발견했습니다. 진짜 식은땀 났죠.

    지금은 분기에 한 번 복구 테스트를 캘린더에 넣어두고 반드시 실행합니다. 방법은 아래와 같아요:

    # Hyper Backup 복구 테스트 절차

1. Hyper Backup Vault 또는 Hyper Backup Explorer 실행
   (백업 대상 NAS에 설치된 Vault, 또는 PC용 Explorer 사용)

2. 백업 저장소 연결 → 특정 날짜 버전 선택

3. 테스트 폴더로 일부 파일 복원 시도
   예: /photo/2023 폴더 중 샘플 10개 파일

4. 복원된 파일 무결성 확인
   - 파일이 정상적으로 열리는지
   - 파일 크기가 원본과 일치하는지

5. DSM → Hyper Backup → 통계(Statistics)에서
   백업 무결성 검사(Backup Integrity Check) 실행
    Synology NAS 데이터 복구 화면 — Hyper Backup 날짜별 버전 선택 및 파일 복원 인터페이스

    ▲ Hyper Backup 복구 화면 — 날짜별 버전을 선택해 특정 시점의 파일을 복원할 수 있습니다. 분기 1회 복구 테스트를 꼭 해보세요

    실제 데이터 복구 시나리오별 대응법

    “어떤 상황에 뭘 써야 하나” 헷갈리실 것 같아서 시나리오별로 정리해 드릴게요.

    시나리오 A: 파일 실수로 삭제 (오늘 발생)

    1. Snapshot Replication 앱 실행
    2. 해당 공유 폴더 선택 → 찾아보기(Browse)
    3. 삭제 직전 시점의 스냅샷 선택
    4. 파일 선택 → 복원(Restore) 또는 다운로드

    ✅ 보통 1~2분 내로 해결됩니다.

    시나리오 B: 랜섬웨어 감염 (수일 전 파일 필요)

    1. 즉시 NAS 네트워크 연결 차단 (추가 감염 방지)
    2. Hyper Backup 실행 → 감염 이전 날짜 버전 선택
    3. 격리된 환경에 복원 후 파일 검증
    4. 볼륨 초기화 후 클린 복원

    ⚠️ 이때 스냅샷은 이미 랜섬웨어에 의해 오염됐을 가능성이 있어요. 반드시 외부 백업(Hyper Backup)에서 복원하세요.

    시나리오 C: NAS 하드웨어 완전 고장

    1. 새 NAS 또는 교체 NAS에 DSM 설치
    2. Hyper Backup 설치 후 백업 저장소 연결
    3. 전체 복원(Full Restore) 실행 — 시스템 설정 포함 복원 가능
    4. 패키지 설정까지 백업해뒀다면 거의 원상 복구 가능

    저는 이 시나리오를 실제로 겪었는데, DSM 설정까지 백업해둔 덕분에 새 NAS 세팅 시간이 정말 많이 줄었습니다. 처음엔 이게 되나 싶었는데 진짜 되더라고요 ㅎㅎ.

    제가 최종 정착한 백업 구성 — 참고하세요

    여러 번 바꾸고 다듬어서 지금은 이 구성으로 안정적으로 운영 중입니다:

    # 홈랩 NAS 백업 구성 (최종)

[1레이어] Snapshot Replication
  - 대상: 모든 Btrfs 공유 폴더
  - 주기: 매시간
  - 보관: 24시간(시간별) + 30일(일별)
  - 목적: 빠른 파일 복원

[2레이어] Hyper Backup → 외장 USB HDD
  - 주기: 매일 새벽 2:00 AM
  - 보관: Smart Recycle (월별 최대 12개월)
  - 암호화: 활성화
  - 목적: 로컬 오프사이트 복사본

[3레이어] Hyper Backup → Backblaze B2
  - 주기: 매일 새벽 3:30 AM
  - 보관: Smart Recycle (월별 최대 12개월)
  - 암호화: 활성화
  - 목적: 클라우드 오프사이트 (화재/도난 대비)

[검증]
  - 매주: 백업 완료 알림 이메일 확인
  - 분기: 실제 파일 복원 테스트
  - 연간: 전체 복구 시뮬레이션

    이 구성이면 3-2-1 백업 전략을 완전히 충족하고, 일상적인 실수부터 하드웨어 전체 고장까지 대부분의 시나리오에 대응할 수 있어요.

    3-2-1 백업 전략 인포그래픽 — Synology NAS 3단계 데이터 보호 구조 요약

    ▲ 3-2-1 백업 전략 요약 인포그래픽 — Snapshot, 로컬 외장드라이브, 클라우드를 조합한 3단계 보호 구조

    자주 묻는 질문 (FAQ)

    Q. Snapshot Replication은 용량을 많이 차지하나요?

    Btrfs의 Copy-on-Write(CoW) 특성 덕분에 변경된 블록만 추가 저장해요. 파일 변경이 적은 환경에서는 스냅샷 용량 증가가 미미합니다. 다만 파일 변경이 잦은 폴더(예: 다운로드 폴더)는 스냅샷 보관 수를 줄이는 게 좋아요.

    Q. Hyper Backup 초기 백업이 너무 오래 걸려요

    첫 풀 백업은 데이터 크기에 따라 며칠이 걸릴 수 있습니다. 처음엔 백업 대상 폴더를 최소화해서 시작하고, 이후 점진적으로 추가하는 방식을 추천드려요. 또는 USB HDD에 먼저 풀 백업 후 클라우드로 이관하는 방법도 있어요.

    Q. ext4 볼륨인데 스냅샷을 쓸 수 없나요?

    네, Snapshot Replication은 Btrfs 전용입니다. ext4 환경이라면 Hyper Backup만으로 백업 전략을 구성하시거나, 새 볼륨 생성 시 Btrfs를 선택하는 걸 권장드려요.

    Q. DSM 버전에 따라 기능 차이가 있나요?

    Hyper Backup과 Snapshot Replication은 DSM 6.x 이후 버전에서 안정적으로 지원됩니다. DSM 7.x에서 UI가 개선되고 일부 기능이 추가됐으니, 최신 DSM 유지를 권장합니다.

    마무리 — 백업은 있는 게 아니라 복구되는 게 중요합니다

    결국 제가 이 글에서 가장 강조하고 싶은 건 하나예요. “백업을 설정했다”는 것과 “복구할 수 있다”는 건 완전히 다른 얘기입니다. 저도 그 차이를 몸으로 배웠거든요.

    Synology NAS 데이터 복구를 위한 전략을 정리하면:

    • ✅ Snapshot Replication으로 빠른 일상 복원 레이어 구성
    • ✅ Hyper Backup으로 외부 오프사이트 백업 구성
    • ✅ 3-2-1 원칙 준수
    • ✅ 분기 1회 이상 실제 복구 테스트 반드시 실행
    • ✅ 백업 실패 알림 설정으로 문제 즉시 인지

    데이터가 날아가고 나서 후회하는 것만큼 억울한 게 없어요. 오늘 당장 복구 테스트 한 번 해보시는 걸 강력 추천드립니다. 생각보다 간단하고, 그 안도감은 진짜거든요. 🎉

    다음 글에서는 Synology NAS의 능동적 보안 설정 — 방화벽 규칙 구성과 2FA(이중 인증) 강화 방법을 다뤄볼 예정입니다. 백업 전략을 완성했다면 보안도 같이 챙겨야 하니까요. 이전 글에서는 Synology NAS 초기 세팅 가이드를 다뤘으니 참고해 보세요.